
Another new era of WordPress - xngzng
http://bethesignal.org/blog/2015/02/27/new-era-wordpress-hhvm-rest-react/
======
grwgreg
"Unless you’ve goofed something up, the slowest part of your PHP-based
application should be PHP itself."

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.

~~~
jdub
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.)

~~~
Rapzid
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.

------
lolatu54
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 :)

~~~
SwellJoe
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...

~~~
mtbcoder
"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.

~~~
SwellJoe
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.

------
ZenoArrow
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.

~~~
snowwrestler
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.

~~~
ZenoArrow
"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.

------
BorisMelnik
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.

~~~
harryf
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](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...](http://www.adweek.com/socialtimes/appboy-reveals-in-app-news-
feeds-to-increase-click-through-rates/544791)

~~~
rytis
> 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?

~~~
harryf
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...](http://officialblog.yelp.com/2013/08/oh-snap-yelp-app-now-
post-reviews-straight-from-your-mobile-device.html) \- I don't think they
found the answer but they certainly saw the problem. But that's another
story...

------
bikamonki
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.

~~~
deanotron
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.

~~~
pgeorgi
The backend could be dynamic, creating static html for the frontend. Which is
essentially, what the numerous caching plugins are doing, just in a very
convoluted way.

~~~
nodata
and what movabletype does.

------
pearjuice
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?".

------
jacques_chester
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.

------
thebouv
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).

~~~
colinramsay
Try and ignore all of the flux stuff and any mention of immutable data - focus
on React itself.

------
maratd
I'm sorry, but the logo on this blog is so creepy. Seriously.

~~~
smacktoward
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](http://en.wikipedia.org/wiki/Hans_Bethe))
that I was too dense to understand.

(god I'm such a nerd)

~~~
jdub
I gave my email address to someone last night who misheard it as Beaver
Signal. Pretty sure I like yours better.

------
rlander
"the unkillable cockroach of the world wide web: PHP"

I'm biased but this is best quote I've heard in quite a while.

~~~
skrowl
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.

~~~
TheOtherHobbes
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.

~~~
krapp
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.

------
ciarlill
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/](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](https://github.com/alexciarlillo/react-wp)

~~~
jdub
Cool!

------
deanotron
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.

~~~
jdub
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. :-)

------
bobloblaw02
"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).

~~~
tyleregeto
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.

~~~
jdub
Check out superagent for all your $.ajax-replacing needs. :-)

[https://github.com/visionmedia/superagent](https://github.com/visionmedia/superagent)

------
jetskindo
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.

~~~
fijal
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.

------
omg_ketchup
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-running-
wordpress-on-heroku)

------
dustin1114
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!

~~~
smacktoward
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/](http://wp-cli.org/)). Anyone used it?

~~~
bwb
wp cli is the bomb, try it, it rocks!

~~~
crxgames
Very much this.

------
audessuscest
This is not specific to Wordpress, you can apply the same to Drupal or any
cms/framework able to send data in json

~~~
snowwrestler
"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.

------
ksec
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.

------
galigan
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

------
sdnguyen90
All I want is a templating language in the WordPress core and I can live with
all the other bad parts.

~~~
jacques_chester
We could call it "Personal Hypertext Processor". It'll be great.

~~~
krapp
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:

    
    
        <?php for($i=0; $i<$num_rows; $i++) { ?>
        
            <div><?php echo htmlspecialchars($db_row[$i]['field']); ?></div>
        
        <?php } ?>
    

repeated ad-nauseum across hundreds of files.

And then somebody decides to drop php variables directly into javascript and
css...

No. No no no.

~~~
mappu
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 } ?>
    

Is it really longer/worse than the equivalent twig/smarty/handlebars ?

~~~
krapp
>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.

    
    
       {% for row in results %}
         <div>{{ row.field }}</div>
       {% endfor %}
    

Of course this doesn't include the added complexity of an entire framework
implementing its own language running on top of everything but still, the
environment is a bit more sane.

~~~
whichdan
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 ?>
    

(Assume the helper function maps htmlspecialchars over an array returned by
PDO::FETCH_ASSOC.)

~~~
krapp
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.

------
pjbrunet
"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.

~~~
jdub
c.f.
[https://news.ycombinator.com/item?id=9121008](https://news.ycombinator.com/item?id=9121008)

~~~
pjbrunet
Post links and downvote all you want. Drop in the microtimers yourself and see
where your PHP apps are really spending time.

~~~
jdub
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.)

~~~
pjbrunet
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-wordpress-
performance/)

~~~
jdub
_" 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.

------
teabee89
If all the UI will be delegated to JS, what HTML will WP produce? An empty
body while React is loading?

~~~
bsimpson
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](https://www.youtube.com/watch?v=yaymfLj5tjA)

Ambidex (one of many ways you could implement this paradigm):
[https://github.com/appsforartists/ambidex](https://github.com/appsforartists/ambidex)

------
jacobbudin
WordPress is a great product? PHP is the "cockroach of the world wide web"?

Who's next up on the soapbox?

------
arxpoetica
IMO, WordPress could benefit by shifting to Node.js.

~~~
deckiedan
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).

~~~
pknight
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.

