Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URL-Driven State in HTMX

lorenstew.art

Post reply on HN
Print view View original

141–150 of 188 posts

Re: URL-Driven State in HTMX

#141

Post by _1tem »

ebiester wrote: post #139
bob1029 wrote: post #79

Earlier quoted context omitted.

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…

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

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

Re: URL-Driven State in HTMX

#142

Post by johnisgood »

tonyedgecombe wrote: post #111
podgorniy wrote: post #66

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

I'd love to see a modern PHP without all the warts but with the ease of use.

I think you are in for a treat, then, because PHP 8 is way different from PHP 5.

Re: URL-Driven State in HTMX

#143

Post by naasking »

ebiester wrote: post #139
bob1029 wrote: post #79

Earlier quoted context omitted.

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…

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

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.

Re: URL-Driven State in HTMX

#144

Post by naasking »

bob1029 wrote: post #134
jermaustin1 wrote: post #130

Earlier quoted context omitted.

I actually started my own PHP based on C# called CHP for fun. It runs atop whatever the current dotnet hosting service is (Kestrel?). It takes everything inside the " " code blocks and inlines it into one big Main method, exposing a handful of shared public convenience methods (mostly around database access and easy cookie-based authentication), as well as the request and response objects. Each request is JITed, then…

Have you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings: var reportPartial = @$" {report.Name} {string.Join('\n', report.Items.Select(reportItem => @$" {reportItem.Col1} {reportItem.Col2} "))} "; In more complex views or reuse scenarios, I'd push the inner interpolation loop to a method. This is how I've been building my .…

Some dangers with injection attacks if you don't santitize inputs correctly, but this is probably faster than most templating languages like razor.

Re: URL-Driven State in HTMX

#145

Post by teddyh »

I remember that before cookies were widely implemented in web browsers, the Spinner web server (effectively an early web server and development framework in one process) implemented what it called ”prestate”; a parenthesised portion of the URL, part of the path, but before the actual path. Like this: http://example.com/(tables,images)/developers/

Re: URL-Driven State in HTMX

#146

Post by lcnPylGDnU4H9OF »

jarofgreen wrote: post #92

> SEO is built in since search engines can crawl every state combination. This isn't always a plus - bots can find a very large number of pages to crawl and swamp your server with traffic. Maybe they would get stuck on all the combinations of listing page filters and miss the important pages. Not saying the conclusion is wrong - just something to consider.

> all the combinations of listing page filters

A public-facing page at $DAYJOB has 44 boolean filters for a bunch of different hardware components (think screws and fasteners rather than boards and drives), meaning 2^44 different combinations ~= 17 trillion different pages to crawl (from the disrespectful AI crawler's perspective).

That said, it wasn't really an issue except we had a misconfiguration in the in-memory caching database we were using so it didn't delete old stuff from memory and started writing to disk, which meant that we ran out of our (millions of) file inodes on the production server. Just saying to point out that keeping the state in the URL wasn't the problem in this case, and it is generally not a problem; it can be a problem but, when it is, it will be obvious why.

Re: URL-Driven State in HTMX

#147

Post by endemic »

worldsayshi wrote: post #80
bob1029 wrote: post #79

Earlier quoted context omitted.

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…

What about a feature like query completion?

SSR doesn't mean "no JavaScript." See "progressive enhancement."

Re: URL-Driven State in HTMX

#148

Post by robertoandred »

> When you move from React to HTMX, you trade complex state management for server-side simplicity.

Managing the same state will have the same complexity on the server as it does on the client. HTMX's smugness is a huge turnoff.

Re: URL-Driven State in HTMX

#150

Post by endemic »

chuckadams wrote: post #132
donatj wrote: post #97

Earlier quoted context omitted.

As a long time PHP developer, it never fails to amuse (amaze?) me the lengths people go to in order to get the things the browser will give you for free.

The browser gives you a full-blown programming language with a rich API, but it seems a lot of people avoid that in favor of smushing together a static view on the server side with little more than string interpolation.

I'd prefer not to download 2MB of JavaScript and feel my phone get uncomfortably hot just to fill out your online form.
Post reply on HN