tatiyants.com Are Single Page Apps Bad?

Single Page Apps (SPAs) are quickly becoming the conventional wisdom for building rich web applications. I for one am a big fan of SPAs in general and a certain superheroic framework in particular.

SPA’s popularity is probably due to rapidly maturing browser technologies (HTML5, CSS3, high-performance JavaScript engines) and a Cambrian explosion of JavaScript MV* frameworks. We’re quickly approaching a point where anything you can build in a desktop app, you can also build in a web app.

Yet in spite of the above-mentioned popularity, SPAs aren’t universally beloved. In the past, primary opposition to SPAs came from fans of the traditional server-side MVC approach and let’s say non-fans of JavaScript. Personally, I found both camps fairly easy to dismiss (with all due respect). However, a recent stream of anti-SPA opinions from knowledgeable people I respect made me pause and reevaluate my opinions.

The Case Against Single Page Apps

Probably the most comprehensive case against SPAs was made by Stefan Tilkov in his talk “Web Development: You’re Doing it Wrong”. In it, he explains why he considers SPAs to be problematic by contrasting them with applications written in a style he refers to as Resource Oriented Client Architecture (ROCA).

So, what is ROCA? Here’s a quote from the ROCA Website describing it:

ROCA is an attempt to define a set of recommendations — independent of any particular framework, programming language, or tooling — that embodies the principles of what we consider to be good web application architecture. Its purpose is to serve as a reference, one that can be implemented as-is or be compared to other approaches to highlight diverging design decisions.

ROCA splits into two parts: The server-side and the client-side architecture. The server-side consists of RESTful backends, serving human-readable content as well as services for machine-to-machine communication, either public or internal. The client-side focuses on a sustainable and maintainable usage of JavaScript and CSS, based on the principle of Progressive Enhancement. This technique is pursued by nearly every basic web technology, e.g. HTML or HTTP. Client and server are largely independent from, yet complement each other.

Though the quote above doesn’t mention specific frameworks, Rails 4.0 (which is heavily influenced by a recent redesign of BaseCamp) is probably the most notable real-world implementation. Pjax is another popular framework which can be used to implement a ROCA-style app.

ROCA vs SPA

Before diving into relevant differences between SPA and ROCA, let’s briefly mention the similarities (as there are many). Both styles advocate using RESTful backends and everything that this entails (like well formed URIs and stateless sessions), both favor unobtrusive JavaScript, and both expect separation of presentation (CSS) and content (HTML).

What then is the difference? There are a few, but the main one is the format those RESTful backends provide to the client. In SPAs, the data being sent to the browser is either JSON or XML. The responsibility of converting that data into a browser-compatible HTML view rests entirely on the client. In ROCA, the data being sent to the browser is HTML.

This seemingly minor difference has significant implications. For example, resources built using ROCA are themselves valid web pages, which can be crawled and indexed by a search engine, bookmarked, and displayed in clients with JavaScript disabled.

In fact, all of the reasons listed above are why ROCA supporters favor it over SPA. In their view, SPAs fundamentally break the web paradigm by essentially recreating desktop apps in the browser. On the other hand, ROCA apps fit nicely within the web paradigm by embracing HTML as the format for exchanging data between client and server.

My Two Cents

Generally speaking, I’m not a fan of reflexively using a technology or an approach irrespective of the problem being solved (with notable exceptions). From this perspective alone, I do agree that using SPAs for everything is not ideal.

Furthermore, a major reason why I like SPAs in the first place is that they force you into creating resource-oriented applications. ROCA does the same and further enforces web compatibility via adherence to HTML.

But What About Performance?

Since SPAs offload a lot of processing to the client, they’re often thought to be more performant and scalable than server-heavy alternatives. The reality is a lot more nuanced.

Consider BaseCamp’s heavy use of sub-component caching (i.e. “Russian doll” approach). BaseCamp individually caches every piece of content displayed on a given page. This cache is global and can therefore be reused between pages, users, apps, etc. What does this mean for performance? Even though all of this HTML is generated server-side, page rendering is ultra fast (100ms or less).

Now, BaseCamp’s domain (project management), works well with this approach. There are many independent pieces of content, which can be combined, shared across pages and users, and so on.

Ok, so Desktop Apps on the Web Are Bad, Right?

Well, no. I do think that certain types of apps (games, image editors, word processors, possibly mail clients, etc), are well suited to the “desktop” metaphor. The really interesting question is how does one decide whether SPA or ROCA is the right option.

Without too much thinking about this (as is my custom), I would assume ROCA to be the default approach and use SPA if the app:

doesn’t require a server at all (ex. image editor)
exposes many complex interactions on a large resource (ex. word processor)

Are there other areas where SPAs would work better?

The Case Against Single Page Apps

ROCA vs SPA

My Two Cents

But What About Performance?

Ok, so Desktop Apps on the Web Are Bad, Right?

You may also like: