This blog started its life as a WordPress blog, but on a previous site, I had actually migrated from my custom blog framework over to WordPress back in 2008 or so. Even back then, WordPress had taken over the blogging world and its robust plugins did much more than I could have tried to code in my spare time.
So I was happily surprised to hear that WordPress launched Calypso, their rewrite of the WordPress admin interface as an SPA, with React and node and babel and the rest of the usual suspects that make up the modern front-end tech stack.
On one hand, I can see why they were motivated to rebuild WordPress. The current code carries a decade’s worth of legacy, and debugging random WordPress issues—usually by diving into the source—is at best time-consuming and at worst confounding. If there were overarching architectural principles beyond the WordPress loop, they were lost to time and programming evolution.
The choice to move to an SPA, though, was a huge decision. I applaud it for many of the same reasons that Matt Mullenweg lists out in his announcement: SPAs, once loaded, provide a speedier user experience that’s usually much easier to model and code completely on the client. They also took this opportunity to clean up some processes, and I suspect the engineers working on WordPress are much happier to build on top of up-to-date tools and technologies.
The major benefit I want to highlight is that SPAs mandate a clear API boundary1. Clear APIs enable the right levels of abstraction between client and server, and forces a separation of concerns between the view, user interactions, and manipulation of the underlying data. Given how easy it is for to mix together business logic and views within the same files in PHP, this is a huge step forward in building a maintenable, scalable codebase.
That said, I’m not looking forward to having to modify this theme once Automattic makes the same move to its reader-facing bits.