A recent article popped up on hackernews[0] that I figured I would respond to here.
[0] The balance has shifted away from SPAs
# New frameworks are focusing on MPA + 0kb JS by default
I definitely see a trend where more and more web frameworks are trying to leverage multi-page applications with minimal or no javascript on the front-end. I welcome these changes because not everything needs to be an SPA. I recently built lists.sh[1] which doesn't have any javascript in its stack. Everything works perfectly fine a simple document browser. It was a lot of fun to build and didn't require any heavy lifting on the front-end. But here's the thing, it didn't require any interactivity. One of its features was no javascript. At the core of the site is a blog. Blogs do not need javascript and in fact, tend to make the reading experience worse. This is one reason why I'm enjoying gemini so much. Gemini is great for what it is: a document browser.
In the comments someone mentioned the concept of holotypes[2], which classifies each use case of the modern browser in a category.
Some categories are better suited as an SPA vs an MPA. So let's organize the list that way:
# SPA
- Social networking destinations
- Social media applications
- PIM applications
- Productivity applications
- Media players
- Graphical editors
- Media editors
- Engineering tools
- Immersive / AAA games
- Casual games
# MPA
- Storefronts
- Content websites
I really like this list because it helps us understand why SPAs are so prevalent. Does everything need to be an SPA? No, but there are a lot of use cases where it just makes sense.
In this context, it's pretty clear that SPAs are not going anywhere.
# New browser APIs to support MPAs
The article continues to discuss that browser's have been implementing more and more features to make MPAs more usable:
- Paint holding
- Back-forward caching
- Service workers
- Shared element transitions
Honestly, I don't think these features are particularly compelling. When I look at this list, I don't think "game changer." These are polish features to make MPAs are little more pleasant, but that's about it.
# Control
Choosing an MPA is a big architectural decision that may effectively cut off the future possibility of taking control of the page in cases where the browser APIs are not quite up to snuff. At the end of the day, an SPA gives you full control, and many teams are hesitant to give that up.
That's it. He described exactly why I like building SPAs: control. As a software engineer who has built a career on SPAs, the control I have when building applications is critical. Control is the primary characteristic I think about when architecting a web app. This is especially important when working at a startup where the business requirements are vague. Making big decisions about an application that might stick around for 5+ years while at the same time not fully understanding the business requirements puts us in a tough position.
At the end of the day, SPAs provide us with control over our application. I can make an SPA do anything I want and that's really all I care about. Do I particularly enjoy building massive javascript applications? Not really. That's why in my free time I'm focusing less on javascript and more on products that doesn't require it.