Three years ago we sat down and tried to imagine what WordPress might look like if it was rebuilt from the ground up using modern technology - purely focused on publishing. It was an amazing problem to mull over, and one which we spent a long time thinking about. Eventually we came to the conclusion that the best possible way to do it would be entirely in JavaScript, specifically using Node.js. We called it Ghost.

It’s going pretty well so far, but our downfall was predicted before we had even begun. The usual “Ghost will never be as ubiquitous as WordPress because it can’t be installed on shared hosting” — comments were made regularly (up until just a few days ago) about how hard it was to install Ghost relative to WordPress and its auto-installer glory.

But we never wavered in our stance, and we stayed true to our belief that the choice of technology we made had the best and the brightest future ahead of it.

As we launched our hosted platform, Ghost(Pro), I answered our most frequently asked question: Why doesn’t Ghost work on shared hosting?

Ten years ago, a little platform called WordPress launched into the world and started growing in popularity at a rate of knots. At the time, hosting PHP was not as trivial as it is today. There were a few companies who did it well, but getting everything up and running was a struggle at best.

As time went on, and more popular PHP platforms started popping up (Drupal, Joomla, and so on) - the hosting industry evolved to cater for the users of those platforms; making one-click installers and simple control panels which meant everyone could get up and running really easily. Today, we pretty much take for granted how easy this process has become.

Now, as the world shifts towards new technologies (like Node.js - which is what Ghost is built on) the hosting industry is adapting again. This is a very straightforward case of supply and demand. The more demand there is for hosting a technology due to popular applications built on it - the more hosts support and offer hosting for this technology.

Node.js hosting is a young but incredibly vibrant industry. In some very abstract way, you could compare it to PHP hosting 10 years ago.

Now that the world’s largest Content Management System is going in the same direction, there could be no better validation that decision we made 3 years ago was the correct one. We’ve fucked up a lot of things since Ghost started, and we’ve learned from all of them, but I’m very pleased we got this one right.

Overall this move is huge, both for the WordPress ecosystem, as well as open source as a whole.

The Future of WordPress

For anyone who was surprised by the announcement - you haven’t been paying attention. Matt has been talking about JavaScript being the future of WordPress for 2 years at every WordCamp and conference he’s been to. I first heard about the existence of Calypso about 14 months ago, and have been looking forward to seeing it ever since. It did make this year’s accidentally ironic April fools gags all the more amusing, though.

For anyone who think this is just “A Mac App for WordPress.com” – you’re still not paying attention. This is the future of WordPress, and it has the potential to be an amazing one.

I’ll throw my (optimistic) hat into the ring and say that WordPress 5.0 will be entirely, or almost entirely written in JavaScript. The impending separation of client and server with an API will solve a lot of backwards compatibility baggage.

It’s important to point out, however, that Calypso is the single biggest vote of no-confidence in the existing WordPress architecture in the history of the platform. This comes after years of Matt saying “If you think WordPress doesn’t scale, just take a look at the 12million sites we power with WordPress.com – or major news websites like Mashable”.

So a lot of people are surprised by the announcement. If there’s one core problem that WordPress faces, it’s the persistent cloak and dagger of ambiguity. As many before me have identified, the lack of leadership and transparency around the long term roadmap for WordPress is consistently detrimental to its macro-economy. This is something that really needs to be addressed.

The reality distortion field has always conveniently ignored the fact that WordPress.com scales because it hasn’t run on WordPress core code for a very, very long time – and major news sites like Mashable largely use WordPress as a front end while running a custom (In Mashable’s case: Node.js) back end.

This new technology stack is an affirmation, finally, that the technical debt which everyone has been talking about for 5 years isn’t a figment of our collective imagination. And that it’s finally taking steps to be fixed. But (of course) it’s being presented as a revelation rather than an admission.

How to React

If there’s one doubt I have about the future of Calypso, it’s React. This is an area marred with subjective opinions, so let me give some context to qualify mine:

JavaScript frameworks are vastly different from one another. It’s almost bizarre that they’re categorised under the same term at all. While people constantly try to compare them to one another, it’s usually a relatively fruitless case of apples and oranges. And puns.

To use a very simplistic metaphor, Ember.js as a framework is a lot like Lego. You have a box of predefined blocks which are specifically suited to ambitious web applications, and you put them together to build your front end. The technology is good. But that’s almost tertiary to the biggest benefit of all for an open source project: All of the Lego pieces are the same no matter what Ember application you work on.

As an Ember developer, when you jump between Ghost, Discourse and your own Ember projects - you are immediately at home. Everything is the same right down to the directory structure. This dramatically lowers the barrier to entry for new developers.

The downsides? Well, if you’re not building an ambitious web application - the Lego pieces provided by Ember probably won’t suit you, and you’re going to have a bad time. Equally, you’re limited to just the blocks which Ember provides. If you start trying to invent your own shit instead of using Ember’s blocks, you’re going to have a bad time.

Angular.js, as a contrasting example, is more like a plastic-injection mould. Rather than a set of predefined blocks to use, you have a machine to create your very own blocks, and then use them. Sound awesome? It is. It’s an incredibly powerful framework which basically allows you to build what you want, how you want, when you want, no matter what type of project it is.

The downsides? Complexity. With an infinite number of possibilities and an infinite number of applications, no two projects are close to being the same. Angular projects have different shaped blocks, different structures, and entirely different ways of doing things all round. When you start working on an existing Angular app, it’s a much higher bar to entry.

So what’s React like? To extend the same metaphor, it’s even further down the road than Angular. A bit like a block of clay. It’s a flexible library which can be squeezed in around an existing custom structure to do simple things, very quickly. But… things can get messy very fast, too.

So how do you determine which is right for any given project?

There are many factors to consider, but two predominant influences stand out as most significant. First, the specification/requirements of the product itself and what’s being created. Second, the makeup and perspective of the team who will be using the tooling in question.

The first factor is often overlooked as people choose their favourite tool rather than the best tool for the job at hand, but it’s still talked about pretty regularly. The second is almost never acknowledged.

A year ago, when we were having an open discussion about which front-end framework to implement in Ghost, Sebastian and I attended a local JavaScript meetup where a group of developers from both Angular.js and Ember.js had both offered to create a mock implementation of the Ghost admin area and explain how they worked in a short talk.

The Ember.js presentation was first, and we listened keenly as we watched slides and a working demo of the Ghost admin area recreated Ember. It was a smooth talk, and there were a few good questions at the end about how the prototype could be adapted further into a more sophisticated end result.

The Angular presentation came next. The presenter was explaining a couple of the initial structural choices he’d made around the implementation, when a hand in the audience went up. “Why” it was asked “have you done it like this?”. The speaker and the interruptor went back and forth a for a while on why he’d chosen this particular way of doing things, neither agreeing with one another, before a second audience member got involved, and a third. The discussion went on for a full 10 minutes about multiple different possible implementations of the same functionality. We were only on the third slide.

Popup debates like this continued throughout the evening and turned what would normally have been a 15 minute talk, into a 40 minute series of heated debates. Having come into the evening with an open mind geared toward learning about both frameworks, Sebastian and I turned to each other afterwards and said “We can’t use Angular” at almost exactly the same time.

When you work in either a small team or a closed team – it’s quite easy to overcome these issues. Everyone gets on the same page about how to do something, and then gets shit done. A flexible tool is a huge advantage when everyone is in agreement.

Conversely, when you have a large, open, diverse team of contributors from all over the world – with different backgrounds, motivations and skillsets – flexibility invariably ends up creating immense confusion.

One of the most important reasons that we ultimately chose Ember was precisely because it is so opinionated and, at times, inflexible. Because in a fully open source team, that’s a huge advantage. There is a definitive right or wrong way to do things in our client-side app, and it is exactly the same as every other Ember app. We never need to have any debates or discussions about implementation. The framework puts us on the same page.

As anyone who has ever painted a bikeshed before will attest: The cognitive benefit of this simply cannot be overstated. It makes open development so much more cohesive.

It appears, at least from the outside, that Automattic selected React based on their own internal needs and biases without any specific thought to how the decision would translate into public development after releasing Calypso as open source. While this was great for 20 months of private work, I think it will present a serious - though not insurmountable - obstacle to bringing this stack into the rest of the WordPress ecosystem.

React, as a view layer which mixes arbitrary JavaScript components in with HTML and CSS, is a predictable choice for a team which is used to doing the same things with arbitrary snippets of PHP. Unfortunately, the pitfall of it being very easy for everything to turn into a giant spaghetti mess is a constant for both.

Significantly, this is a pitfall which WordPress has always dramatically failed to overcome.

It will take a great deal, here, to prevent history from repeating itself.

What Should WordPress be Used for?

While Calypso is a pretty major step toward a technology upgrade, it doesn’t offer any progress toward addressing WordPress’ identity crisis. To understand what I mean, answer the following question: What is WordPress for?

For years WordPress has flipped and flopped without consciously pivoting or focusing. At various points over the last 5 years it has tried directly and indirectly to compete with Drupal, Facebook, Tumblr, SquareSpace, Shopify, Wix and Medium. All without ever focusing for long enough to succeed at one before moving on to the next.

The only constant has been following, rather than leading, at each stage.

It’s very hard for the core community and the wider WordPress industry to rally around any sort of vision or goal when there is none evident beyond “75% to go”. So it’s unsurprising, then, that there is regular conflict between stakeholders as a result of disparate motivations and ambitions for the future of the platform.

We all know that WordPress could do just about anything but, maybe it’s time to stop and ask whether it actually should.

What we can say with relative certainty is that WordPress cannot become the best publishing platform, website builder, ecommerce store, social network, rss reader and application platform - all at the same time.

Stephen Covey once said: The main thing is to keep the main thing the main thing.

So what is WordPress’ main thing?

The Road Ahead

From a business perspective, I would argue that Calypso is one of the most important moves that Automattic has ever made. It’s very telling that Matt’s post opened with passage on disrupting yourself, and I’m glad someone (finally) gave him a copy of The Innovators Dilemma. This is all very overdue.

I’ve seen a few people suggest that both Calypso and the WordPress API are “too little, too late”. I don’t think that’s accurate, but I do think (generously) that they are “just enough, just in time” — which isn’t an overly aspirational level to reach for.

If released two years ago, this all would’ve been very groundbreaking and risky. A truly enticing bet on the future. Today, it’s really just par for the course in order to keep up.

Someone needs to be asking a much deeper question of what WordPress should be in 5 years time, and use some of Automattic’s $300million+ war chest to start working on it right now, to actually get ahead of the curve.

Church and State

WordPress.com is the only tech company I can think of with a billion dollar valuation where, after 10 years, I still can’t name a single one of their active users.

I know they must exist. Somewhere. I guess?

WordPress.com is a bit like Foursquare in the sense that, back in 2009, it was interesting and relevant to the consumer trends of the time. Foursquare eventually found its feet in enterprise location data after the consumer appeal slowly waned, and I can’t help but wonder if WordPress.com wouldn’t be better served following a similar path.

With the notable exception of WooCommerce, Jetpack is by far the most interesting and powerful product in Automattic’s repertoire. It’s the one place where the power of a closed system (easy interaction with 3rd party APIs, useful big data and sophisticated tooling) combines with the power of a distributed system (freedom and diversity) to create a truly special user experience.

If WordPress.com was predominantly a cloud computing platform that acted as a back-end-service for all WordPress sites, the potential could be incredible. It might also finally see WordPress.com and .org finally complementing each other; rather than perpetually confusing each other.

For that to ever happen, though, Automattic would first need to fix their developer PR problem. The predominant sentiment toward Jetpack remains regrettably negative, because of repeated dark patterns, opaque data collection, performance problems and (again) a clear lack of general transparency. These things are all eminently fixable.

Regardless, if Automattic don’t start leveraging the wider WordPress development community in a positive way, we may eventually be left wondering what might have been - as we have with Twitter.

The best part of Calypso

This is a long post. I’ve weaved through a lot of thoughts I’ve had about WordPress for the past few years, and my sentiment towards the project remains overwhelmingly positive. I still evangelise WordPress on an almost daily-basis, usually while people are trying to do more than “just blog” with Ghost when WordPress would be a way better fit.

I want to finish by touching on what is, for me, the most exciting aspect of Calypso by far — which I haven’t seen anybody else mention yet.

There is an enormous world of JavaScript developers out there which WordPress is about to be introduced to. JavaScript is the most ubiquitous programming language on the internet — and this move opens up a whole new wave of new blood who can contribute to, and get involved in WordPress for the first time. Which is undeniably amazing.

It also means that soon WordPress developers will find it more easy to get involved with Ghost and vice-versa. This can only be a good thing, as two communities with a huge overlap in values and ambitions now will also have a big overlap in skill-sets.

For those of you who are new to JavaScript and want to tool-up for the future, I highly recommend Code School, who have some really great courses that will have you up and running in no time.

One way or another, the future is looking pretty exciting.