URL-Driven State in HTMX
137 comments
·July 29, 2025gortok
packetlost
tbh I always found it interesting that CGI was dropped as a well supported technology from languages like Python. It was incredibly simple to implement and reason about (provided you actually understand HTTP, maybe that's the issue), and scaled well beyond what most internal enterprise apps I was working on at the time needed.
podgorniy
I think people are now ready for php. I bet it will be reinvented on top of nodejs.
jermaustin1
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.
bob1029
Have you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings:
var reportPartial = @$"
<h1>{report.Name}</h1>
<table>
{string.Join('\n', report.Items.Select(reportItem => @$"
<tr>
<td>{reportItem.Col1}</td>
<td>{reportItem.Col2}</td>
</tr>
"))}
</table>
";
This is how I've been building my .NET web apps for the last ~3 years. @+$ = PHP in C# as far as I'm concerned.
bob1029
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.
swiftcoder
> 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
lelanthran
> 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?
zarzavat
> modern internet connection
Have you heard of these things called smartphones? I hear they're getting quite popular.
jiggawatts
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.
0x445442
Complexity merchant... I like that.
worldsayshi
What about a feature like query completion?
gwd
The query completion can also be SSR. The example below is HTMX for Active Search, but the principle is the same:
1oooqooq
html native datalist?
lyu07282
there probably is a jQuery plugin for that /s
donatj
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.
chuckadams
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.
mardifoufs
Like a super rich and very well tested front end client, that doesn't need a server to template everything for it?
jiggawatts
The most "special" code that I regularly come across is when a developer takes a JPG in blob storage -- already a public HTTPS URL -- then serves that in a "Web API" that converts it to base-64 encoded bytes inside JSON, sends it to client JavaScript, decodes it, and feeds it to an image in code.
Invariably, it's done with full buffering of the blob bytes in memory on both server and client, no streaming.
Bonus points are awarded for the use of TypeScript, compression (of already compressed JPGs, of course), and extensive unit and integration tests to try and iron out the bugs.
cnnlive789
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!
recursivedoubts
smdh!
mhd
I'm voting for Cold Fusion on top of Golang.
null
pjmlp
Too advanced typesystem for Go folks, better keep it on top of Java. /s
franky47
Indeed, the Platformatic folks announced just that last week:
https://blog.platformatic.dev/laravel-nodejs-php-in-watt-run...
pjmlp
I feel revindicated for staying with ASP.NET and JavaEE/Spring all these years.
Next.js is kind of bareable, as it uses the same approach, going back to the roots of web development, it is almost as doing JSPs all over again.
tonyedgecombe
I'd love to see a modern PHP without all the warts but with the ease of use.
inopinatus
It’s about time. We already reinvented Lotus Notes.
tonyedgecombe
Lotus Notes was great until they added email.
Twey
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).
bubblyworld
Yeah, solving this edge case properly can add a lot of complexity (your solution has the same problem, no? deletes would mess it up as would updates, technically). I've seen people using long-lived "idempotency tokens" point to an event log for this but it's a bit nuts. Definitely worth considering not solving it, which might be a more intuitive UX anyway (e.g. for leaderboards).
yxhuvud
It doesn't have the problem if a timestamp or similar is used.
runeks
> 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.
purerandomness
If you're bookmarking a directory, a list of things (e.g. the HN frontpage), you expect the content to change when opening the bookmark.
You bookmark a link to the directory so you don't forget the directory's entry URL.
The use case the author is talking about is a different one: You are configuring a complex item in a shop, and want to bookmark the URL so you can save it, recall it later, share this configuration with someone, or compare it with a different URL.
In this case, you also would expect little details to change (pricing, descriptions, photos) but the structure of the state should stay the same.
It's very frustrating when you share a link to a product detail page, only to discover that all your filters and configurations have been lost.
Twey
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.
high_na_euv
Indeed, thats weird.
He probably wants to freeze the state of the page. Maybe he should consider saving it via ctrl s
wackget
Dunno why you've been voted down; you're totally right. The method you mention is called token/cursor/keyset-based pagination.
nebezb
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”. The latter isn’t something you’d bookmark.
Twey
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’.
the_arun
I cannot think of any other way to bookmark anything static unless I convert it into pdf/screenshot before sharing. Are there better ways to bookmark a list page which guarantees same list forever?
tossandthrow
Well, this really depends on the intention: are you looking for the cheapest items, excluding the 20 first, or are you linking to a content list.
I use Occams razor to decide this, and conceptually it is simpler to think that you are linking to a content list - so that is likely the right answer.
bravesoul2
I agree. Most people won't expect urls to provide a wayback-machine style snapshot. Although you could add that as an option "save results as link".
crabmusket
Datomic + put the database version in the URL :)
waynenilsen
also significantly better for performance
DimmieMan
The JS world leaves me more and more perplexed.There's a similar rant about forms, but why is this so hard? Huge amount of dev time spent being able to execute asynchronous functions to the backend seamlessly yet pretty much every major framework is just rawdog the url string and deal with URLSearchParams object yourself.
Tanstack router[1] provides first class support for not only parsing params but giving you a typed URL helper, this should be the goal for the big meta frameworks but even tools like sveltekit that advertise themselves on simplicity and web standards have next to zero support.
I've seen even non JS frameworks, with like fifteen lines of documentation for half baked support of search params.
The industry would probably be better off if even a tenth of the effort that goes into doing literally anything to avoid learning the platform was spent making this (and post-redirect-get for forms) the path of least resistance for the 90% of the time search params are perfectly adequate.
I don't use HTMX but i do love how it and its community are pushing the rediscover of how much simpler things can be.
[1] https://tanstack.com/router/latest/docs/framework/react/guid...
switz
Nuqs[0] does a very good job at parsing and managing search params. It's a complex issue that involves serialization and deserialization, as well as throttling URL updates. It's a wonderful library. I agree, though, that it would be nice to see more native framework support for this.
Forms are also hard because they involve many different data-types, client-side state, (client?) and server validation, crossing the network boundary, contextual UI, and so on. These are not simple issues, no matter how much the average developer would love them to be. It's time we accept the problem domain as complex.
I will say that React Server Components are a huge step towards giving power back to the URL, while also allowing developers to access the full power of both the client and the server–but the community at large has deemed the mental model too complex. Notably, it enables you to build nuanced forms that work with or without javascript enabled, and handle crossing the boundary rather gracefully. After working with RSCs for several years now, I can't imagine going back. I've written several blog posts about them[1][2] and feel the community should invest more time into understanding their ideas.
I have a post in my drafts about how taking advantage of URL params properly (with or without RSCs) give our UIs object permanence. How we as web developers should be relying on them more and using it to reflect "client-side" state. Not always, but more often. But it's a hard post to finish as communicating and crystalizing these ideas are difficult. One day I'll get it out.
[1] https://saewitz.com/server-components-give-you-optionality
[2] https://saewitz.com/the-mental-model-of-server-components
DimmieMan
Don’t get me wrong, I never meant it was easy to solve, just that things could be better if search parameters didn’t somehow become this niche legacy thing with minimal appetite to fix.
Thanks for the point on RSC, probably the first argument I’ve heard that helps me contextualise why this extreme paradigm shift and tooling complexity is being pushed as the default.
throwaway54365
I prefer how Angular handles it. It's just HTML with bindings to an object
valenterry
> Tanstack router[1] provides first class support for not only parsing params but giving you a typed URL helper, this should be the goal for the big meta frameworks
Let's not pretend that the Tanstack solution would be good. For example, What if my form changes and a new field is added but someone still runs the old html/js and sends their form from the old code? Does Tanstack have any support to 1.) detect that situation 2.) analyze / monitor / log it (for easy debugging), 3.) automatically resolve it (if possible) and 4.) allow custom handling where automatic resolution isn't possible?
It doesn't look like it from the documentation.
Sorry, frustration is causing me to rant here, but it's a classical thing of the frontend-world and it causes so much frustration. In the backend-world, many (maybe even most) libraries/frameworks/protocols have builtin support for that. See graphql with it's default values and deprecation at least, see avro or protobuff with their support for versions, schema-history and even automatic migration.
When will I not have to deal with that by hand in my frontend-code anymore?
fny
The same thing should happen that happens with Rails/Django and friends: nothing. Most frameworks only parse URL params, they don't check to see if the params are valid given your app logic.
That's your job. Frankly, anything more would be over kill. Why should my url param manager handle new or removed form fields?
valenterry
> The same thing should happen that happens with Rails/Django and friends: nothing
So you can never make any breaking change to your api whatsoever? Or, in practice, you don't care and let users deal with app crashes and invalid state? Yep, welcome to the frontend-world.
btown
> treating URL parameters as your single source of truth... a URL like /?status=active&sortField=price&sortDir=desc&page=2 tells you everything about the current view
Hard disagree that there can be a single source of truth. There are (at least) 3 levels of state for parameter control, and I don't like when libraries think they can gloss over the differences or remove this nuance from the developer:
- The "in-progress" state of the UI widgets that someone is editing (from radio buttons to characters typed in a search box)
- The "committed" state that indicates the snapshot of those parameters that is actively desired to be loaded from the server; this may be debounced, or triggered by a Search button
- The "loaded" state that indicates what was most recently loaded from the server, and which (most likely) drives the data visualized in the non-parameter-controlling parts of the UI
What if someone types in a search bar but then hits "next page" - do we forget what they typed? What happens if you've just committed changes to your parameters, but data subsequently loaded from a prior commit? Do changes fire in sequence? Should they cancel prior requests or ignore their results? What happens if someone clicks a back button while requests are inflight, or while someone's typed uncommitted values into a pre-committed search bar? How do you visualize the loaded parameters as distinct from the in-progress parameters? What if some queries take orders of magnitude longer than others, and you want to provide guidance about this?
All of those questions and more will vary between applications. One size does not fit all.
If this comment resonates with you, choose and advocate for tooling that gives you the expressivity you feel in your gut that you'll need. Especially in a world of LLMs, terse syntax and implicit state management may not be worth losing that expressivity.
chii
> All of those questions and more will vary between applications. One size does not fit all.
all of those come from the fundamental "requirement" set out earlier to have no in-page state, but still require the webpage to behave as tho it did.
If you remove this requirement, then it will be like how it was back in the 2000's era web pages! And the url does indeed contain the single source of truth - there are no inflight requests that are not also a full page reloads.
tempfile
The example they used for "in progress" state was form inputs. Don't you count those as in-page state?
chii
until you pressed enter, this progress is understood to be ephemeral. It has only been recently that the user has been 'conditioned' to expect the form inputs to be retained when they click a link, and it's because the app is trying to retain the state of ephemeral progress.
So you cannot have both a webpage that is not an app, but maintain an app-like behaviour. Trying to do so is a cursed problem, and it might succeed with high effort, but ultimately not worth it.
delifue
Yes the simple solution is obviously not perfect in edge cases. It's a tradeoff between simplicity and edge-case-perfectness.
In my opinion the higher priority task is to optimize the query in backend so that it can refresh quickly. If loading is quick enough then that edge case will be less likely to happen.
Arch-TK
Next you'll tell me the URL can contain information which can be used to auto-scroll you to a specific heading.
johnisgood
Not even only that, but it can auto-scroll to ANY parts these days, see: "URL Text Fragments".
https://www.lexo.ch/blog/2025/01/highlight-text-on-page-and-...
In any case, yeah, what was suggested in the submission is nothing esoteric, but I guess everything can be new to someone.
aaronbrethorst
Sorcery!
PaulHoule
This is a classic pattern of web applications from the 1990s. Works amazingly well even w/o HTMX
nosefurhairdo
One of the legitimate grievances of SPAs is that they made this pattern less obvious.
pjmlp
More like we have a whole generation educated in bootcamps that think they need SPAs for doing anything.
PaulHoule
I find the whole thing where you configure your web server to serve the same thing from
http://example.com/application
http://example.com/application/with/path?and=parameters
http://example.com/item/448828
http://api.example.com/item/448827
http://api.example.com/item/448828
http://api.example.com/item/448829
eadmund
What I would want is to GET http://example.com/item/448828 with an Accept header of ‘application/s-expression,application/json;q=0.1’ instead of retrieving the HTML representation of the resource. HTTP is the API.
I also want http://example.com/application/with/path?and=parameters and http://example.com/application to return Link headers with rel=canonical appropriately.
I’d also like world peace.
fny
Coming up next: moving JS outside of markup with selectors.
TimTheTinker
I had a similar strategy when building early web apps with jQuery and ExtJS (but using the URL hash before the History API was available). Just read from location.hash during page load and write to it when the form state changes.
For more complex state (like table layout), I used to save it as a JSON object, then compress and base64 encode it, and stick it in the URL hash. Gave my users a bookmarklet that would create a shortened URL (like https://example.com/url/1afe9) from my server if they needed to share it.
sghiassy
It’s still unfortunately contentious in many development circles :/
user____name
This is cute but merely points to the obvious solution of base64 encoding all page contents straight into the URL.
0x445442
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.
junto
I find it deeply ironic that we have come full circle, and Javascripters have reinvented what we had 20 years ago.
lexicality
I'm not sure that it really counts as ironic when HTMX was conceived specifically to try and get people to stop writing megabytes of JS and to go back to the old ways.
_heimdall
This is a great pattern to follow, and I highly recommend understanding it even to those working on projects that are full client-side SPAs.
Its too easy to jump right in to react, NextJS, etc. Learning why URLs work the way they work is still extremely useful. Eventually you will want to support deep linking, and when you do the URL suddenly becomes really important.
Remix has also been really interesting on this front. They leaned heavily into web standards, including URLs as a way of managing state.
vyrotek
The syncing of the state reminded me a lot of datastar Signals. And a little bit of ASP.NET ViewState.
ashwinsundar
Makes sense, HTMX and Datastar both have a common philosophical ancestor in HATEOAS
So until about 2013? 2014? URL-driven state was just the way everything worked.
One of the major complaints of `cgi-bin` was that you had to manually add back to the URL to manage state (and of that time, there were a good number of cgi-bin applications that just didn't bother -- which unsurprisingly is how the SPAs worked at first until "URL Routing" took over).
But, all of this is literally just reinventing the wheel that's been there since the web began. The entire purpose of the web was to be able to link to a specific resource, action, or state without having to to anything other than share a URL.
What's wild is there are whole generations of programmers that started programming after the SPA world debuted and are now re-learning things that "were just the way things were" before 2013.