undefined | Better HN

0 pointsebiester7mo ago0 comments

Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. I haven't seen someone solve errors with form submissions and the back button well at the framework level. Post-Redirect-Get was awful. Trying to solve back buttons and wizards. Trying to solve modals. Is a modal a separate page with the rest in the back? What does closing a modal mean? What does a sidebar mean? How about closing it? Pretty soon, you're in half-an-SPA already.

And since you don't want a 2000 character URL, you're either storing half of the session on the server or having to build an abstraction with local storage. And since our frameworks didn't evolve to handle that, what is the purpose?

The key insight into the SPA is that you are writing a coherent client experience. No SSR framework figured out how to do this because they thought about pages rather than experiences.

Let me be clear: I am speaking about web applications. If you're providing information and only have a small number of customer interactions, an SSR is superior. CNN should not be an SPA.

0 comments

const_cast7mo ago

All of the SSR webapps I've built had these solved at a framework level. Dot net and PHP.

Like, the back button: there is no logic because this isn't react. It's just the browser back button. You don't have to do anything if you're using SSR. Back button problems only apply to SPAs or hybrids.

naasking7mo 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.

TimTheTinker7mo ago

> 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.

naasking7mo ago

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.

2 more replies

_1tem7mo ago

> Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have.

Clearly you've never used Laravel + Livewire. Modals, forms, wizards, sidebars, I have all of that in my app without writing any client-side JavaScript. And it works better than most SPAs. I actually get gushing praise for how "smooth" the app experience is.

ebiesterOP7mo ago

My contention is that this may not be the traditional client side app, but you are still placing these on a single page. Just because you are replacing the HTML on the page doesn't mean it is a multi-page app. It's an interesting SPA/MPA hybrid but just because you are not writing javascript doesn't mean that the infrastructure isn't using javascript to handle the plumbing.

So, let's use this as an example. Let's say you bring out a side drawer to edit the details of one row on the table. The side drawer pops up. The user edits details and clicks submit. (To answer this question, the user scrolls to other parts of the table to look at other rows.) There is an error in the user's input based on business logic. The user corrects it, and the row is changed. The side drawer goes away.

How many times is the whole page loaded from scratch? In a traditional SPA, the page is loaded once. With a strict MPA, the page is loaded from scratch four times. With Laravel + Livewire, to my understanding, the page is loaded once and divs are replaced with HTML from the server.

Even if it is not a react app, it is still a collection of single page apps with server side intermediations using html.

TimTheTinker7mo ago

> The key insight into the SPA is that you are writing a coherent client experience.

This is the best way to put it I've yet seen. HN articles keep saying things like "now that navigation transitions are solved in CSS, there's no use case left for SPAs". Is everyone just writing apps for widespread content consumption or something?

> CNN should not be an SPA.

Yes, and we need canonical "that should be an SPA"-type apps to bring up in these discussions--which can be hard, since all the best SPAs are for getting work done, not publishing content for the public to consume. Thus, as a class they tend to be department-procured B2B apps and not as generally recognizable. I propose GMail and Google Docs/Sheets/Slides for starters.

ebiesterOP7mo ago

I think the easy answer is "could you see this system being rewritten in QT or Visual Basic 6?"

If this would have been a desktop app in the 90s, it's within this scope.

j / k navigate · click thread line to collapse

0 pointsebiester7mo ago0 comments

The key insight into the SPA is that you are writing a coherent client experience. No SSR framework figured out how to do this because they thought about pages rather than experiences.

Let me be clear: I am speaking about web applications. If you're providing information and only have a small number of customer interactions, an SSR is superior. CNN should not be an SPA.

0 comments

const_cast7mo ago

All of the SSR webapps I've built had these solved at a framework level. Dot net and PHP.

naasking7mo 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.

TimTheTinker7mo ago

> 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.

naasking7mo ago

2 more replies

_1tem7mo ago

> Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have.

ebiesterOP7mo ago

Even if it is not a react app, it is still a collection of single page apps with server side intermediations using html.

TimTheTinker7mo ago

> The key insight into the SPA is that you are writing a coherent client experience.

> CNN should not be an SPA.

ebiesterOP7mo ago

I think the easy answer is "could you see this system being rewritten in QT or Visual Basic 6?"

If this would have been a desktop app in the 90s, it's within this scope.

j / k navigate · click thread line to collapse