WordPress Calypso

Recently Automattic have announced the release of Calypso, a next-generation interface to manage WordPress.com or Jetpack-enabled sites. It’s a very ambitious project, but I believe they have some of the best developers in the world. Plus Andy Peatling, who I’ve had a huge amount of respect for since he initiated the BuddyPress project, ran the team.

The interesting thing for developers is their choice of technology stack. Calypso is a single-page app, powered by Facebook’s React library, node.js, with data coming from the WordPress REST API. All mod cons, and the interface is certainly beautiful, easy to use and very fast.

But I have to admit I have concerns about single-page apps, and the “modern” approach of total reliance on JavaScript to power a UI. JavaScript is the least robust of the Holy Trinity of web technologies (HTML, CSS and JavaSscript) as it does not gracefully handle errors. Many sites fall into the trap of thinking they can rely on JavaScript when they can’t. CSS is in the same boat, although if you get *some* CSS then whatever you get will be used to style the page. If you get just *some* JavaScript the likelihood is that nothing will work. It’s clear that the only resource which we can really count on – and even then, it’s not 100% guaranteed – is the HTML.

So, using my favourite progressive enhancement testing tool (turning off JavaScript), what do you see in Calypso when javaScript fails? This:

Unfortunately there’s nothing there, just the WordPress logo. Perhaps showing the “unsupported” message by default would be better, as this is what the Calypso app redirects to wordpress.com/browsehappy if the browser doesn’t support some modern JavaScript APIs or is iOS version 5 or earlier.

Here’s the (JavaScript) code that checks whether the browser cuts the mustard, with comments from me:

(function() {
    function isSupported() {
        var ios, version, ua;
        ua = window.navigator.userAgent;
        // check if the browser supports window.history, which allows changing the displayed URL without refreshing the page
        if ( ! window.history ||
            ! window.history.pushState ||
            ! window.history.replaceState ||
            ! ( '__proto__' in Object.prototype )
        ) {
            return false;
        function getFirstMatch( regex ) {
            var match = ua.match( regex );
            return ( match && match.length > 1 && match[1] ) || '';
        ios = getFirstMatch( /(ipod|iphone|ipad)/i ).toLowerCase();
        version = getFirstMatch( /version\/(\d+(\.\d+)? )/i );
        // check if the browser looks like iOS version 5 or earlier
        if ( ios && version < 6 ) {
        // disable for now because it is breaking Chrome on iOS
        //return false;
        // if we get here we know we can run the app
        return true;
    if ( ! isSupported() ) {
        window.location = 'https://wordpress.com/browsehappy?url=' + encodeURIComponent( window.location );

And this is the “unsupported” message (with cute Nessie image):

OK, on to performance. As I’ve mentioned Calypso feels really fast. One of the principles for the project was speed, and it shows. It’s also responsive, which for a powerful “app” such as this is no mean feat.

The resource stats show that it’s pretty big, however (this is from Google Chrome dev tools for a new post edit page):


The breakdown of requests shows a large amount of JavaScript (as you’d expect) and quite a lot of CSS:

Resource type Requests Total filesize
All 93 1.9mb
HTML 1 2.2kb
CSS 22 322kb
JavaScript 17 1.4mb
Images 12 13.5kb
Fonts 17 137kb

I was surprised at the amount of web fonts, which led me to look at the dependencies on other domains. Here’s how that breaks down (again, this is for a edit post page):

Domain Requests Description
gravatar.com 7 Avatars
fonts.googleapis.com 5 Web font stylesheets
fonts.gstatic.com 11 Web fonts
wp.com 34 Stats collection, jQuery, stylesheets, favicons and widget HTML
wordpress.com 13 Stylesheets, main JavaScript files
google-analytics.com 2 Analytics tracking
olark.com 1 Chat facility, presumably for customer support

I ignored subdomains and XHR requests (which are the requests to the API to get data) for this table.

Better stats that don’t rely on me manually counting rows in dev tools could be got from WebPageTest, and I may do that when I figure out how to get WebPageTest to log in to Calypso.

My conclusion from this very quick investigation is that while Calypso is a very slick web app (whatever “web app may mean) its total reliance on JavaScript means it could easily break for users on low-powered devices or using it dodgy network conditions. If the aim of WordPress is to democratise publishing then this has to be for users is the worst of browsing scenarios as well as those of us lucky enough to have fast machines, modern browsers, and fast and stable networks.

My belief is that the WordPress team know this, and that work is already under way inside Automattic to enable things like server-side rendering and handling of POST requests. And, in the mean time, the classic admin interface is still available.

What this means for the huge plugin ecosystem will be very interesting to find out. That’s a topic for another post!