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

121–130 of 188 posts

Re: URL-Driven State in HTMX

#121

Post by jiggawatts »

zarzavat wrote: post #83
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…

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

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.

Re: URL-Driven State in HTMX

#123

Post by waynenilsen »

Twey wrote: post #15

The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. To get truly bookmarkable list URLs, the best approach I've seen is ‘page starting from item X’, where X is an effectively-unique ID for the item (e.g. a primary key, or a timestamp to avoid exposing IDs).

also significantly better for performance

Re: URL-Driven State in HTMX

#124

Post by Twey »

nebezb wrote: post #25
wackget wrote: post #22

Earlier quoted context omitted.

Dunno why you've been voted down; you're totally right. The method you mention is called token/cursor/keyset-based pagination.

He’s being downvoted because suggesting cursor pagination in an example describing sorting by price (descending) is plainly wrong. While neither is bookmarkable, cursor pagination is much worse. The UX went from “show me _almost_ the most expensive items” to “show me everything less expensive than the last item on the page I was on previously — which may be stocked out, more expensive, or heavily discounted today”. T…

If you believe that the user wants to see everything around a particular price point, e.g. because they've ordered their search results by price, then the correct cursor token is the price point of the top item (or the price point of the last item on the previous page, as an open bound, or even something fancier like the median price of the items in the page).

There's a choice to be made about semantics, and you have plenty of information given to you by the user in a search scenario, but ‘page 2’ is not the right choice because it has no useful semantics. If the user is hoping to bookmark the page it's because they want to preserve some property of the data for later, even in the face of data changes. I can almost guarantee that property isn't ‘items that happen to be on page 2 today’.

Re: URL-Driven State in HTMX

#125

Post by Twey »

runeks wrote: post #90
Twey wrote: post #15

The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. To get truly bookmarkable list URLs, the best approach I've seen is ‘page starting from item X’, where X is an effectively-unique ID for the item (e.g. a primary key, or a timestamp to avoid exposing IDs).

> The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. Why is the content changing between refreshes not "(helpfully) bookmarkable"? The HN front page (ie. "page 1") does that but it's a very useful bookmark.

The data in a bookmark may change, but it should preserve some property of interest — otherwise why bookmark it?

Page 1 (a.k.a. the top few results with no pagination) has the property of being the selected top of HN, which is an interesting property in its own right, and what we're bookmarking. Page 2 doesn't have that property.

Re: URL-Driven State in HTMX

#126

Post by 0x445442 »

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…

Complexity merchant... I like that.

Re: URL-Driven State in HTMX

#127

Post by recursivedoubts »

cnnlive789 wrote: post #115
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.

php is great but I’m surprised by how people are not discussing htmx. It’s a chance to start all over yet again! Come on- we’re all up for that, we do it every few months!

smdh!

Re: URL-Driven State in HTMX

#128

Post by 0x445442 »

user____name wrote: post #122

This is cute but merely points to the obvious solution of base64 encoding all page contents straight into the URL.

The bookmarkable ability is secondary to the filter parameters meaning. Once I know the parameters and their meaning I dont need the bookmark. In fact, I'd probably need to title the bookmark as something close to the URL anyway to know what it was actually referring to.

Re: URL-Driven State in HTMX

#129

Post by dilawar »

0x445442 wrote: post #126
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…

Complexity merchant... I like that.

https://chrlschn.dev/blog/2025/05/beware-the-complexity-merc...

Re: URL-Driven State in HTMX

#130

Post by jermaustin1 »

podgorniy wrote: post #66

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

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 the assembly is cached in memory for future requests to the same path, and it will recompile sources that are newer than the cached assembly.

There is no routing other than dropping the .chp extension if you pass "-ne" into the arguments launching the server.

It's not very far along, and is completely pointless other than for the sake of building my own web language thingy for the first time since 2003.

Post reply on HN