Over the past few years we’ve seen an real surge in the use of single page application architecture. Moving away from traditional web application workflows of requests that render a page on the server, responding by sending it down to the browser. This move has been driven by a renaissance in front end development practices. Over the past 10 years or so, we’ve seen a serious up leveling in the JavaScript framework space. Starting with Angular and Backbone in the early 2010s, the thought of producing a thicker client that could create richer experiences became plausible. In the jQuery era, the thought of producing a full application client like this seemed out of reach. The complexity of such an application would quickly overwhelm the developers creating it. It simply wasn’t an option, until the tools came along to help manage the complexity.

With the single page application architecture hitting full stride in 2019, it seems like a given that this has become the defacto standard for any new project. The message seems to be that to build anything of value, you need to be building a microservices backend and a single page application frontend.

But have we lost our way? Just because we now can accomplish impressive architectures that enable the entire experience to be loaded in a single request, have we considered if we should?

Everything has tradeoffs

Every choice that you make as a developer solves problems, but also creates problems. One of your primary responsibilities as a developer is to make sure that the ledger of these choices end up solving more important problems then they create.

We tend to look at the advancement of the web as leaving things behind, but I’d assert that it should be seen as progressive enhancement.

In a Web 1.0 world, the web was largely built around static documents. JavaScript was largely seen as unnecessary, and pages did not have much use for these sorts of highly interactive bits of content. As the web progressed, we entered a world in which the documents were no longer static, but dynamic. In a Web 2.0 world, we got the concept of a “web application”, sites that were dynamically generated on the fly using server-side technology. But does this mean that the approach of using simple static documents is now useless? Would it be smart to use a server-side MVC tool if all you need to do is serve static html documents? Absolutely not, because that creates complexities with no real return. It wouldn’t be solving any important problems for your users, but you would be incurring the added complexity.

This is how I like to frame the conversation around single page applications today. We are viewing server-side rendered solutions as if they are archaic and irrelevant, even though in many cases the added complexity involved in producing a single page application brings no measurable value to users.

That is not to say that this new and exciting way of building applications doesn’t solve problems, becauese it does! You just have to be sure that you actually have the problems it solves.

An alternative, Multi App Pages

We decided that we expressly did not have the problems that single page applications are best at solving. We don’t have a need for microservices. Our frontend would talk to a single backend. We are a 1 person team with production experience building product with Ruby on Rails.

BUT, we also really enjoy all the new tools and approaches that the JavaScript ecosystem has built up over the years. Declarative UIs, one way data flow, and proper state management are all pushing front end web development forward, but you don’t have to build a single page application in order to to take advantage of those advancements.

We developed a process that allows us to drop into a proper front end application workflow when interactivity is needed, but allow Ruby on Rails to continue leveraging it’s strengths to build out the bedrock of our application. In this way, on any given route rendered by Ruby on Rails, there may be multiple “frontend applications” that are loaded, from a small simple form element scaling up to an entire interactive dashboard like our project overview.

I can confidently say that this approach has allowed us to move extremely fast in building out our application, without compromising the level of interactivity we need to solve our user’s problems.