by docmars | 2025-07-27 01:13:34+00:00
> wouldn't something like Astro be a happy middle ground?

Absolutely, but it is additional boilerplate I have to worry about that serves as another layer alongside whatever SPA framework I prefer; whereas spinning up a Vite template with Vue, writing a few routes + components, and getting it built + deployed is easier. It's at such a low cost (bundle size, time, boilerplate) that the optimizations gained from Astro aren't even in my purview unless I'm experiencing a significant enough scale that justifies static rendering.

When my apps are feeling and behaving perfectly already, why optimize? It only comes with increased scope and cost to bend around another layer.

> If you've built your site as a SPA, and you realize that your product just needs to be HTML to stay competitive

This does go both ways, yes, but with SPAs, I have more flexibility around client-side features like transitions, animations, pagination for smaller datasets, and state-based views that depend on a lot of different interactions, user selections, etc. that all drive what gets displayed instantly, without making a single network request just to complete the interaction. The Venn diagram between the two shows SPAs doing more out of the box, at such a low cost to commit.

Whereas with MPAs and server-side templating, a better-feeling UI isn't a luxury you can enjoy without some form of JavaScript to wire up page interactions. Given these are often a requirement, you'll find yourself haphazardly adding an SPA library to an existing MPA to enhance the perceived UX that it couldn't provide. Then you're not only juggling 2 scripting languages, but also reconciling the separation of concerns between your client/server now.

Although, happy-mediums have emerged: 37signals created Hotwire to help bridge this gap, Laravel has a similar library Intertia.js, and htmx+Alpine is another interesting solution.

Lastly on this point, Svelte's build step strips your SPA into the smallest possible runtime. Svelte was actually built for creating SPAs intended to run on low-power devices [1] typically seen in places like LATAM. React also has an official compiler that memoizes component data and callbacks. Preact is a 3kb alternative to React (40kb) for low-power devices, sharing the same APIs with only a few minor differences.

React, Vue, and Svelte all have server-side rendering where you can comfortably write sites/apps that serve up smaller bundles and stream updates to the client as needed, without sacrificing a pleasant UX. So, to answer your question "what if your SPA needs to be HTML to stay competitive?" -- these are all the most sustainable paths with the lowest costs.

>> You may be asking, "why don't you learn + use some of the alternatives you listed?"

As any reasonably tired, middle-aged engineer would say: I'm happy with the language(s), tools, libraries, and frameworks I'm comfortable using. The incessant drive to learn new tools that pretty much do the same thing with dubious (and likely negligible) benefit at smaller scale feels like a distraction when I could just be building and shipping something with familiar tech that thousands of other developers enjoy using. I also benefit from the community support as well, not to mention, AI tools are best used in TypeScript codebases currently.

Server-side templating requires dedicated hosting / VPS, which is a whole 'nother layer of deploying, managing, and debugging. Static sites and SPAs can be hosted with a static host for free (unless you scale like crazy), and any data-related needs are solved with serverless services like Supabase, Convex, lambdas/functions, and any number of others -- all with generous free plans and some level of portability.

In my case, I'm only developing SaaS applications not needing mobile support, that are only used by companies that buy decent computers for their employees. Otherwise I'm building small webapps for personal use and some that may become a hit among niche communities. Even my personal site is a tiny Vue app, and only because it's familiar and easy to change. The performance fiends can cry all they want that it isn't purely static, and in many ways, that amuses me.

[1] https://developer.mozilla.org/en-US/docs/Learn_web_developme...