💾 Archived View for erock.io › 2022 › 05 › 21 › shifting-away-from-spa captured on 2023-01-29 at 15:52:53. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

reply -- the balance has shifted away from SPAs

Stardate 2022-05-21

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.

[1] lists.sh

In the comments someone mentioned the concept of holotypes[2], which classifies each use case of the modern browser in a category.

[2] application holotypes

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.

Want to chat? email me at gemlog@erock.io

home