Half of my professional software career has been working with the LAMP stack and Content Management Systems - mainly Drupal. The half before it - the formative half - was with desktop programming, or as we called it back then - programming.
Since Drupal 5, I've toyed with the idea of writing a content management system in a compiled language such as C++. As Drupal has become more abstracted in layers, I've increasingly thought about it because in trying to be everything to everyone, Drupal does seem to becoming less of a content management system and more of a framework. Some already call it a framework, but I think it's more fair to say that it's moving toward becoming a framework.
But is a framework based on PHP really that efficient? From a coding perspective - from a development perspective - yes, it is. This is because development times will typically be lower with PHP, all things being equal. Still, as I have been pondering things that I would want to do with a framework such as Drupal, I often stop and say, "That query will take a while, so I'll have to build Yet Another Table on cron runs (as the search module does)". And then I consider how long code might take to run with some of the heavier algorithms I've considered for navigation and search.
The answer since the start of the Internet has always been to throw more hardware at complexity. For those of us who can remember the Wintel era of computing, it's basically the same model that allows more 'features' (or 'bloat') to run at an acceptable speed. This has been really good as content management systems such as Drupal, Joomla and yes, the heavily evolved Wordpress, to become the veritable powerhouses that they are now.
Who Needs What?
There are two sides to the content management market. There is the large corporation/organization side (some call it 'Enterprise') and there's the small side of the market. The most development money is spent by those on the large side of the market who need customization. The least development money is spent on the small side of the market, where the basic features - and usually only some of those features - are used.
In the context of Drupal, other than being unsupported, I don't expect that the smaller end of things will be throwing wads of cash at Drupal 8. In time, Drupal 6 will not be supported just as Drupal 5 no longer is, and the talk of Drupal 9 will continue. What will happen to the Drupal 6 folks? They'll either shell out the cost to upgrade to Drupal 8 or switch to something else. I'd wager that's the majority.
Most people will be looking at upgrading with nothing more to gain other than support - a distinctly Microsoft business model.
In thinking about all of this and discussing it with a few in the Drupal world, as well as wondering how to effectively use more complex algorithms such that they are usable for a browser, I began thinking of C++ again. Granted, you could do it in any language, but I know C++. I cut my teeth on C/C++ in the professional world. And I found some interesting things.
In looking around, I found CppCMS - A C++ framework, and for most people that might be just too much. There's CppBlog for those who only need a blog, and then there's WikiPP. From a back end perspective, these will likely be awesome - but I'm not sure what the front end customization will be like or how easily the framework can be extended. Still, it's something worth exploring - and it demonstrates that I'm not the only person who has been considering inefficiencies in present frameworks - and that I'm so late to the game that I might have very little to do. It's dual licensed, too, with the LGPLv3 or the alternative commercial license.
Another thing I'm planning to look at is Snap Websites. They say a mouthful right here:
The main idea of having this written in C++ is for speed of execution. PHP is an interpreted language and although it is fast to develop, it remains slow to execute.
The other big change from Drupal is the backend. We want to use a data manager, not a full blown SQL database. This introduces a problem: we cannot as easily gather data. However, quite often, this data gathering in Drupal can be quite slow. Not only that, it is difficult to maintain, difficult to backup for easy restore, difficult to move from one system to another. With a data manager that does all of that work automatically, the small draw back of some extra work for data gathering looks quite acceptable.
Another huge problem with Drupal: it is impossible to have a truly international website. I tried a couple of times, and it just is a nightmare to manage. You get different pages for different languages so each menu to that "one" page are different for each language. Imagine you have a documentation of 100 pages written in three languages, that's 300 links to manage MANUALLY! (if you want the site to work as expected, at least)
So, again, someone else has thought it through and has written something.
Yes, I know about node.js, as well as a million other better mousetraps out there. I'm not disrespecting their efforts at all - I'll encourage them - but to me, I think compiled code for basic features makes a solid bit of sense for a lot of people.
Am I sold on any one path? No. But it seems to me that we're coming to a juncture with LAMP based CMS's where at least some of the features should be compiled rather than abstracted out. It makes for easier support for the majority of users (not the high dollar users) and doesn't leave them holding an old unsupported version of a PHP CMS.
Conversely, it could also mean a lot of trouble for support as well. I'm not sold. My eyes, however, are open.