Single Page Applications or SPAs have become the norm for web development. And that drives me insane.

Short primer on definitions: I consider a SPA to be a Javascript (or webassembly) application that has to run in the user's browser for the site to be usable. There are some more modern approaches like NextJS that can produce the whole document server-side and let the client use JS for enhanced functionality. I'm ok with that and those are outside the scope of this rant.

User's perspective

The most egregious example I can think of is LinkedIn. If you open the frontpage, you are hit with 35MB(!) of Javascript. The client performs 21 GraphQL queries during the initial load. You have to wait for a couple seconds before you see the actual page, after which you see the first piece of content load in. All this with uBlock Origin installed.

All this for a site that has very few features that require any client-side logic. There is zero reason you'd need Javascript just to read the post your boss wants you to like.

In general, the whole web has become slower and slower during the last decade, while our servers, networks and personal devices have become faster. It's not just that we use more resources since Moore's law allows us to (.. to an extent), but we have used this as an argument to push for objectively bad architecture that actively harms the users and developers.

If you want a reminder of how quick the web used to be literally 20+ years ago, open any old phpBB forum. Sure, it looks old, but a little bit of CSS can fix it right up. You could use Javascript for a nicer editor and maybe profile popups when hovering a name, but otherwise it all works perfectly.

Developer's perspective

Writing an application purely in the client can be enticing, as then you can have all of the logic for how the application is rendered and how it's interacted with in one place. It also lets you skimp on the server implementation, which is important in today's world of "full stack" developers, who can at most set up a bog standard CRUD.

Issue is, we have to somehow manage state. Managing state is so difficult there are hundreds of libraries for it. We don't have to do it just in the client, but on the server too. This part is unescapeable, no matter how much we want to pretend the server is stateless. The whole point of CRUD is to store state.

I have worked on a lot of SPAs over my career. I have not worked on a single project that needed to be a SPA or benefited from being a SPA. Every time the client-side state management ended up accounting for around 50% of total code of the client and around 90% of the total bugs (including the server). All this state already exists on the server and we'd avoid all of this if we render the html on the server.

I am entirely convinced that if we were to forbid the use of client-side rendering, other than for small conveniences, all of these projects would have been finished in half the time and would be far easier to maintain. And users would be happier.

The paradigm inversion

I don't want to be all negative. I've started to notice a paradigm inversion, where instead of attempting to write all of the code in the client, we attempt to write all of the code on the server. This is actually excellent.

As a concrete example, take Phoenix LiveView. In it, you define a function from state to html and actions, which can be executed server-side to produce the document, which is then passed to the client. After this, every action the user makes is passed to the server using a websocket, which then updates state accordingly and returns a precise diff of how the view should change. All of the state is managed automatically and efficiently between the client and the server. Phoenix also lets the server push updates at any point, solving all of the polling and sync issues with live chat, for example.

I hope this shift gains traction and we could see a faster web again.