"Unless you’ve goofed something up, the slowest part of your PHP-based application should be PHP itself."<p>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.
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.<p>I don't mind PHP though :)
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.<p>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.
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?<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.
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.<p>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.<p>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.<p>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).
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 <a href="http://p2theme.com/" rel="nofollow">http://p2theme.com/</a> 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: <a href="https://github.com/alexciarlillo/react-wp" rel="nofollow">https://github.com/alexciarlillo/react-wp</a>
The thing about WordPress is that for most clients you'll likely end up running on a managed WP server like WP Engine.<p>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).<p>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.
"One taste of React in front of WP-API, and I reckon the jQuery and Backbone era will be finished."<p>This seems to me like a bit of an exaggeration (or maybe just facetious).
It's unrealistic to compare WordPress php and Facebook php. Most website running WordPress do not need the optimization required to run facebook.<p>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.<p>Throw in hhvm or any optimization on the code and you still have to deal with the other issues.
I was just reading about this...<p><a href="http://wptavern.com/heroku-wp-a-template-for-installing-and-running-wordpress-on-heroku" rel="nofollow">http://wptavern.com/heroku-wp-a-template-for-installing-and-...</a>
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.<p>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 really wish all of these similar ideas were to happen on Ruby and Rails.<p>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.<p>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
"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."<p>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.