The Single Page App Backlash

There have been a lot of articles recently that claim Single Page Apps are overhyped and thou shalt not build them. Ironically, even if I'm writing a book on them, I've been basically saying the same in my Single Page Apps on Rails presentation I gave a few times throughout the last years. The biggest problem with building SPA's is that this is almost always much more complex than building a standard web application based on the request/response model. Even if DHH's approach doesn't really sound that much simpler (add a lot of caching to anything and complexity can explode if you're not careful), the contrast in complexity between a simple web app with some sprinkles of javascript and a full blown Single Page App can be quite stark.

(Relevant to this, especially in the light of my Jumpstart book, is this article which describes building the TodoMVC app with Rails, jQuery and Turbolinks instead of a client side MVC framework)

But, then, why considering it at all? What's the point of all of those MVC frameworks then? Let me answer this in two ways.

First of all, as I say in my talk (here's the related blog post), I don't think that, for most usecases, it makes sense to start out with a single page app. The number of applications where this makes sense from the very beginning is very, very small.

Also, it's not a black and white thing. Libraries like backbone.js or angular.js can work very well as a supporting technology, meaning that only parts of an app where a SPA style architecture makes sense are rewritten.

A SPA architecture also makes sense when your JavaScript is getting out of control. One of the core concepts of most SPA libraries and frameworks is to create a relatively clear boundary by separating frontend concerns from backend concerns. Your server only serves a simple JSON api and your client software is completely written in JavaScript. This has a few benefits besides the boundaries itself: The typical jQuery powered JavaScript augmentation found in many webapps is usually quite the entangled mess that is hard to test, hard to change and hard to operate with. With a good architecture that has clearer boundaries, you can untangle that mess. MVC frameworks give you additional boundaries and structures to test against, refactor to and operate with.

The second answer is almost orthogonal to the first: We are currently building a completely new type of web application, where the SPA metaphor is imperative: Web Applications that are almost or completely independent of a web server. These apps work in your browser even when the network is not available. These apps save application data in localStorage or indexedDB or abstractions on top of these and are able to cache all assets needed to run the app.

One prime reason to take such an approach is mobile, of course: Regardless of how good your mobile provider is, you will always have situations where your connectivity is absent. Usually this happens when you urgently need that little piece of data.

Take Firefox OS: An operating system based on Android kernals that completely exchanged the Java based UI and App Layer of Android with a graphics rendering engine and Gecko, the browser engine in Firefox. Applications can be started from the web, but can also be installed from a ZIP file that contains the complete app.

WebOS of now defunct Palm had a similar model. Blackberry has the WebWorks platform which is also quite close to the Firefox OS model.

Currently, while Firefox OS and other platforms show that this approach is kind of valid, we're still facing the problem that mobile devices have a certain need to only run programs that are as efficient as possible. Drew Crawford wrote a widely recognized article that finally delivered some numbers on this subject and I urge you to read this if you haven't already. I'm not entirely sure how this will play out - While Firefox OS is perfectly usable on my preview devices, it is, performance wise and usability wise a long stretch from there to my iPhone (which is from 2010, btw.).

The big plus of these offline web apps is a relatively simple way to port apps between different platforms. Don't make the mistake of assuming porting an app is essentially free, though - While many mobile platforms have similar usability patterns, you're probably ignoring the fine details of a platform at your peril. A web app on an Android phone that uses iOS patterns feels weird.

Coming back to the original point: If you don't have a server to talk to, the SPA pattern really IS your only option. And while most of the current MVC frameworks are mostly assuming some sort of server persistence per default, most of them are easily adapted to use one of the client side persistence methods. Also, I'm predicting a range of new frameworks and libraries that are optimized for offline usage (and utilize server sync technologies where possible). hood.ie still has a server component to allow for sync and easy testing, but it definitely takes a bold step into that direction.

So, while Single Page Apps might not be the best approach for a wide range of problems (and using an anti-yak-shaving framework like Rails or Django still pretty much is the fastest option to develop and deploy most green field web apps), there are scenarios where a Single Page App is either the best way of dividing up responsibilities and building clean code (there, I said it), or where a SPA style architecture is simply the only option.

Choose wisely.