You probably don’t need a single-page application

The meteoric rise of front-end frameworks like React, Angular, Vue.js, Elm, etc. has made single-page applications ubiquitous on the web. For many developers, these have become part of their ‘default’ toolset. When they start a new project, they grab the tools they know already: a REST API on the backend, and a React/Angular/Vue/Elm frontend.

Is there something wrong with these tools? Absolutely not. In fact, I love working with them. However, I would only choose this architecture when an actual requirement is pushing me in that direction. If there are no specific reasons to build a single-page application, I will go with a traditional server-rendered architecture every day of the week. It is simpler and allows you to move faster:

All of this means that single-page applications impose more complexity and cognitive load on the developers. In my experience as a developer, complexity and cognitive load are the single biggest factors in software bugs and development slowdown.

When to go for the single page app #

As I said, the default choice in most cases should be the traditional server-rendered application. However, there are some requirements that might force you to opt for the single-page application architecture:

These products absolutely have to use a single-page architecture to work properly. This is why it’s the right choice for these companies. However, many web-based products do not have these requirements and this complexity can be avoided.

Hybrid solutions #

Even if your app needs some real-time capabilities or rich interactions, you don’t need to use the SPA paradigm for your whole app. A great approach is to embed small frontend applications into a traditional architecture.

Github uses this hybrid approach. The backbone of their website is a traditional rails app but some areas, like the projects tab, are built as embedded frontend applications. It’s a beautiful solution that combines the best of both worlds. The great thing is that you can start simple and gradually add more complex UI interactions with this approach.

I believe that my current project, Plausible, will evolve in this direction. The main UI of the app will need rich interactions in the future, but the rest of the app can stay with the server-rendered architecture.

It all comes down to tradeoffs #

As with everything in programming, there isn’t a single answer in the SPA vs traditional architecture dilemma. There are cases where it makes sense to go with a SPA because you need a snappy, real-time UI. However, we should recognize that this comes at a cost to the development speed. And if a single-page app is not a requirement, we can avoid the additional complexity and move much quicker by going the traditional route.

Picking the right architecture for the job makes a huge difference in productivity, and ultimately, success. We should aim to have both architectures in our toolbox, so we can use the optimal solution in each case.

This blog documents the journey of building Plausible
Get notified of new posts →


Now read this

How I found my 10 first users

Last week I felt like I was ready to share the beta version of Plausible online. Contrary to all advice I didn’t build an audience before releasing my product. Instead, I did what many first-time indie founders do: build a product and... Continue →