Another new era of WordPress(bethesignal.org)
bethesignal.org
Another new era of WordPress
http://bethesignal.org/blog/2015/02/27/new-era-wordpress-hhvm-rest-react/
25 comments
No.
Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Which makes PHP the slow bit.
Not because PHP is bad: That’s a pretty reasonable figure for platforms based on Ruby, Python, PHP, etc. (Less so for Java and .NET.)
It's a really good rule of thumb: If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.
You’ve probably hit a database scalability limit, or tried to get the database to do something silly. (And hey, that’s easy to do with MySQL, which is fast primarily because it’s dumb.)
(By the way: WordPress, out of the box, doesn't spend much time in the database at all.)
Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Which makes PHP the slow bit.
Not because PHP is bad: That’s a pretty reasonable figure for platforms based on Ruby, Python, PHP, etc. (Less so for Java and .NET.)
It's a really good rule of thumb: If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.
You’ve probably hit a database scalability limit, or tried to get the database to do something silly. (And hey, that’s easy to do with MySQL, which is fast primarily because it’s dumb.)
(By the way: WordPress, out of the box, doesn't spend much time in the database at all.)
I'm going to have to backup jdub on this. The "IO/database should be" classic wisdom has not really held up to my experience doing a stint providing managed support for LAMP(P as in PHP) servers at a hosting company. Most of the time there were performance issues it was PHP taking up the CPU's. We had a lot of success mitigating this for people with some proper varnish configs.
Very rarely was the issue with the databases. I've had people not want to normalize data and create some generally disgusting tables and code because "joins bad"... On tables that will only ever have a few 10k records. If you have the proper indexes and queries in place, your database is just traversing btree's in memory and it will be blazing fast.
Very rarely was the issue with the databases. I've had people not want to normalize data and create some generally disgusting tables and code because "joins bad"... On tables that will only ever have a few 10k records. If you have the proper indexes and queries in place, your database is just traversing btree's in memory and it will be blazing fast.
> If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.
For most webapps, I/O typically should be the bottleneck. This holds especially true for wordpress, which has nothing computationally heavy to do, and is...rather liberal with the way it queries the database. Certainly the large installations I've managed spent most time doing I/O (either in the database or memcached.)
For most webapps, I/O typically should be the bottleneck. This holds especially true for wordpress, which has nothing computationally heavy to do, and is...rather liberal with the way it queries the database. Certainly the large installations I've managed spent most time doing I/O (either in the database or memcached.)
This is completely correct. On smaller sites, we're usually seeing 1% of total time spent in database, the rest being PHP. With larger sites, this increases a bit to around 5% because larger databases take longer to return queries.
It is, absolutely. And Wordpress is notoriously liberal with its queries and use of storage in relational database (unless something monumental has changed in the last year). There's a reason there are 8 million caching plugins.
If PHP is the slowest part of your application, you're probably in good shape. If your Wordpress application is slow, replacing PHP with Hack is like putting a souped up engine in a car with no gas in the tank.
PHP scaled poorly at Facebook not because it was PHP, but because it was Facebook. They would have run into the same (or worse) performance issues with most dynamically-typed languages.
If PHP is the slowest part of your application, you're probably in good shape. If your Wordpress application is slow, replacing PHP with Hack is like putting a souped up engine in a car with no gas in the tank.
PHP scaled poorly at Facebook not because it was PHP, but because it was Facebook. They would have run into the same (or worse) performance issues with most dynamically-typed languages.
HHVM was needed at Facebook because it's a dynamic app with rapidly changing content.
WordPress sites are typically static content that are perfectly fit for static caching with a CDN - it really shouldn't matter how many milliseconds you are able to save on the server if your site is only being hit once every two hours from the CDN.
The 8 million caching plugins are unnecessary when you can just sign up for cloudflare.
WordPress sites are typically static content that are perfectly fit for static caching with a CDN - it really shouldn't matter how many milliseconds you are able to save on the server if your site is only being hit once every two hours from the CDN.
The 8 million caching plugins are unnecessary when you can just sign up for cloudflare.
8 million caching plugins is a total exaggeration. As far as I can tell there's only two options: WP Super Cache (which seems to have been abandoned by the author) and W3 Total Cache which is a spammy mess of nag screens to join New Relic and MaxCDN. (No wonder it was banned by WP-Engine.) If I wasn't busy on other projects, I would take on W3 Total Cache--it's the worst UI I have ever seen and it doesn't even work. I had to mostly disable it today because my CPU went from 100% to 600% after installing it.
FYI, WP Super Cache is not really abandoned. The plugin author works for Automattic (as do I). I would say more that it has been so popular that support has been hard to keep up with and there hasn't been much focus on new features recently. Patches are always welcome: https://github.com/Automattic/wp-super-cache/
Seeing a lot more than two: https://wordpress.org/plugins/tags/cache
How many big WordPress sites do you reckon can say, "Fuck it, it's all static anyway"? I mean, your blog, sure, but the New York Times?
(Who are, interestingly enough, putting a non-PHP-based high performance dynamic front-end in front of WordPress using... WP-API.)
(Who are, interestingly enough, putting a non-PHP-based high performance dynamic front-end in front of WordPress using... WP-API.)
Cloudflare is - in this example - just one of the 8 million (albeit as a CDN, a far wiser choice).
Ultimately that sacrifice comes down to real-time dynamic site versus having some content be static or conditionally dynamic. None of that is a symptom of PHP as the backend (unless you have a LOT of traffic).
Ultimately that sacrifice comes down to real-time dynamic site versus having some content be static or conditionally dynamic. None of that is a symptom of PHP as the backend (unless you have a LOT of traffic).
> If PHP is the slowest part of your application, you're probably in good shape.
Or doing something epicly wrong. One of the two...
Or doing something epicly wrong. One of the two...
Anecdotally, I got a pretty noticeable speedup on an experimental WordPress-on-HHVM setup even on a page that was running dozens of database queries.
(I didn't end up taking it live because HHVM did not render the page entirely correctly, but the speedup was still pretty nice.)
(I didn't end up taking it live because HHVM did not render the page entirely correctly, but the speedup was still pretty nice.)
I presume this is the case, but were you comparing against PHP with APC or similar in place?
Yep. I double-checked that I hadn't borked the PHP install because I was surprised at the result. I'm not sure what it was doing to make the big difference since the inconsistencies with real PHP behavior were enough to write it off as a drop-in replacement, so I didn't continue experimenting much more, but it seemed promising.
I did some server engineering for a large media property based on WordPress. The New Relic graph normally indicated > 80% of request turnaround was spent in PHP. An average request (there was a frontend caching layer in place) that hit the app would normally take ~700ms, of which ~550 would be spent in WordPress. I attributed it mostly to WordPress being WordPress though. A lean PHP API can turn a typical request around on similar machinery in 1/10 the time.
That doesn't discount that the database is ridiculously ugly, though.
That doesn't discount that the database is ridiculously ugly, though.
In that example, I bet WordPress on its own would have spent less than 550ms without having to replenish your cache layer. Also how much of that time was actually PHP vs. PHP waiting for MySQL? I bet if you scattered microtimers throughout WordPress, you would see 99% of your 550ms would be waiting for the disk and MySQL.
No, actually MySQL was the remainder (~150ms).
WordPress wasn't updating the cache; I mention that because 700ms is painfully slow, once all the JS and ads run load time can cross 2 full seconds. The cache becomes the only acceptable way to run it in production.
New Relic actually provides a breakdown of how much time was spent in each function; while I don't remember offhand what that was, there wasn't any low-hanging fruit that could be optimized.
WordPress wasn't updating the cache; I mention that because 700ms is painfully slow, once all the JS and ads run load time can cross 2 full seconds. The cache becomes the only acceptable way to run it in production.
New Relic actually provides a breakdown of how much time was spent in each function; while I don't remember offhand what that was, there wasn't any low-hanging fruit that could be optimized.
"I attributed it mostly to WordPress being WordPress though."
One of the unfortunate issues with Wordpress is their continued support for outdated PHP versions. Wordpress is compatible with as far back as PHP 5.2.4, which was released back in 2007. There have been many performance improvements to PHP since the early versions of 5.x. The fact that Wordpress is eating up so much CPU on trivial CRUD logic is probably attributed to the sheer amount of technical debt/cruft in the code base, but also compounded by the need (insistence?) to support legacy systems, thus not being able to take advantage of newer features of PHP.
One of the unfortunate issues with Wordpress is their continued support for outdated PHP versions. Wordpress is compatible with as far back as PHP 5.2.4, which was released back in 2007. There have been many performance improvements to PHP since the early versions of 5.x. The fact that Wordpress is eating up so much CPU on trivial CRUD logic is probably attributed to the sheer amount of technical debt/cruft in the code base, but also compounded by the need (insistence?) to support legacy systems, thus not being able to take advantage of newer features of PHP.
The conservative choice of PHP 5.2 as the minimum requirement for WordPress doesn't stop performance sensitive sites using later versions of PHP, or HHVM, or Phalanger, or whatever floats their boat.
Indeed, only 30% of WordPress installs use PHP 5.2.
Runtime features are not a problem for WordPress users.
If you think the minimum requirement is limiting potential for optimisation, what are some relevant language and library features in subsequent versions that the WordPress team can’t use?
Indeed, only 30% of WordPress installs use PHP 5.2.
Runtime features are not a problem for WordPress users.
If you think the minimum requirement is limiting potential for optimisation, what are some relevant language and library features in subsequent versions that the WordPress team can’t use?
I agree that the database is the bottleneck. I wrote a DB caching drop-in for WordPress and got pretty deep into the various queries that are running. There really aren't any nasty joins, but the problem is that the stock WordPress install with the default theme and no plugins runs nearly 30 DB queries per page. If you install once of the really slick commercial themes then WordPress will run upwards of 100 queries on every single page view.
Even a small site with a low level of traffic can bring a modest DB server to it's knees without caching of some type. It's really ridiculous but just due to the modular nature of WordPress.
Even a small site with a low level of traffic can bring a modest DB server to it's knees without caching of some type. It's really ridiculous but just due to the modular nature of WordPress.
I agree. And that's just fine for 99% of the bloggers that will never reach 1 million pageviews/month. Most of those queries are unnecessary. But rather than fix the root of the problem, we put the whole database in memory. Run out of memory? No problem, move to a solid state drive! LOL.
With a caching plugin like W3 Total Cache you should not be hitting the database very often. I take this a step further and cache the entire site (not just resources) on CloudFront.
In my opinion site-wide caching (like Cloudfront) is the best answer. The fewer plugins the better. Ideally WP is just the publishing backend for whatever CDN-type solution you use.
Except that W3 Total Cache trades I/O time for PHP time. In most cases, you can fix I/O time. You can't fix PHP time by adding more PHP. :-)
Sorry, I was unclear. I meant Cloudfront.
> Is the database not the bottleneck?
It shouldn't be. If it is, it's because you missed a cache result. Even for highly dynamic sites, the DB should never be the slowest part of your app because you rarely hit it.
It shouldn't be. If it is, it's because you missed a cache result. Even for highly dynamic sites, the DB should never be the slowest part of your app because you rarely hit it.
Every time I have to debug another problem in Wordpress, every time I encounter another bug in WP's core code I raise my head up and cry, impotent rage against the nameless void. Wordpress' architecture resembles a plate of spaghetti. It's abominable, a horror upon the face of this planet.
I don't mind PHP though :)
I don't mind PHP though :)
And, yet, the results for users are stunningly great. I heavily use both WordPress and Drupal for sites. WordPress may be uglier on the backend, but to people just using the software, the differences could not be more stark, and Drupal does not fare well.
Things like upgrading the core software...with WordPress it's so easy that it doesn't even take thought; hell, they've made upgrades automatic by default a few days ago. With Drupal, I'm months into a migration process to get our site onto Drupal 7 (not even kidding). It's been more complicated, and more error-prone, than the process of migrating from OpenACS to Joomla and then from Joomla into Drupal 6.
WordPress also seems to have the ecosystem right. No matter what kind of task you're trying to solve, there are a dozen plugins for it, some free, some commercial, some a hybrid of the two (sometimes annoyingly spammy about it). I've whipped up several websites in the past few weeks for various side projects I have, and it's downright fun to build complicated sites with WordPress. And, because there are more themes than there are people using WordPress (exaggeration to make a point), getting a site looking good and not like every other WordPress site is trivial and cheap. I find myself wanting to make new websites because it's more fun than working on my company website running Drupal. When it comes to building custom code, I prefer Drupal (mostly), but I do that pretty rarely; I interact with the frontend and admin interface daily.
I've almost talked myself into migrating my company site to WordPress+bbPress. I wonder if there's a really good ticket tracker option for WordPress...
Things like upgrading the core software...with WordPress it's so easy that it doesn't even take thought; hell, they've made upgrades automatic by default a few days ago. With Drupal, I'm months into a migration process to get our site onto Drupal 7 (not even kidding). It's been more complicated, and more error-prone, than the process of migrating from OpenACS to Joomla and then from Joomla into Drupal 6.
WordPress also seems to have the ecosystem right. No matter what kind of task you're trying to solve, there are a dozen plugins for it, some free, some commercial, some a hybrid of the two (sometimes annoyingly spammy about it). I've whipped up several websites in the past few weeks for various side projects I have, and it's downright fun to build complicated sites with WordPress. And, because there are more themes than there are people using WordPress (exaggeration to make a point), getting a site looking good and not like every other WordPress site is trivial and cheap. I find myself wanting to make new websites because it's more fun than working on my company website running Drupal. When it comes to building custom code, I prefer Drupal (mostly), but I do that pretty rarely; I interact with the frontend and admin interface daily.
I've almost talked myself into migrating my company site to WordPress+bbPress. I wonder if there's a really good ticket tracker option for WordPress...
"No matter what kind of task you're trying to solve, there are a dozen plugins for it, some free, some commercial, some a hybrid of the two (sometimes annoyingly spammy about it)."
This is a double-edged sword that can get you into trouble quickly. Personally, I prefer systems that focus on one thing and one thing only.
This is a double-edged sword that can get you into trouble quickly. Personally, I prefer systems that focus on one thing and one thing only.
But, I need more than one thing on my websites. Sure, you can have many disparate parts all doing their one thing well
..but the user experience for that often sucks. Controlling notifications from four different tools in four different places is deeply user hostile, for example, and that's the situation I'd be putting my users in for our website (unless I built a unified notification UI for forums, content, tickets, and store applications). Likewise unifying logins/sessions is often a nightmare (I've done it but don't like doing it). Handling spam across multiple tools that allow user content, etc. There are big costs to single-purpose tools. For some folks the cost is worth paying.
I had the exact opposite reaction to Wordpress - I found it an excellent reference for studying how to build a great CMS. For me its code is concise and easy to follow. The time I spent with Wordpress was a great adventure in someone else's code... I think debugging WP is pretty fun!
agree, while it may have some technical limitations it is one of the most successful CMS's ever, and gaining in being a very successful open source program as well. I'm a bigtime WordPress user and really don't have any problems with it. Most of my websites load in under 2 seconds (with a lot of tweaking) so I really can't complain.
I can't remember where I read this but I think Google's new "gold standard" for load time is < 1s. A couple of years ago I think it was < 3s.
Perhaps two whole seconds fine for your needs, but to put in perspective your performance-is-fine claims in multiple posts in this thread: I won't go live with a site that doesn't render in under 150ms, because I consider doing worse than that disrespectful to my users and wasteful of their time. The amount of effort I have had to put in in the past to make WordPress perform even adequately has been disgusting.
I think the confusion is a page can render in 150ms but load time in the above comment was more about when the load event would fire on your site. 2 seconds for load event is pretty good. It's not google fast but it's not bad if your site has any images or loads css/js - most the WP sites I've ever dealt with have 50-60ms render times...
Two seconds to fire a load event would not be allowed out of the test environment anywhere I have worked.
correct, ttfb for instance on many servers is 1 second alone. A framework being rendered vs the entire load time of a website are 2 completely different metrics.
If this WP API thing gets traction and people start deploying lots of front end themes that rely on it rather than direct calls into WP's internal organs, it wouldn't be impossible to redo the core in any stack.
I spent two days replacing WordPress with custom PHP that does exactly what we need for our blog (read a bunch of static text from files), and then I never had to care about the horrors of WordPress (or worse, the plugins) again!
What struck me is that one of the benefits of the WP-API is that you could create a drop-in replacement for the server-side of Wordpress. Why? To move WP away from PHP.
Seriously, if the API is stable, why not just build something that matches it using a faster, cleaner language? The user gets the speed benefits, the developers get to start again from a clean(er) slate. The only hole in this idea is the shortage of cheap hosting which offers something other than PHP for dynamic websites.
Seriously, if the API is stable, why not just build something that matches it using a faster, cleaner language? The user gets the speed benefits, the developers get to start again from a clean(er) slate. The only hole in this idea is the shortage of cheap hosting which offers something other than PHP for dynamic websites.
As the article notes, the most likely way Wordpress will get faster on the server is HHVM.
I doubt very much that the WP team has any intention of moving away from PHP anytime soon (if ever). Yes, they could start again on a clean slate of code, but they'd also have to start again on a clean slate of the community. But the community is worth way more than the code.
WP-API is important so that Wordpress can continue to grow into more complex projects. Javascript front-ends are getting more popular, and if WP cannot feed data to them in a flexible and performant way, it will lose out to other content frameworks that can (for example, Drupal), or custom development of content stores.
I doubt very much that the WP team has any intention of moving away from PHP anytime soon (if ever). Yes, they could start again on a clean slate of code, but they'd also have to start again on a clean slate of the community. But the community is worth way more than the code.
WP-API is important so that Wordpress can continue to grow into more complex projects. Javascript front-ends are getting more popular, and if WP cannot feed data to them in a flexible and performant way, it will lose out to other content frameworks that can (for example, Drupal), or custom development of content stores.
"I doubt very much that the WP team has any intention of moving away from PHP anytime soon (if ever)."
You've misunderstood me. I didn't envision this move would be made by the WP team. Anyone with the prerequisite skills to build server software could do it. A new open-source project, a WP-compatible drop in replacement. Even just for environmental reasons it'd be worth it, imagine what a difference it would make if a significant portion of the world's websites switched to a more efficient solution.
You've misunderstood me. I didn't envision this move would be made by the WP team. Anyone with the prerequisite skills to build server software could do it. A new open-source project, a WP-compatible drop in replacement. Even just for environmental reasons it'd be worth it, imagine what a difference it would make if a significant portion of the world's websites switched to a more efficient solution.
It'd be nice to build a WPAPI layer on top of other CMSs. Plone is my favorite one, but it's not known for speed.
What other CMS is as easy to teach to end users, is free, and works 99% of the time? What other CMS can turn itself into an eCommerce store, blog, business website, magazine, etc with a few small tweaks?
I hear a lot of these comments from very well respected developers, but as a user and webmaster (not a developer) of WordPress I am very satisfied with it, and rarely see a WordPress site that runs slow, with the exceptions of poorly coded themes which will slow down ANY CMS.
I manage a lot of websites, probably 200 or so of them are WordPress. Over the last 5 years I've seen about 5 hacks, 3 were due to outdated plugins and 2 were brute forced. Backups are incredibly easy (file structure and database) for an end user with plugins, and maintenance for an average WordPress takes about 20 minutes per month.
I think this discussion is very positive in the fact that the core of WordPress is very outdated and has not really been touched in the last 5 years (or more?) or so. I'd love to see version 5 or 6 be a full re-write or even a partial rewrite of the main functions and core includes, perhaps even a more efficient language but that is not really my territory. The problem I see with all that is backwards compatibility. There are so many themes, plugins, and addons that depend on WordPress core hooks, I don't know how that could work seamlessly. I suppose that is what beta testing is for.
As I've already said in this thread, WordPress is a huge success in the mainstream and is gaining in popularity every day. 75 million WP sites last I checked vs a fraction of that in Drupal and Joomla.
Node is on the rise but is still a custom solution and not deployable unless you are a skilled developer with knowledge of the network stack.
We live in an age where end users want to be able to control their website backend. They want to blog, make changes to static pages, add images from events and even add their own products. Have you ever tried to teach someone to do this in Joomla and Drupal? I have, with success but it is 100x more difficult than WordPress.
I hear a lot of these comments from very well respected developers, but as a user and webmaster (not a developer) of WordPress I am very satisfied with it, and rarely see a WordPress site that runs slow, with the exceptions of poorly coded themes which will slow down ANY CMS.
I manage a lot of websites, probably 200 or so of them are WordPress. Over the last 5 years I've seen about 5 hacks, 3 were due to outdated plugins and 2 were brute forced. Backups are incredibly easy (file structure and database) for an end user with plugins, and maintenance for an average WordPress takes about 20 minutes per month.
I think this discussion is very positive in the fact that the core of WordPress is very outdated and has not really been touched in the last 5 years (or more?) or so. I'd love to see version 5 or 6 be a full re-write or even a partial rewrite of the main functions and core includes, perhaps even a more efficient language but that is not really my territory. The problem I see with all that is backwards compatibility. There are so many themes, plugins, and addons that depend on WordPress core hooks, I don't know how that could work seamlessly. I suppose that is what beta testing is for.
As I've already said in this thread, WordPress is a huge success in the mainstream and is gaining in popularity every day. 75 million WP sites last I checked vs a fraction of that in Drupal and Joomla.
Node is on the rise but is still a custom solution and not deployable unless you are a skilled developer with knowledge of the network stack.
We live in an age where end users want to be able to control their website backend. They want to blog, make changes to static pages, add images from events and even add their own products. Have you ever tried to teach someone to do this in Joomla and Drupal? I have, with success but it is 100x more difficult than WordPress.
Sorry to rain on this party but...
Wordpress is failing on mobile.
Most of the themes are poorly optimized for mobile. For example open http://wordpress.org/news on your phone - there's so much mobile fail happening here, from the hamburger menu and the poor use of space at the top to tiny fonts and navigation elements. Over at blog.wordpress.com there's other fail going on, like the performance of opening the menu top left. Both of these reflect the general state of Wordpress themes from my experience.
Meanwhile, aside from some app-based editing tools, Wordpress has completely failed to bring blog content to apps.
The #1 use case here is for app developers who won't content from their blog to be available somewhere in their app.
And actually it's not just Wordpress failing here. There's such a gap in the market that mobile marketing platforms like AppBoy are filling the gap with product features e.g. http://www.adweek.com/socialtimes/appboy-reveals-in-app-news...
Wordpress is failing on mobile.
Most of the themes are poorly optimized for mobile. For example open http://wordpress.org/news on your phone - there's so much mobile fail happening here, from the hamburger menu and the poor use of space at the top to tiny fonts and navigation elements. Over at blog.wordpress.com there's other fail going on, like the performance of opening the menu top left. Both of these reflect the general state of Wordpress themes from my experience.
Meanwhile, aside from some app-based editing tools, Wordpress has completely failed to bring blog content to apps.
The #1 use case here is for app developers who won't content from their blog to be available somewhere in their app.
And actually it's not just Wordpress failing here. There's such a gap in the market that mobile marketing platforms like AppBoy are filling the gap with product features e.g. http://www.adweek.com/socialtimes/appboy-reveals-in-app-news...
> Wordpress is failing on mobile.
I don't know much about WP, so I'm really curious, is it WP that is failing on mobile, or is it the poorly designed themes?
I don't know much about WP, so I'm really curious, is it WP that is failing on mobile, or is it the poorly designed themes?
To me it's really that Wordpress developers / community are not taking mobile seriously. Poorly mobile optimized themes are just a symptom of the problem.
The consequence is a generation of Mobile developers are ignoring Wordpress, at least in their apps. Wordpress needs to have a drop-in SDK that allows content from an app developers blog to be displayed in a friendly way in-app, plus push notifications / badges etc. to inform users of new content. How do you tell users about new features in your app for example?
Then there are some deeper questions to answer like blog comments - do they make sense on mobile at all? Most people aren't going to write more than a sentence on their phone. What about finding different ways to provide feedback? Yelp for example spend a long time soul-searching about whether to allow reviews from mobile - http://officialblog.yelp.com/2013/08/oh-snap-yelp-app-now-po... - I don't think they found the answer but they certainly saw the problem. But that's another story...
The consequence is a generation of Mobile developers are ignoring Wordpress, at least in their apps. Wordpress needs to have a drop-in SDK that allows content from an app developers blog to be displayed in a friendly way in-app, plus push notifications / badges etc. to inform users of new content. How do you tell users about new features in your app for example?
Then there are some deeper questions to answer like blog comments - do they make sense on mobile at all? Most people aren't going to write more than a sentence on their phone. What about finding different ways to provide feedback? Yelp for example spend a long time soul-searching about whether to allow reviews from mobile - http://officialblog.yelp.com/2013/08/oh-snap-yelp-app-now-po... - I don't think they found the answer but they certainly saw the problem. But that's another story...
100% poorly designed themes, WordPress does just fine on mobile and all of my websites pass Google's mobile testing tool which, is enough for me (and they look great.)
I do admit that there are probably way more bad themes out there than good, and that most WP 'developers' do not stick to the codex / standards and just want to make money on themes.
I do admit that there are probably way more bad themes out there than good, and that most WP 'developers' do not stick to the codex / standards and just want to make money on themes.
No-backend cuasi-static would be a new era. There is no reason for a dynamic CMS on sites that are updated twice a month and maybe reach 50k visits/mo; I am sure the vast majority of WP sites out there are of such nature.
Static CMS's are great for personal projects, or very tech-friendly clients, but most clients paying for a website want the ability to manage content in a user friendly way.
I'm sure the vast majority of WP sites have been built for a paying client.
I'm sure the vast majority of WP sites have been built for a paying client.
I've done a ton of WP sites, maybe two clients update themselves. Besides, who says a no-backend CMS cannot be as friendly to use?
This is true about infrequent updates - it may be more for providing the appearance of total control.
I would love to see a user-friendly universal app for managing static sites (Jeckyl, Docpad) that is something someone of my Mom's tech capability could use. (and let's be honest, WP itself is sometimes "way too much")
I would love to see a user-friendly universal app for managing static sites (Jeckyl, Docpad) that is something someone of my Mom's tech capability could use. (and let's be honest, WP itself is sometimes "way too much")
More than ultra-friendly I think what the static site CMS ecosystem is missing are tons of beautiful themes. Let's be clear about it: the client only sees and complains about the looks. Once we have enough themes out there it will take off. Lately I am playing with a homemade hack to use any html template on a static site generator....let's see how that turns out.
I'm running into this with a client.
They want a friendly easy way to manage a complex case management system, but they don't understand how some of interconnected relationships work between the data they want. So trying to cross that chasm, of explaining what they actually want implies for the data has been miserable. Somethings just aren't simple :(
They want a friendly easy way to manage a complex case management system, but they don't understand how some of interconnected relationships work between the data they want. So trying to cross that chasm, of explaining what they actually want implies for the data has been miserable. Somethings just aren't simple :(
Maybe this will help: always charge a monthly SLA b/c systems are not like a haircut that you sell and forget about it, systems are alive monsters. When clients complain about the SLA use this story:
You: Do you own a car a pay insurance?
Client: Yes (most likely answer)
You: Do you use the insurance?
Client: No (if client answers yes they are conceding the point in advance!)
You: But you pay for it regardless just in case you need it. Same deal with SLA contracts. Cars break, systems break.
that's true clients think they want a CMS system, the reality is however the one who does the updating is usually you.
That is why you would use a caching proxy like Varnish (or Squid) and/or a web-server cache module like mod_cache (Apache) for.
Using either of the above, you'd reduce the latency and increase the through-put of WP to the likes of hosting a simple HTML page on nginx.
The picture gets a bit more complicated with the back-end admin area, user logins, sessions, dynamic page parts, etc. And there are ways to either handle it or just bypass the caching layer for it, but for handling reader traffic, caching is the key regardless of which CMS you use.
Using either of the above, you'd reduce the latency and increase the through-put of WP to the likes of hosting a simple HTML page on nginx.
The picture gets a bit more complicated with the back-end admin area, user logins, sessions, dynamic page parts, etc. And there are ways to either handle it or just bypass the caching layer for it, but for handling reader traffic, caching is the key regardless of which CMS you use.
Yes, but I think the point being made, (which I agree with), is that a huge amount of sites using WP, or another CMS, are updated rarely, and would be simpler, faster, and more secure if they were static sites instead. Also, there are a number of amazing static site generators out there.
> maybe reach 50k visits/mo
Also, the more visits, the less of a need for a dynamic CMS.
Also, the more visits, the less of a need for a dynamic CMS.
Why so?
Static sites are trivially cacheable. Caching gets cheaper per request the higher the volume.
Presumably because you'd be more likely to be using Varnish or a CDN?
The majority of wp sites would be blogs. Features like comments are crucial here.
Disqus? Name a dynamic component of a website: there is a SAAS for it, normally free for small low-traffic sites.
That is not a good choice per se. If you use disqus you let some third party spy on your visitors, you give away content that belongs to your site to a random service and you require javascript for something as trivial as reading/writing comments. You might as well use Facebook or a random hosted service as your blog
Once, maybe twice every year you have this blog post of how WordPress will improve, will be rewritten to a modern foundation, will reinvent blogging plastered with the sympathetic "WordPress gets the job done but the foundation is horrible". Fast-forward a few months and WordPress releases a new version, the project to rewrite WordPress didn't gather enough momentum and there you are, slapping in another function_exists in your module and thinking "man, why did nobody ever improve this horrible house of cards?".
So far as I can tell, the actual meat and potatoes of Wordpress has been largely untouched for more than a decade. I first looked under the hood in 2004, last looked in I think 2013 or so. And basically it all seemed spookily familiar.
Wordpress is the triumph of style and marketing over all other considerations. Having managed a small fleet of Wordpress sites for over a decade, I am not a fan.
And I am not very optimistic about Grand Visions In Blog Posts. I've had a few of those myself.
Wordpress is the triumph of style and marketing over all other considerations. Having managed a small fleet of Wordpress sites for over a decade, I am not a fan.
And I am not very optimistic about Grand Visions In Blog Posts. I've had a few of those myself.
I can get behind WP-API and like that direction.
However, I can't wrap my mind around like React.js. Having a mental roadblock on even diving it to do prototypes with it to give it a whirl (which I often do with new libraries or languages even).
However, I can't wrap my mind around like React.js. Having a mental roadblock on even diving it to do prototypes with it to give it a whirl (which I often do with new libraries or languages even).
Try and ignore all of the flux stuff and any mention of immutable data - focus on React itself.
I'm sorry, but the logo on this blog is so creepy. Seriously.
I had a bigger problem with the domain name -- for some reason I didn't read it as "be the signal" but as "bethe signal," and wasted five minutes wondering if it was a clever reference to Hans Bethe (http://en.wikipedia.org/wiki/Hans_Bethe) that I was too dense to understand.
(god I'm such a nerd)
(god I'm such a nerd)
I gave my email address to someone last night who misheard it as Beaver Signal. Pretty sure I like yours better.
i think it's awesome
"the unkillable cockroach of the world wide web: PHP"
I'm biased but this is best quote I've heard in quite a while.
I'm biased but this is best quote I've heard in quite a while.
TurdPress is pretty much solely responsible for keeping PHP alive this long. So so many kids these days learn a little WordPress and tell people they're web developers.
It's the IE of blog platforms.
WP causes endless security problems for hosting companies. Even when it's locked down it's (often) still wide open, and most users don't know how to lock it down.
But it's never going to die, because ecosystem. Static alternatives are never going to take over, because they don't have gargantuan theme factories supporting them. And most users like pretty.
So I guess we're stuck with it for a while yet.
WP causes endless security problems for hosting companies. Even when it's locked down it's (often) still wide open, and most users don't know how to lock it down.
But it's never going to die, because ecosystem. Static alternatives are never going to take over, because they don't have gargantuan theme factories supporting them. And most users like pretty.
So I guess we're stuck with it for a while yet.
Nothing is ever really going to kill PHP or Wordpress so long as the communities designing other languages and frameworks approach the business case of the common nontechnical user with disdain.
This is nice to read. I just started looking into a playing with React... and then got the great idea to start recreating something like http://p2theme.com/ with React and WP-API. Good to see that I am on the right track ;) There is not much to it yet (still in prototype/PoC stage) but for those interested: https://github.com/alexciarlillo/react-wp
Cool!
The thing about WordPress is that for most clients you'll likely end up running on a managed WP server like WP Engine.
The vanilla WP environment means goodies like React (which requires V8 to compile on the server) and HHVM are not in the cards. But PHP and WordPress really doesn't need to be fast (just put it behind a CDN).
Isomorphic rendering over the WP-API is all you need - I've had a lot of benefit using logic-less templates like Handlebars on the client and the server.
The vanilla WP environment means goodies like React (which requires V8 to compile on the server) and HHVM are not in the cards. But PHP and WordPress really doesn't need to be fast (just put it behind a CDN).
Isomorphic rendering over the WP-API is all you need - I've had a lot of benefit using logic-less templates like Handlebars on the client and the server.
You don't need to build your React client-side JavaScript on the server. You build it on your development workstation and ship the resulting JavaScript bundle in your theme.
"PHP and WordPress really [don't] need to be fast"... until you're doing anything dynamic at all, and then they do. :-)
"PHP and WordPress really [don't] need to be fast"... until you're doing anything dynamic at all, and then they do. :-)
"One taste of React in front of WP-API, and I reckon the jQuery and Backbone era will be finished."
This seems to me like a bit of an exaggeration (or maybe just facetious).
This seems to me like a bit of an exaggeration (or maybe just facetious).
I think it is a bit of an exaggeration, but not entirely inaccurate. I am currently working on a large application UI re-write, we've moved to React, and JQuery was included from day one. The entire application uses JQuery exactly once as of today. (We're leveraging $.ajax) React solves a lot of the same issues JQuery does. We didn't purposely try avoiding JQuery, we just haven't needed it so far. That's a major change.
Check out superagent for all your $.ajax-replacing needs. :-)
https://github.com/visionmedia/superagent
https://github.com/visionmedia/superagent
I agree that React and all the sweetness it contains does have this effect when working on a large - or simply dynamic - application.
But all of the benefits of the React Virtual DOM don't really come into play if the content is static (like most WordPress sites). If no data is changing, you don't need observables to automatically update views, and the built in underscore.js templating will do a fine job.
But all of the benefits of the React Virtual DOM don't really come into play if the content is static (like most WordPress sites). If no data is changing, you don't need observables to automatically update views, and the built in underscore.js templating will do a fine job.
In this context, I meant it mostly about the WordPress admin back-end, but I wouldn't be awfully uncomfortable making the claim more broadly. :-)
It's unrealistic to compare WordPress php and Facebook php. Most website running WordPress do not need the optimization required to run facebook.
If there is something that slows down WordPress it's the database queries, the amount of external assets and bloated themes. There are more then files being downloaded for each requests and all served from the same server.
Throw in hhvm or any optimization on the code and you still have to deal with the other issues.
If there is something that slows down WordPress it's the database queries, the amount of external assets and bloated themes. There are more then files being downloaded for each requests and all served from the same server.
Throw in hhvm or any optimization on the code and you still have to deal with the other issues.
You definitely did not have a deep look at "how to optimize wordpress". It's a massive spaghetti piece of awful PHP that does A LOT of completely unnecessary work. Now as a smart VM, it's possible to reduce quite a bit this amount of work (inlining etc.) and the JIT coming from HHVM can come handy in here.
My blog spends about 10% average request time doing database work. The big WordPress sites I've worked on are generally about the same.
The database is not where raw performance opportunities lie on a sensibly built WordPress site.
The database is not where raw performance opportunities lie on a sensibly built WordPress site.
I was just reading about this...
http://wptavern.com/heroku-wp-a-template-for-installing-and-...
http://wptavern.com/heroku-wp-a-template-for-installing-and-...
I like the idea of a WP API. I guess in the future you could more easily build non-browser apps that utilize WP data. Of course, there's always going to be the people who don't very much like the whole front-end JavaScript MVC idea (Backbone, React, Angular, etc.), but there will still be the regular PHP themes for them to use.
My only wish is that a proliferation of horrible themes based on inefficient JS does not occur. Front-end MVC can be done right, but don't abuse it with bad code that gives the rest a bad name!
My only wish is that a proliferation of horrible themes based on inefficient JS does not occur. Front-end MVC can be done right, but don't abuse it with bad code that gives the rest a bad name!
I just wish there were a WP management API. Like, let me remotely do updates, backups, user administration etc. against a bunch of WP sites from a single console (or better yet, command line script), rather than having to log in to each one individually to do that stuff, which is a pain.
EDIT: So it turns out there's a third party project that kinda sorta does this: WP-CLI (http://wp-cli.org/). Anyone used it?
EDIT: So it turns out there's a third party project that kinda sorta does this: WP-CLI (http://wp-cli.org/). Anyone used it?
I've written batch scripts with WP-CLI and mysql to spin up new sites, from scratch, including database creations, install latest core, a suite of base plugins, install themes and create child themes, and configure some options. Works a treat.
Pantheon (hosting) provides a lot of tools for managing Drupal sites like this. Now that they also support hosting Wordpress sites, they may offer similar tools. Might be worth a look: getpantheon.com
Have you tried WP Multi-Site?
I use wp-cli pretty much every day at work
Note that a “regular PHP theme” could be built on the WP-API instead of the current horrible mess of functions and loops. I’m tempted to port a version of html5-blank-wordpress over to it…
This is not specific to Wordpress, you can apply the same to Drupal or any cms/framework able to send data in json
"Headless Drupal" is a growing idea in that community, and I believe how the new Tonight Show website was built--Drupal data store, JS front-end.
I really wish all of these similar ideas were to happen on Ruby and Rails.
Ruby need something similar to HHVM, progress on the RuJIT sponsored by Ruby Association looks like stalled. IronRuby ( or something similar ) on the new Microsoft CoreCLR will take years.
And Rails Core team, or DHH seems to be against the Rails API ideas.
Ruby need something similar to HHVM, progress on the RuJIT sponsored by Ruby Association looks like stalled. IronRuby ( or something similar ) on the new Microsoft CoreCLR will take years.
And Rails Core team, or DHH seems to be against the Rails API ideas.
I had read the post, thinking that there is a good new direction in wp. At the end, the only valuable thing for me, is rendering templates using the wp-api instead of the big mess of files and code that actually is. Also this way, you don't expose your wordpress install xD
[deleted]
All I want is a templating language in the WordPress core and I can live with all the other bad parts.
We could call it "Personal Hypertext Processor". It'll be great.
The meme that PHP is a templating language may be technically accurate, but as a templating language, raw PHP is so terrible that the thought of using it as such should also be dismissed outright.
There is nothing great about this sort of thing:
And then somebody decides to drop php variables directly into javascript and css...
No. No no no.
There is nothing great about this sort of thing:
<?php for($i=0; $i<$num_rows; $i++) { ?>
<div><?php echo htmlspecialchars($db_row[$i]['field']); ?></div>
<?php } ?>
And then somebody decides to drop php variables directly into javascript and css...
No. No no no.
You forgot `ENT_QUOTES | ENT_SUBSTITUTE` on `htmlspecialchars`, it's perilous to use directly in every single place. But after embracing `short_open_tag` (or `<?=` is always available in 5.4+), foreach, `\PDO::FETCH_OBJ` and a helper function;
<?php foreach($row in $results) { ?>
<div><?=h($row->field)?></div>
<?php } ?>
>You forgot `ENT_QUOTES | ENT_SUBSTITUTE` on `htmlspecialchars`, it's perilous to use directly in every single place.
I would have added it in real code... but manually escaping everything is still what you have to do with raw php. At the very least, have something to recursively escape an array (keys and values) before it gets dumped onto the page.
Twig at least lets you escape by default (and you don't have to worry about double-escaping), but the equivalent wouldn't be much less verbose. Twig's syntax is a bit cleaner in couple of places I think, and it lets you use array bracket syntax [] in versions of PHP too old to support it natively.
I would have added it in real code... but manually escaping everything is still what you have to do with raw php. At the very least, have something to recursively escape an array (keys and values) before it gets dumped onto the page.
Twig at least lets you escape by default (and you don't have to worry about double-escaping), but the equivalent wouldn't be much less verbose. Twig's syntax is a bit cleaner in couple of places I think, and it lets you use array bracket syntax [] in versions of PHP too old to support it natively.
{% for row in results %}
<div>{{ row.field }}</div>
{% endfor %}
Meh. With short tags, and a helper function which can be abstracted away in your stack, you can write the following:
<? foreach($row in $results): ?>
<div><?= $row['field'] ?></div>
<? endforeach ?>
At that point, though, once you no longer have to echo and escape everything, you have a templating framework on top of PHP. The number and complexity of 'helper functions' differs between this and something like Twig, but it's still using abstractions to manage what PHP doesn't do well on its own.
A lot of self-described minimalist templating languages do wind up looking a lot like that. I personally don't want to see raw PHP in anything i'm calling a template but to each their own.
A lot of self-described minimalist templating languages do wind up looking a lot like that. I personally don't want to see raw PHP in anything i'm calling a template but to each their own.
Well, it's still strictly better than all the templating engines used in PHP for... well, no good reason. You have equivalent, or sometimes even shorter, syntax in PHP, and with templating engines, it always ends up with developers working around engine's limitation in some ways. Why use something underpowered for the task where you could use an actual programming language?
"Unless you’ve goofed something up, the slowest part of your PHP-based application should be PHP itself. Other parts of your stack may exhibit scaling problems that affect response times, but in terms of raw performance, PHP is the piggy in the middle of your web server and data stores."
I completely disagree. PHP is rarely the issue and I don't know where people get this idea that PHP is slow. Unless you're calculating the flight trajectory to Mars, the main bottleneck of WordPress is MySQL. Fill up you PHP application with microtimers, you'll see PHP only needs milliseconds to do its job even without caching. If there's anything slowing you down, you're waiting for MySQL or Curl or some external application, which is unnecessary most of the time if you designed the application properly.
I completely disagree. PHP is rarely the issue and I don't know where people get this idea that PHP is slow. Unless you're calculating the flight trajectory to Mars, the main bottleneck of WordPress is MySQL. Fill up you PHP application with microtimers, you'll see PHP only needs milliseconds to do its job even without caching. If there's anything slowing you down, you're waiting for MySQL or Curl or some external application, which is unnecessary most of the time if you designed the application properly.
Post links and downvote all you want. Drop in the microtimers yourself and see where your PHP apps are really spending time.
I run the numbers and monitor New Relic charts on large WordPress sites all the time. Yes, some request time is spent doing I/O, but the majority of request time in any healthy PHP (or Ruby, Python, etc.) site is spent in PHP.
(When more time is spent elsewhere, you have a problem that needs to be fixed. For example, waiting for I/O because you've done something silly with a database query or you've pushed it beyond its scaling limits and everyone's waiting for I/O.)
(When more time is spent elsewhere, you have a problem that needs to be fixed. For example, waiting for I/O because you've done something silly with a database query or you've pushed it beyond its scaling limits and everyone's waiting for I/O.)
I wouldn't trust New Relic charts. Maybe that is the source of all this disinformation. Get in the actual code and time everything yourself. If PHP is actually slow, you should be able to isolate the problem, like a loop within a loop that's just bad coding. You can make any language go slow with bad code. Check out my blog post on this subject:
http://pjbrunet.com/microtimers-on-hooks-to-measure-wordpres...
http://pjbrunet.com/microtimers-on-hooks-to-measure-wordpres...
"I wouldn't trust New Relic charts."
Good for you.
Putting microtimers throughout your code is like using printf for "debugging": It's banging rocks together. Use xdebug, xhprof, New Relic, something sensible. You'll learn much more about your stack.
Good for you.
Putting microtimers throughout your code is like using printf for "debugging": It's banging rocks together. Use xdebug, xhprof, New Relic, something sensible. You'll learn much more about your stack.
I suspect if you are using scattered microtime() calls you're not getting the full picture. You should at least try profiling it with Xdebug/xhprof.
If all the UI will be delegated to JS, what HTML will WP produce? An empty body while React is loading?
It's a service-oriented architecture. The API is not your web server.
You can use something like Ambidex to render HTML from your React components on the web server, backed by your WP-API.
------
More info (in video form): https://www.youtube.com/watch?v=yaymfLj5tjA
Ambidex (one of many ways you could implement this paradigm): https://github.com/appsforartists/ambidex
You can use something like Ambidex to render HTML from your React components on the web server, backed by your WP-API.
------
More info (in video form): https://www.youtube.com/watch?v=yaymfLj5tjA
Ambidex (one of many ways you could implement this paradigm): https://github.com/appsforartists/ambidex
WordPress is a great product? PHP is the "cockroach of the world wide web"?
Who's next up on the soapbox?
Who's next up on the soapbox?
IMO, WordPress could benefit by shifting to Node.js.
I feel reasonably sure you're just trolling - or attempting a joke. However.
The reason WP did - and does - so well is that for most hosts, it's very easy to deploy, does what most sites need, and is reasonably easy to teach. It's also trivially extensible, within it's somewhat limited framework.
So any other PHP application (various shopping carts, etc) can be easily put on top of a normal WP site, and with a little glue, made to be a plugin that "just works" (most of the time. And occasionally makes the whole site return a completely empty page and no errors...).
However, there is going to be a general decline in PHP being easier to deploy than other server site languages, an interesting proposition might be to make a language agnostic WP 'database core'.
Currently, it's all a bit of a mess underneath - lots of the system still thinks it's a pure blogging engine, lots of the internal functions are aimed at that, etc.
But the core idea of the data model is
[post] >- [categories] and [metadata] which can be attached to those somewhat ad hoc. Posts can be different 'types', dependant on the current theme (yeah - WP is kind of messed up).
But the idea of all your content pieces are roughly equivalent, so a blog post is basically the same thing as a static page, is basically the same thing as a custom-post-type-video, cat picture, etc, is reasonably powerful.
If the core of the database concepts were codified and 'locked down', and the PHP back end simplified down to being a RESTful interface on top of it (JSON for the back end, pretty HTML for the front end) + a few oddments, then that could be ported to any number of different languages quite easily.
This way mysql could be factored out, if desired, or PHP, and a lot of the concepts would still keep on working.
The trouble is you lose the WP 'it's PHP, so a custom theme can do ANYTHING!!!!! magic'. Which might be good for security, but bad for popularity.
If the core were codified enough, then many plugins and theme control stuff could simply become front-end javascript plus templating files, which would be good though. (And back-end agnostic).
The reason WP did - and does - so well is that for most hosts, it's very easy to deploy, does what most sites need, and is reasonably easy to teach. It's also trivially extensible, within it's somewhat limited framework.
So any other PHP application (various shopping carts, etc) can be easily put on top of a normal WP site, and with a little glue, made to be a plugin that "just works" (most of the time. And occasionally makes the whole site return a completely empty page and no errors...).
However, there is going to be a general decline in PHP being easier to deploy than other server site languages, an interesting proposition might be to make a language agnostic WP 'database core'.
Currently, it's all a bit of a mess underneath - lots of the system still thinks it's a pure blogging engine, lots of the internal functions are aimed at that, etc.
But the core idea of the data model is
[post] >- [categories] and [metadata] which can be attached to those somewhat ad hoc. Posts can be different 'types', dependant on the current theme (yeah - WP is kind of messed up).
But the idea of all your content pieces are roughly equivalent, so a blog post is basically the same thing as a static page, is basically the same thing as a custom-post-type-video, cat picture, etc, is reasonably powerful.
If the core of the database concepts were codified and 'locked down', and the PHP back end simplified down to being a RESTful interface on top of it (JSON for the back end, pretty HTML for the front end) + a few oddments, then that could be ported to any number of different languages quite easily.
This way mysql could be factored out, if desired, or PHP, and a lot of the concepts would still keep on working.
The trouble is you lose the WP 'it's PHP, so a custom theme can do ANYTHING!!!!! magic'. Which might be good for security, but bad for popularity.
If the core were codified enough, then many plugins and theme control stuff could simply become front-end javascript plus templating files, which would be good though. (And back-end agnostic).
I think about the future of WordPress a lot. Like what would WP look like if it was mostly JS? When I look at all the front-end developments (React etc), it's really hard to gauge. On one level I'd love to see things become more framework agnostic and flexible. The json api in theory frees up a lot of restrictions in what devs can do with WP running as a backend. Even cooler if we can switch out Mysql with other kinds of databases.
But it's kind of interesting, for all PHP's warts, it has made it so easy to build things, allowing a huge amount of plugins and themes to develop. For all these years, devs didn't need to worry about the latest library, from backbone to angular, from react to mithril etc. It's the stability and ease of access that has been so important to growth.
Now that the web is so javascript oriented it's really compelling to just think about how WP can adapt to it. But a big push toward adopting new methodologies just strips away the number one reason to develop with WordPress: the huge ecosystem that has solutions coded with PHP. And if you are going to create that rift, you might as well start with some other platform.
But it's really hard to pick a winner now, React for example, could easily be overtaken by another lib in a years time. We're unsure how Nodejs is going to develop. The json API's current state is not superfast or fully developed yet.
I sometimes wonder that we're underestimating the advantages of having something stable like PHP continuing to run at least part of the show. For example, I have yet to see any kind of theme (A WP theme or otherwise) coded with some kind of front-end oriented mvc setup that results in a qualitatively superior site experience.
But it's kind of interesting, for all PHP's warts, it has made it so easy to build things, allowing a huge amount of plugins and themes to develop. For all these years, devs didn't need to worry about the latest library, from backbone to angular, from react to mithril etc. It's the stability and ease of access that has been so important to growth.
Now that the web is so javascript oriented it's really compelling to just think about how WP can adapt to it. But a big push toward adopting new methodologies just strips away the number one reason to develop with WordPress: the huge ecosystem that has solutions coded with PHP. And if you are going to create that rift, you might as well start with some other platform.
But it's really hard to pick a winner now, React for example, could easily be overtaken by another lib in a years time. We're unsure how Nodejs is going to develop. The json API's current state is not superfast or fully developed yet.
I sometimes wonder that we're underestimating the advantages of having something stable like PHP continuing to run at least part of the show. For example, I have yet to see any kind of theme (A WP theme or otherwise) coded with some kind of front-end oriented mvc setup that results in a qualitatively superior site experience.
Is the database not the bottleneck? Especially with the way wordpress stores "post meta data" with key and value columns it seems that the joins could get a bit ugly.