The Rebellion Against JavaScript SPA's has begun

alt text The physical manifestation of my webpack.config.js file. Photo by Yung Chang

Rebels have been quietly plotting the SPA(Single Page Application) downfall. JavaScript frameworks like Angular, Vue, and React have dominated web development in the last few years. The complexity of SPAS to build and maintain stand in contrast to server-side applications.

To be glib, lots of people will look back at this era of web development with regret. For the majority of applications, server-side rendering remains a Thiel truth. It’s uncomfortable for some to hear, but most web sites would be better off being server-side apps than single-page applications.

Servier-side monoliths are cheaper to build, faster to create and are easier to maintain. As a bonus, they tend to be faster than their JavaScript counterparts, for the most part, thanks to techniques such as server-side caching, database optimisations and CDNs.

On the other hand, Javascript frameworks have to write their HTML once they have received JSON from the server, adding to the wait before a user can even use the app.

A lot more goes into a profitable web application than the right technology choice. But you give yourself a massive advantage by picking a traditional server-side framework(such as Rails, Django or Laravel) over a SPA.

Not all apps should be server-side. Some apps, such as Figma need to take advantage of being a SPA. Yet Figma is in the minority of apps I have seen in the wild that benefit from being a SPA.

It’s not all bad. Frameworks such as React have raised standards of what the web could be, and users expect your new web app to be more interactive and responsive. Suppose you don’t want to be dragged into the complexity-ridden world of the SPA? What can you do to make your app more interactive but keep the benefits of server-side rendering?

Arming the rebels

If you’re convinced that you want your next app to be more interactive but avoid the pitfalls of a JavaScript framework, what can you do?

Here is a list of solutions to look into:

Phoenix LiveView

The first time I saw an alternative proposition to React was this talk. It is also the first time I started looking into Elixer. Phoenix LiveView uses a persistent connection between the client and the server to allow the server to update the client.

Stimulus Reflex

A framework for Ruby on Rails. An interesting framework that was inspired by Phoenix LiveView. It uses WebSockets to implement changes to the client via the morphdom library.

Hotwire

The latest framework from Basecamp (who also built Rails) that is more opinionated than Stimulus Reflex and also includes wrappers from iOS and Android making it easy to create a mobile app from your Rails app.

Laravel Livewire

Laravel Livewire is another tool one could use to add interactivity. It uses Ajax and DOM mutation to handle changes.

Matestack

Craft web UI’s in pure Ruby. Avoid writing JS altogether.

Stick with server-side rendering

There are far more solutions out there. Common pain-points inspired these solutions; one of them is the complexity of modern JavaScript frameworks for a small team. Yet, does that mean you should embrace any of these solutions at all? I would argue that no, you shouldn’t. Start server-side first and build from there. You will produce faster, cheaper and you can add the interactivity later when it matters.

Have you felt jaded by the modern JavaScript framework of the week trend for the last five years? Do you have a gnawing feeling in the back of your head that something isn’t right? Maybe you want to build something for people and not spend time writing configuration files so you’ll eventually be able to make something.

Maybe you’ll become a rebel too.