URL-Driven State in HTMX • Hacker News Board

Re: URL-Driven State in HTMX

#181

Post by naasking » Fri, Aug 01, 2025, 3:28 PM UTC

TimTheTinker wrote: post #178

naasking wrote: post #177

Earlier quoted context omitted.

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…

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

Re: URL-Driven State in HTMX

#182

Post by TimTheTinker » Fri, Aug 01, 2025, 7:14 PM UTC

naasking wrote: post #181

TimTheTinker wrote: post #178

Earlier quoted context omitted.

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…

> 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 architectur…

That's a very impressive demo of Datastar, and I like his minimalist approach to frontend architecture.

However, the display logic is implemented as a web component containing (a) a lot of tags written as a big HTML file for streaming state from the backend, and (b) a canvas element rendered by a WASM component. If that fits your definition of SSR for frontend apps, no problem and I think it's great. But that's not what I would have defined as SSR.

Some hurdles I imagine Datastar will need to overcome before this pattern can see widespread adoption:

- there doesn't seem to be a straightforward way to statically bind the frontend markup to the backend, so scaling this to multi-team apps will be a challenge.

- the markup and associated binding feels very similar to template-driven SPA frameworks (data- attributes for everything, really? That's fine in the resulting DOM tree but it's got to be a pain to author and maintain for large apps). Perhaps if someone could build a JSX-like code-to-markup DSL, that problem could be ameliorated.

- he is demoing it from his local machine, so we don't get to see (a) how much server-side compute is required at any scale (even >10 users), (b) how strongly latency can affect rendering, and (c) overall bandwidth requirements.

That being said, I know video game companies have streaming games deployed, so in theory this approach has merit (though I suspect only users who lack beefy home computers and have great internet connections opt for it).

Overall, this feels like less of an indictment of the SPA pattern in general* and more of a "let's see what happens if we change what we assume the constraints are."

*Yes, he's right that a lot of modern SPA development tooling is terrible. Dojo from the 2000s is still arguably easier to develop in than most modern SPA frontend stacks, especially since it can be run with only a static file server, no build required.

Re: URL-Driven State in HTMX

#183

Post by naasking » Sat, Aug 02, 2025, 4:27 AM UTC

TimTheTinker wrote: post #182

naasking wrote: post #181

Earlier quoted context omitted.

> 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 architectur…

That's a very impressive demo of Datastar, and I like his minimalist approach to frontend architecture. However, the display logic is implemented as a web component containing (a) a lot of tags written as a big HTML file for streaming state from the backend, and (b) a canvas element rendered by a WASM component. If that fits your definition of SSR for frontend apps, no problem and I think it's great. But that's not w…

I'm not indicting anything, I'm simply pointing out that there are a lot of assumptions that SPAs are the only or best way to have a great user experience, that server interactions are slow, that DOM updates are slow, and that API-based SPAs are the only way to solve all of these issues. The Datastar demo disproves all of these, regardless of how you feel about Datastar's specific approach to it.

Which leads me back to my original point that the only feature an SSR can't intrinsically provide is offline functionality.

Re: URL-Driven State in HTMX

#184

Post by Terretta » Sat, Aug 02, 2025, 7:13 PM UTC

TimTheTinker wrote: post #178

naasking wrote: post #177

Earlier quoted context omitted.

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…

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

Re: URL-Driven State in HTMX

#185

Post by TimTheTinker » Sun, Aug 03, 2025, 1:32 PM UTC

Terretta wrote: post #184

TimTheTinker wrote: post #178

Earlier quoted context omitted.

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…

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

It did, but they were slow & ugly or used Flash/ActiveX/Java.

Re: URL-Driven State in HTMX

#186

Post by RNCTX » Sun, Aug 03, 2025, 8:30 PM UTC

bob1029 wrote: post #79

podgorniy wrote: post #66

I think people are now ready for php. I bet it will be reinvented on top of nodejs.

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 i…

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

Re: URL-Driven State in HTMX

#187

Post by johnisgood » Tue, Aug 05, 2025, 9:05 AM UTC

johnisgood wrote: post #153

tonyedgecombe wrote: post #151

Earlier quoted context omitted.

Unless they have abandoned backwards compatibility then I don't think that is what I meant.

Major differences that I can think of between the two are (with regarding to warts and ease of use): PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on. PHP 8 has strong support for static typing now, thank goodness. PHP 8 introduces union types (int|float|null). PHP 8.1 introduces intersection types (A&B). PHP 8.1 added the "never" return typ…

Additionally, PHP 8.5 will have the pipe operator.

https://thephp.foundation/blog/2025/07/11/php-85-adds-pipe-o...

Re: URL-Driven State in HTMX

#188

Post by tonyedgecombe » Tue, Aug 12, 2025, 8:30 AM UTC

johnisgood wrote: post #153

tonyedgecombe wrote: post #151

Earlier quoted context omitted.

Unless they have abandoned backwards compatibility then I don't think that is what I meant.

Major differences that I can think of between the two are (with regarding to warts and ease of use): PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on. PHP 8 has strong support for static typing now, thank goodness. PHP 8 introduces union types (int|float|null). PHP 8.1 introduces intersection types (A&B). PHP 8.1 added the "never" return typ…

That's great but unless you have given up backwards compatibility then you are still going to have all the warts.