Tags: Wordpress »»»» Node.JS »»»» Drupal
Supposedly the Wordpress team is migrating Wordpress from PHP to Node.js.
Supposedly the Wordpress team is migrating Wordpress from PHP to Node.js. That astonishing bit of news
comes from news.sys-con.com, but the evidence presented isn't exactly compelling. He refers to a recent blog post by Matt Mullenweg, CEO of Automattic, praising Node.js and how the Automattic team had used Node.js in developing Calypso. He also refers to
the architectural gains I discussed yesterday - microservice architecture can make for a cleaner overall system, and more. While the prospect of completely switching Wordpress from PHP to Node.js seems extremely daunting, it's possible the Wordpress team will approach this in piecemeal fashion (if they do it at all).
Wordpress has seen years of successful use by zillions of websites. Wordpress is perhaps the most popular website platform. You might think "Why mess with success?"
In Mullenweg's blog post he makes the case that Wordpress is being bogged down by years of baggage due to the need to maintain compatibility. Perhaps part of that baggage is PHP itself, but the rest is the architecture of Wordpress. The rapid move towards mobile devices, highly interactive services, etc etc, the architecture of systems like Wordpress must drastically change in order to keep up.
The inclusion of support for REST API's in Wordpress 4.4 is a big step in that direction. But, the basic architectural paradigm doesn't suit itself well to mobile oriented web services, because such mobile apps require a highly transactionally oriented service architecture.
Why?
First you have to ask "Why" - because the task of recasting the years of knowledge baked into Wordpress is not something to be undertaken lightly.
I'd suggest these points:
- Node.js architecture is more suited to the modern web than most any other language.
- While the PHP team is redesigning/modernizing PHP, JavaScript and Node.js don't carry the sort of baggage that PHP carries
- JavaScript on both server and client finally implements the long time dream of the same language at all layers of the application stack
- Node.js shines brightly when presented with highly transactional workloads.
Big hurdle - Node.js hosting is rare
The big advantage of PHP is you can get PHP hosting from zillions of web hosting companies. That makes the Wordpress 5-minute install a piece of cake. Node.js hosting is rare ... meaning the mom-and-pop self-hosted Wordpress websites (like my own
LongTailPipe blog) would be incredibly harder to self-host like we currently do.
Of course if Wordpress were to switch to Node.js, the hosting companies would be highly encouraged as a result to develop simple easy-to-use Node.js hosting support.
Did Mullenweg really promise a switch to Node.js?
His blog post (linked above) does not make an explicit promise of this sort. Instead the entire post spends its time praising the approach used in Calypso, to split the administrative screens out to a separate application that talks with
He talked about how the administrative backend of Wordpress hasn't changed much in years -- "The basic paradigms of wp-admin are largely the same as they were five years ago."
He talked about how the current design of Wordpress and the inability to make major changes are holding it back -- "that an incremental approach wouldn’t give us the improvements we needed, and that two of the things that helped make WordPress the strong, stable, powerful tool it is — backward compatibility and working without JavaScript — were actually holding it back."
The Calypso project grew out of the idea to experiment with this question -- "What would we build if we were starting from scratch today, knowing all we’ve learned over the past 13 years of building WordPress? "
Therefore, it seems that Mullenweg is implying that Wordpress will sooner-or-later switch to Node.js on the server -- maybe -- but it won't be a wholesale change done all at once. That's good, because there's too much institutional knowledge baked into Wordpress Core to switch in any kind of stable manner.
My recommendation for how the Wordpress community should approach this idea
I'm a long-time Drupaler (this blog runs on Drupal), who has written a book about Node.js application development (see book cover image in sidebar), who has developed
a pseudo-CMS written in Node.js, and who has done a significant amount of work with Wordpress this year, that includes getting a Wordpress plugin into the Wordpress.org repository. Ergo, I have some background with which to make some reasonable suggestions.
The key thing is to not do this all at once. Instead the team should do it one piece at a time.
For each piece of Wordpress do something like this:
- In the PHP version of Wordpress: for a given functional segment, wall it off the code into a separable module
- Make a well defined API for the module
- Strictly enforce rules that all other code within Wordpress only use that API
- Extend the API as needed to support the use-cases existing in Wordpress code
- Have a configuration mechanism so that this separable code module can be replaced with an external module which implements the same API
- Implement in Node.js such a module
This way Wordpress Core can organically move towards a modular structure, and the Wordpress team can continue experimenting with the best way to break up Wordpress while maintaining the institutional knowledge baked into the existing code. Additionally, as pieces of Wordpress become separable modules, the Wordpress team should be able to reap some efficiency benefits.
An example that might be interesting is the user account management system. If that were a separable service, the same user accounts could be shared among multiple websites. The default for Wordpress would be to use a local user account management system. For more complex Wordpress sites spanning multiple Wordpress instances, a "remote" user account management service could be used.
Another thing to consider is one of the big changes made by the Drupal team in Drupal 8. That is to separate out configuration data from the database, and instead store it as YAML files in the file system. They recognized that putting configuration data into the database made it much harder to treat a website as buildable code, and for example have separate easily managed development and staging and live websites.
