[bob1029]

The #1 reason I push for SSR/vanilla web is to consolidate all state to the server. Literally the only thing on the client could be a session cookie. A few hundred bits of entropy. That's the client's state. Imagine how simple that would be.

The cost of a round trip for every UI interaction might seem high, but I've never seen a distributed client/server state machine model that could compensate for any of these alleged UX harms without simultaneously bringing in more complexity than anyone was prepared to deal with.

[adamddev1]

But then we lose the ability to do anything offline. Offline web apps are still valuable. Some people want to turn their data off sometimes. Many people live in places where internet access is spotty.

I also love the simplicity of SSR/vanilla web for some things. But I say keep offline-first SPA/PWAs alive. Cross-plaftorm. Freedom from the app stores. Freedom from needing to be tied online all the time.

[adamddev1]

When you have a website that needs to be always accessed online, absolutely, give us an old-fashioned SSR vanilla web experience. Just give us a page WITH ALL THE DATA that loads in half a second. Don't make us wait for 5 seconds with spinners and placeholders while you make the client fetch data itself from different sources. This is insanity and torture! People are using client side rendering for the wrong things.

But there are good and powerful use cases for client side rendering.

[bob1029]

> I say keep offline-first SPA/PWAs alive.

I have no problem with the properly offline-capable apps using standards compliant web technology. I've been championing the use of PWAs to circumvent the iOS App Store for years.

To be very specific, the problematic solutions in my view tend to be those right in the middle of pure SSR and pure client. They aren't sure if they are always online or offline by default and the actual customer use cases don't seem to have been fully explored.

Did you ask the customer if a ~150ms form post to us-east-1 from their main office would be something they'd even care about? Why not? You could save an unbelievable amount of frustration if they don't care. It would take 10 minutes to set up a demo they could try if you think it's going to be a deal breaker at delivery time.

I've not once worked with a B2B customer in the banking, insurance, finance, manufacturing or retail domains who raised a concern about any of this. Only nerds on the internet seem to fantasize about the customer getting outraged at a browser navigation event or a synthetic browser benchmark score.

[adamddev1]

I agree. I think it would nice to have basically two tracks, either fully SSR or fully client. I think if they researched what really irritated customers it would be the 2-4 seconds of staring at spinners and placeholders that has become normal. Now we've got instant feedback for browser events but brutally slow load times for our pages to fill out.

[nkrisc]

Freedom from browsers - I'd rather have an executable I can run.

[LegionMammal978]

Yeah, sites demanding a roundtrip for every small interaction can be a pain to use when traveling. The principle I'd wish more web devs would keep in mind is, "Just because the client managed to contact your server once doesn't mean it will have fast and easy access to it in perpetuity." Indeed, in my experience, too many roundtrips is the cause of most atrociously slow websites, regardless of how heavy or light a framework they use.

[hombre_fatal]

That works for a certain class of applications, but it's not very simple once you do want interactivity on the browser client.

Nor would I call it simple that the server has to be able to send the whole UI over the wire instead of just data. And it ties your server to the web browser instead of providing a simple data API that can be used by anything that can make an http request.

There are always trade-offs.

[paulddraper]

Was there any traumatic event that induced memory loss?

The number of broken stateful server-side page that had some weird server state and couldn't handle URL navigation?

You can f up either way, but I've seen as many crimes with server apps as with client ones.

[no-dr-onboard]

> Literally the only thing on the client could be a session cookie.

You know, about 7 years ago I would have heartily agreed with you. KISS, right?

The thing is, it just doesn't make financial, UX, or security sense to do that. The cost of storing every jot and tittle on the backend is huge. The collateral of anything happening to the backend becomes larger. Enjoy benign things like preferences/app settings, unsent comments not having to be rewritten because your session expired, etc? If you're not storing them via local storage, you can KISS that goodbye.