Hacker News new | ask | show | jobs
by naasking 328 days ago
The only real use case for an SPA is something that has to continue to work offline. There are legitimate cases like this, but most apps developed as SPAs aren't it.

> No SSR framework figured out how to do this because they thought about pages rather than experiences.

Laravel, Blazor and apps designed around HTMX are all like this. "SSR framework" has literally nothing to do with "pages rather than experiences". Pages are just a medium to deliver experiences.

1 comments

> The only real use case

The original idea behind an SPA was to enable API-only backends (with static file service). I still think that's a very worthy use case.

Why not decouple the backend from the concerns of particular views? It makes for a more complex frontend, but it also allows multiple, highly differentiated frontend apps to be build on top of a single set of backend APIs. Esri's ArcGIS Online powers a lot of specialized frontend-only web apps. I used to be on their Business Analyst team (that's a web app) - and I have to say I really like the pattern of building apps this way.

That's not a use case, that's an implementation. What is the end user actually getting with this architecture that can't be obtained by the server-side one? Offline functionality is the only differentiating feature.
A use case for an architecture pattern is a way it could be used to implement something. The concept of a "use case" doesn't just apply to end-users of a software product.

> What is the end user actually getting

More things implemented in the products with less development time.

For ArcGIS? Have you ever used that?

A similar system would be Figma - how do you build a server side Figma?

I'm not sure what you're trying to argue. SSR sites and apps still have scripting and client-side interactivity, the only difference is where the rendering is happening. That's what SSR stands for. SSR switches from APIs exchanging JSON with heavy client-side rendering, to REST endpoints returning hypertext which eliminates the majority of client-side rendering.
How would you implement Google Maps as a SSR app? -- same question for ArcGIS, Figma, an arcade game, or a Zoom clone. It's a serious question -- do you think that would be possible for any of those?

I contend that to build a coherent, usable web app of any of those types, there has to be a lot of client-side scripting. Hence, a SPA is the best architectural pattern.

Sure, you could use SSR for the layout of the page... but in that case, why not skip HTML rendering altogether by shipping raw HTML/CSS for the app's layout? Then you'd only need JS to power the contents of <div>s where the app's functionality is located.

> How would you implement Google Maps as a SSR app? -- same question for ArcGIS, Figma, an arcade game, or a Zoom clone. It's a serious question -- do you think that would be possible for any of those?

Yes: https://www.youtube.com/watch?v=0K71AyAF6E4#t=21m21s

> I contend that to build a coherent, usable web app of any of those types, there has to be a lot of client-side scripting. Hence, a SPA is the best architectural pattern.

"Lot's of scripting" does not automatically entail "SPA".

> you think that would be possible for any of those?

You think the web didn't have interactive maps or maps with directions before SPAs?