4 ms·

At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experie

At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much in the more meaningful domains of business since you can't cheat god (information theory). If the data is so frequently out of sync that every interaction results in JSON payloads being exchanged, then why not just render the whole thing on the server in one go? This is where I can easily throw the latency arguments back in the complexity merchant's face - you've simply swept the synchronization problem under a rug to be dealt with later.

worldsayshi 1y ago
What about a feature like query completion?
- lyu07282 1y ago
  there probably is a jQuery plugin for that /s
- 1oooqooq 1y ago
  html native datalist?
  - simongray 1y ago
    The behaviour of an HTML datalist is basically completely different in every browser. It is a highly flawed element.
- gwd 1y ago
  The query completion can also be SSR. The example below is HTMX for Active Search, but the principle is the same: https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/
  - worldsayshi 1y ago
    I suppose that is a rather neat way to do it.
- endemic 1y ago
  SSR doesn't mean "no JavaScript." See "progressive enhancement."
zarzavat 1y ago
> modern internet connection Have you heard of these things called smartphones? I hear they're getting quite popular.
- jiggawatts 1y ago
  I read HN all the time on my phone, and I love that it loads reliably even on 1 bar of 4G. Meanwhile, Reddit no longer works reliably even with 3 bars of 5G. The former is HTML with a light sprinkling of JavaScript, the latter is a SPA app.
lelanthran 1y ago
> At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. I dunno; other than the fact that there are some webapps that really are better done mostly client-side with routine JSON hydration (webmail, for example, or maps), my recent experimentation with making the backend serve only static files (html, css, etc) and dynamic data (JSON) turned out a lot better than a backend that generates HTML pages using templates. Especially when I want to add MCP capabilities to a system, it becomes almost trivial in my framework, because the backend endpoints that serve dynamic data serve all the dynamic data as JSON. The backend really is nicer to work with than one that generates HTML. I'm sure in a lot of cases, it's the f/end frameworks that leave a bad taste in your mouth, and truth be told, I don't really have an answer for that other than looking into creating a framework for front-end to replace the spaghetti-pattern that most front-ends have. I'm not even sure if it is possible to have non-spaghetti logic in the front-end anymore - surely a framework that did that would have been adopted en-masse by now?
0x445442 1y ago
Complexity merchant... I like that.
- dilawar 1y ago
  https://chrlschn.dev/blog/2025/05/beware-the-complexity-merchants/ https://chrlschn.dev/blog/2025/05/beware-the-complexity-merc...
swiftcoder 1y ago
> Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention With modern CSS transitions, you can mostly fake this anyway. It's not like javascript apps actually achieve 0ms in practice - their main advantage is that they don't (always) cause layout/content flashes as things update
ebiester 1y 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. 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.
- TimTheTinker 1y 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.
  - ebiester 1y 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.
- _1tem 1y 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.
RNCTX 1y ago
> Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. "it's too slow" is a thing a lot of customers have mentioned to me over the years.

worldsayshi 1y ago

What about a feature like query completion?

lyu07282 1y ago
there probably is a jQuery plugin for that /s
1oooqooq 1y ago
html native datalist?
- simongray 1y ago
  The behaviour of an HTML datalist is basically completely different in every browser. It is a highly flawed element.
gwd 1y ago
The query completion can also be SSR. The example below is HTMX for Active Search, but the principle is the same: https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/
- worldsayshi 1y ago
  I suppose that is a rather neat way to do it.
endemic 1y ago
SSR doesn't mean "no JavaScript." See "progressive enhancement."

zarzavat 1y ago

> modern internet connection Have you heard of these things called smartphones? I hear they're getting quite popular.

jiggawatts 1y ago
I read HN all the time on my phone, and I love that it loads reliably even on 1 bar of 4G. Meanwhile, Reddit no longer works reliably even with 3 bars of 5G. The former is HTML with a light sprinkling of JavaScript, the latter is a SPA app.

lelanthran 1y ago

> At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. I dunno; other than the fact that there are some webapps that really are better done mostly client-side with routine JSON hydration (webmail, for example, or maps), my recent experimentation with making the backend serve only static files (html, css, etc) and dynamic data (JSON) turned out a lot better than a backend that generates HTML pages using templates. Especially when I want to add MCP capabilities to a system, it becomes almost trivial in my framework, because the backend endpoints that serve dynamic data serve all the dynamic data as JSON. The backend really is nicer to work with than one that generates HTML. I'm sure in a lot of cases, it's the f/end frameworks that leave a bad taste in your mouth, and truth be told, I don't really have an answer for that other than looking into creating a framework for front-end to replace the spaghetti-pattern that most front-ends have. I'm not even sure if it is possible to have non-spaghetti logic in the front-end anymore - surely a framework that did that would have been adopted en-masse by now?

0x445442 1y ago

Complexity merchant... I like that.

dilawar 1y ago
https://chrlschn.dev/blog/2025/05/beware-the-complexity-merchants/ https://chrlschn.dev/blog/2025/05/beware-the-complexity-merc...

swiftcoder 1y ago

> Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention With modern CSS transitions, you can mostly fake this anyway. It's not like javascript apps actually achieve 0ms in practice - their main advantage is that they don't (always) cause layout/content flashes as things update

ebiester 1y 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. 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.

TimTheTinker 1y 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.
- ebiester 1y 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.
_1tem 1y 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.

RNCTX 1y ago

> Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. "it's too slow" is a thing a lot of customers have mentioned to me over the years.