The physical manifestation of my webpack.config.js file. Photo by Yung Chang
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.
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
Here is a list of solutions to look into:
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.
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 is another tool one could use to add interactivity. It uses Ajax and DOM mutation to handle changes.
Craft web UI’s in pure Ruby. Avoid writing JS altogether.
Stick with server-side rendering
Maybe you’ll become a rebel too.