14 ms·

URL-Driven State in HTMX

304 points by lorenstewart 1y ago

torstenvl 1y ago
Ideally, this is how state management should work all the time, regardless. Holding too much state server-side breaks bookmarks and shares. EDIT: Hmm. Is this comment controversial? Obviously some people disagree strongly. Mind sharing why?
- patates 1y ago
  didn't down-vote you but perhaps you mean tech which holds nearly all client state on the server like JSF or webforms and I think that may be not so clear to some :) for front-end frameworks, not storing the state on the URL usually means storing it on the memory or sessionstorage and server is usually not involved
cadamsdotcom 1y ago
This pattern - saving the query to the URL with the history API - is fantastic UX but never gets implemented because there’s never time. Luckily an LLM can build this quickly as it’s straightforward and mostly boilerplate. Still the boilerplate makes me wonder if it belongs in a library, eg. a React hook that’s a drop in replacement for `useState`. Backend logic would still need to be implemented. Does something like this exist?
- monadoid 1y ago
  Agreed I love this pattern! I'm a big fan of using nuqs for this in nextjs, but really stoked to try out rust / loco / htmx for my next project.
- PaulHoule 1y ago
  Doesn't react-router do something like this?
  - nosefurhairdo 1y ago
    Yep, `useSearchParams()`. At work I built a wrapper to incorporate zod schemas for typesafe search param state. Nuqs is the best for this if your application meets its prerequisites: https://nuqs.47ng.com/ https://nuqs.47ng.com/
- t-writescode 1y ago
  > is fantastic UX but never gets implemented because there’s never time Wouldn't the change take something like an hour the first time you implement it and then 10s of seconds for calling the centralized function henceforth? I don't think the problem is "there's never time"; and if that is the problem, I don't think an LLM will "solve" that, especially since studies have shown developers are slower when they use LLMs to code for them.
- crab_galaxy 1y ago
  > never gets implemented because there’s never time In my experience that time is saved and more when you find you no longer need to manage Zustand/redux stores to track application state. This pattern works beautifully when incorporating the query parameters as query keys with tan stack query too.
- c-hendricks 1y ago
  At work we have a hook for that with various backends (memory, local storage, redux, and search params). Supports page, offset, and cursor pagination. https://stackblitz.com/edit/github-8ssor8-rqkyew8w?file=src%2FInfinite.tsx%3AL30-L48 https://stackblitz.com/edit/github-8ssor8-rqkyew8w?file=src%...
- franky47 1y ago
  > Still the boilerplate makes me wonder if it belongs in a library, eg. a React hook that’s a drop in replacement for `useState` That’s exactly what `nuqs` does (disclaimer: I’m the author). > Backend logic would still need to be implemented Assuming your backend is written in TypeScript, you can use nuqs loaders to reuse the same validation logic on both sides. https://nuqs.47ng.com https://nuqs.47ng.com
rorylaitila 1y ago
I didn't see if you were doing this, but there is an additional use case that I had when using hot swapping like HTMX: updating other links on the page to reflect the URL state, when those links are outside of the swapped content. While the server can use the URLs to update the links in the new HTML, if other links outside that content should also reflect the changes params, you need to manually update them. In my progressive enhancement library I call this 'sync-params' https://github.com/roryl/zsx?tab=readme-ov-file#synchronize-url-parameters-across-links https://github.com/roryl/zsx?tab=readme-ov-file#synchronize-...
- trentnix 1y ago
  Isn’t that what hx-swap-oob is for?
  - rorylaitila 1y ago
    Maybe, I'm not an HTMX user, but looking at hx-swap-oob I think that solves another issue. My need was when other links can exist in any place, and they need to match the URL after its clicked. I didn't want to have the performance hit or remember to add extra swaps just to get links up to date. The feature basically is "when a param is marked to be synced, ensure all links on the page are updated to match the changed param"
    - trentnix 1y ago
      I’ve been building a Golang web platform for my own web apps and I wired up toaster notifications using hx-swap-oob. I just populate a ‘notifications’ slice in my view model and hx-swap-oob makes sure my toaster messages get loaded irrespective of what content is actually being swapped. It sounds like a similar use case to yours.
      - PenguinCoder 1y ago
        Are you able to share the code you have for this? I have a similar need use case and using golang and Htmx for my app.
o11c 1y ago
Note that you can store longer state (at least 64K; more not tested) in the fragment (`location.hash`); obviously only the client gets to see this, but it's better than nothing (and JS can send it to the server if really needed). For parameters the server does need to see, remember that params need not be &-separated kv pairs, it can be arbitrary text. Keys can usually be eliminated and just hard-coded in the web page; this may make short params longer but likely makes long ones shorter. You absolutely should not restore state based on LocalStorage; that breaks the whole advantage of doing this properly! If I wanted previous state, I would've navigated my history thereto. I hope this isn't as bad as sites that break with multiple open tabs at least ...
- NegativeLatency 1y ago
  I've seem a largish company everyone here knows of, try this and have it fail, because of various weird client things, and also eventually run out of space in the hash. It's a neat hack but I wouldn't rely on it.
  - wredcoll 1y ago
    Oh boy, hashbangs are back. The first one that comes to mind was twitter...
    - mediumsmart 1y ago
      I think LinkedIn won the stuffedURLbufferOverflow Olympics back in the day.
  - ashwinsundar 1y ago
    They failed as a company?
    - NegativeLatency 1y ago
      Still around doing, eh fine. But they abandoned the url hash params with an id that references params on the backend (a mess!)
PaulHoule 1y ago
This is a classic pattern of web applications from the 1990s. Works amazingly well even w/o HTMX
- nosefurhairdo 1y ago
  One of the legitimate grievances of SPAs is that they made this pattern less obvious.
  - PaulHoule 1y ago
    I find the whole thing where you configure your web server to serve the same thing from http://example.com/application and http://example.com/application/with/path?and=parameters to be absolutely nerve-wracking. Not hard to do but it's just batshit crazy and breaks the whole idea of how web crawlers are supposed to work. On the other hand, we had trouble with people (who we know want to crawl us specifically) crawling a site where you visit http://example.com/item/448828 and it loads an SPA which in turn fetches a well-structured JSON documents like http://api.example.com/item/448827 http://api.example.com/item/448828 http://api.example.com/item/448829 with no cache so it downloads megabytes of HTML, Javascript, Images and who knows what -- and if they want to deal with the content in a structured way and it put it in a database it's already in the exact format they want. But I guess it's easier to stand up a Rube Goldberg machine and write parsers when you could look at our site in the developers tools and figure out how it works in five minutes... and just load those JSON documents into a document database and be querying right out of the gate.
    - eadmund 1y ago
      What I would want is to GET http://example.com/item/448828 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 http://example.com/application/with/path?and=parameters and http://example.com/application http://example.com/application to return Link headers with rel=canonical appropriately. I’d also like world peace.
Twey 1y ago
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).
- wackget 1y ago
  Dunno why you've been voted down; you're totally right. The method you mention is called token/cursor/keyset-based pagination.
  - nebezb 1y ago
    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.
    - the_arun 1y ago
      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?
      - oxidant 1y ago
        Not if the items change relative position over time.
      - scarmig 1y ago
        This depends on use case and who or what is actually consuming the pages. Most of the time, humans don't actually want the same list for all time (though what follows would work for them). The only way to have a static list is to have an identifier for the state of the list at a certain time, or a field that allows you to reconstruct the list (e.g. a timestamp). This also means you need to store your items' data so the list of items can be reconstructed. Concretely, this might mean a query parameter for the list at a certain time (time=Xyz). When you paginate, either a cursor-based approach, an offset approach, or a page number approach would all work. This is not what most human users want: they would see deleted items, wouldn't see added items, and changes to fields you might sort on wouldn't be reflected in the list ordering. But it's ideal for many automated use cases. ETA: If you're willing to restrict users to a list of undeletable items that is always sorted, ascending, by time of item creation, you can also get by with any strategy for pagination. The last page might get new items appended, and you might get new pages, but any existing pages besides the last page won't change.
cloudking 1y ago
I like the simplicity. I've been building some web apps with Alpine.js recently, another lightweight React alternative. It's pretty powerful and capable for building reactive SPAs, only ~16kb. https://alpinejs.dev/ https://alpinejs.dev/ https://github.com/alpinejs/alpine https://github.com/alpinejs/alpine
- aitchnyu 1y ago
  There is Alpine Ajax, their HTMX counterpart. https://alpine-ajax.js.org/ https://alpine-ajax.js.org/
Arch-TK 1y ago
Next you'll tell me the URL can contain information which can be used to auto-scroll you to a specific heading.
- aaronbrethorst 1y ago
  Sorcery!
- johnisgood 1y ago
  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-scroll-to-it-using-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.
Gilipe 1y ago
Our dealership listings page is largely run with this pattern, as well as most of our plugins. Nothing new and very dependable. Forgo HTMX for one less dependency.
_heimdall 1y ago
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.
DimmieMan 1y ago
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/guide/search-params https://tanstack.com/router/latest/docs/framework/react/guid...
- switz 1y ago
  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. [0] https://nuqs.47ng.com https://nuqs.47ng.com [1] https://saewitz.com/server-components-give-you-optionality https://saewitz.com/server-components-give-you-optionality [2] https://saewitz.com/the-mental-model-of-server-components https://saewitz.com/the-mental-model-of-server-components
AdieuToLogic 1y ago
On a related note, I've found combining htmx with Parsley[0] to be very powerful for adding client-side validation to declarative server-rendered HTML form definitions. All that is needed is a simple htmx extension[1] and applicable data attribute use. 0 - https://parsleyjs.org/doc/index.html https://parsleyjs.org/doc/index.html 1 - https://htmx.org/docs/#extensions https://htmx.org/docs/#extensions
btown 1y ago
> 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.
- delifue 1y ago
  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.
- chii 1y ago
  > 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.
vyrotek 1y ago
The syncing of the state reminded me a lot of datastar Signals. And a little bit of ASP.NET ViewState. https://data-star.dev/guide/reactive_signals https://data-star.dev/guide/reactive_signals
- ashwinsundar 1y ago
  Makes sense, HTMX and Datastar both have a common philosophical ancestor in HATEOAS
emmelaich 1y ago
Another reminder of Programming inside the URL String. https://apenwarr.ca/log/20121218 https://apenwarr.ca/log/20121218
TimTheTinker 1y ago
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 https://example.com/url/1afe9) from my server if they needed to share it.
- sghiassy 1y ago
  It’s still unfortunately contentious in many development circles :/
kazinator 1y ago
URL-driven state? Sounds like a "take that" upper cut to the jaw of the RESTful opponent.
bravesoul2 1y ago
Please do! Dropping deep links with state is very useful. It cant be used for everything. E.g. not dark mode!
aitchnyu 1y ago
My HTMX side project uses Rison to store nested objects without unreadable encoding or handmade parsing. https://github.com/Nanonid/rison https://github.com/Nanonid/rison
podgorniy 1y ago
I think people are now ready for php. I bet it will be reinvented on top of nodejs.
- edu 1y ago
  I think they go with a PHP implementation on WASM so it runs on the client
- mhd 1y ago
  I'm voting for Cold Fusion on top of Golang.
  - deleted 1y ago
    [deleted]
  - pjmlp 1y ago
    Too advanced typesystem for Go folks, better keep it on top of Java. /s
- inopinatus 1y ago
  It’s about time. We already reinvented Lotus Notes.
  - tonyedgecombe 1y ago
    Lotus Notes was great until they added email.
- Etheryte 1y ago
  Given you can run Doom on your fridge these days, it should be absolutely no surprise that you can already run PHP both in the browser and in Node [0]. [0] https://github.com/asmblah/uniter https://github.com/asmblah/uniter
- bob1029 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. 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.
justsayinnnn 1y ago
Finally we are getting out of Hipster tech territory and back to something that makes sense. Thank you HTMX.
- fny 1y ago
  Putting JavaScript directly in your markup with bespoke attributes is extremely hipster.
- robertoandred 1y ago
  JS has always been able to work with URLs. Thinking it can't and HTMX is some sort of savior is the real hipster territory.
junto 1y ago
I find it deeply ironic that we have come full circle, and Javascripters have reinvented what we had 20 years ago.
- lexicality 1y ago
  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.
deleted 1y ago
[deleted]
tomtomistaken 1y ago
We were experimenting with saving states in URLs with https://libmap.org https://libmap.org. Sharing these URLs on mastodon.social would add the post to the map.
ac130kz 1y ago
>URLs up to ~2000 characters Exactly, this approach doesn't scale well without trickery involved. You have to have some sort of weird encoding in place to compact it down.
- rbinv 1y ago
  Yup, ASP's "__VIEWSTATE" hidden form parameter comes to mind. It was base64-encoded and POSTed because it could get loooong (hundreds of KB). Terrible for browser navigation/refresh though, because pretty much everything was a form POST. Thus no URL state sharing, either.
  - bux93 1y ago
    Also a terrible idea to execute code from the client, even if it's supposedly signed. https://darkatlas.io/blog/critical-sharepoint-vulnerability-cve-2025-53770-remote-code-execution-via-viewstate-abuse https://darkatlas.io/blog/critical-sharepoint-vulnerability-...
gloosx 1y ago
It's just how web works – storing data in URL params to restore the same state later. With React or whatever library you do the exactly same thing. In this case HTMX doesn't particularly stand out or enable anything new here.
- runeks 1y ago
  > With React or whatever library you do the exactly same thing. There are many React SPAs where the address bar URL rarely changes, and I have to find some "share" button on the page itself to get the page's URL.
  - gloosx 1y ago
    This is a generalization from personal exposure, availability bias. It just points out that some people implement things poorly — ignoring that many well-designed SPAs do use URL state effectively. React itself does not prevent or discourage URL-based state, it's just the developer's choice whether to use routing or no.
hamdouni 1y ago
Funny to see query parameters used as intended ... few decades ago
jarofgreen 1y ago
> 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.
- Chiron1991 1y ago
  That's why you can give guidance to crawlers using sitemaps.
  - Quarrel 1y ago
    Which, just like robots.txt, worked decently well until the AI bot crawlers overwhelmed all else.
- lcnPylGDnU4H9OF 1y ago
  > 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.
theanonymousone 1y ago
I'm currently writing a single-file web application in "Java" using JBang, J2Html, and Javalin (+htmx). It's so refreshing!
user____name 1y ago
This is cute but merely points to the obvious solution of base64 encoding all page contents straight into the URL.
- 0x445442 1y ago
  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.
gortok 1y ago
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.
- packetlost 1y ago
  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.
teddyh 1y ago
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/ http://example.com/(tables,images)/developers/
robertoandred 1y ago
> 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.
- recursivedoubts 1y ago
  depends how much state is accidental vs essential: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ while I certainly try to be funny online, I hope I'm reasonably even handed about the tradeoffs associated with the hypermedia approach: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand
colgandev 1y ago
HTMX has given me so much joy. I love Django and was there near the beginning. For a while I thought I had to switch to something like FastAPI and Vue etc to make relevant web apps and sites, but with Django recently adding async, Django Ninja, and HTMX, I'd reach for Django now for almost anything besides a few specific use cases. So many problems I've run into with newer tools feel like they were already solved years ago if you can SSR. Not that the newer tools don't have their place and they have plenty of good ideas, but it's been fun to see Django stay relevant and for more of the included batteries to be useful again (forms, templates, etc).

304 points by lorenstewart 1y ago

Ideally, this is how state management should work all the time, regardless. Holding too much state server-side breaks bookmarks and shares. EDIT: Hmm. Is this comment controversial? Obviously some people disagree strongly. Mind sharing why?

patates 1y ago
didn't down-vote you but perhaps you mean tech which holds nearly all client state on the server like JSF or webforms and I think that may be not so clear to some :) for front-end frameworks, not storing the state on the URL usually means storing it on the memory or sessionstorage and server is usually not involved

cadamsdotcom 1y ago

This pattern - saving the query to the URL with the history API - is fantastic UX but never gets implemented because there’s never time. Luckily an LLM can build this quickly as it’s straightforward and mostly boilerplate. Still the boilerplate makes me wonder if it belongs in a library, eg. a React hook that’s a drop in replacement for `useState`. Backend logic would still need to be implemented. Does something like this exist?

monadoid 1y ago
Agreed I love this pattern! I'm a big fan of using nuqs for this in nextjs, but really stoked to try out rust / loco / htmx for my next project.
PaulHoule 1y ago
Doesn't react-router do something like this?
- nosefurhairdo 1y ago
  Yep, `useSearchParams()`. At work I built a wrapper to incorporate zod schemas for typesafe search param state. Nuqs is the best for this if your application meets its prerequisites: https://nuqs.47ng.com/ https://nuqs.47ng.com/
t-writescode 1y ago
> is fantastic UX but never gets implemented because there’s never time Wouldn't the change take something like an hour the first time you implement it and then 10s of seconds for calling the centralized function henceforth? I don't think the problem is "there's never time"; and if that is the problem, I don't think an LLM will "solve" that, especially since studies have shown developers are slower when they use LLMs to code for them.
crab_galaxy 1y ago
> never gets implemented because there’s never time In my experience that time is saved and more when you find you no longer need to manage Zustand/redux stores to track application state. This pattern works beautifully when incorporating the query parameters as query keys with tan stack query too.
c-hendricks 1y ago
At work we have a hook for that with various backends (memory, local storage, redux, and search params). Supports page, offset, and cursor pagination. https://stackblitz.com/edit/github-8ssor8-rqkyew8w?file=src%2FInfinite.tsx%3AL30-L48 https://stackblitz.com/edit/github-8ssor8-rqkyew8w?file=src%...
franky47 1y ago
> Still the boilerplate makes me wonder if it belongs in a library, eg. a React hook that’s a drop in replacement for `useState` That’s exactly what `nuqs` does (disclaimer: I’m the author). > Backend logic would still need to be implemented Assuming your backend is written in TypeScript, you can use nuqs loaders to reuse the same validation logic on both sides. https://nuqs.47ng.com https://nuqs.47ng.com

rorylaitila 1y ago

I didn't see if you were doing this, but there is an additional use case that I had when using hot swapping like HTMX: updating other links on the page to reflect the URL state, when those links are outside of the swapped content. While the server can use the URLs to update the links in the new HTML, if other links outside that content should also reflect the changes params, you need to manually update them. In my progressive enhancement library I call this 'sync-params' https://github.com/roryl/zsx?tab=readme-ov-file#synchronize-url-parameters-across-links https://github.com/roryl/zsx?tab=readme-ov-file#synchronize-...

trentnix 1y ago
Isn’t that what hx-swap-oob is for?
- rorylaitila 1y ago
  Maybe, I'm not an HTMX user, but looking at hx-swap-oob I think that solves another issue. My need was when other links can exist in any place, and they need to match the URL after its clicked. I didn't want to have the performance hit or remember to add extra swaps just to get links up to date. The feature basically is "when a param is marked to be synced, ensure all links on the page are updated to match the changed param"
  - trentnix 1y ago
    I’ve been building a Golang web platform for my own web apps and I wired up toaster notifications using hx-swap-oob. I just populate a ‘notifications’ slice in my view model and hx-swap-oob makes sure my toaster messages get loaded irrespective of what content is actually being swapped. It sounds like a similar use case to yours.
    - PenguinCoder 1y ago
      Are you able to share the code you have for this? I have a similar need use case and using golang and Htmx for my app.

o11c 1y ago

Note that you can store longer state (at least 64K; more not tested) in the fragment (`location.hash`); obviously only the client gets to see this, but it's better than nothing (and JS can send it to the server if really needed). For parameters the server does need to see, remember that params need not be &-separated kv pairs, it can be arbitrary text. Keys can usually be eliminated and just hard-coded in the web page; this may make short params longer but likely makes long ones shorter. You absolutely should not restore state based on LocalStorage; that breaks the whole advantage of doing this properly! If I wanted previous state, I would've navigated my history thereto. I hope this isn't as bad as sites that break with multiple open tabs at least ...

NegativeLatency 1y ago
I've seem a largish company everyone here knows of, try this and have it fail, because of various weird client things, and also eventually run out of space in the hash. It's a neat hack but I wouldn't rely on it.
- wredcoll 1y ago
  Oh boy, hashbangs are back. The first one that comes to mind was twitter...
  - mediumsmart 1y ago
    I think LinkedIn won the stuffedURLbufferOverflow Olympics back in the day.
- ashwinsundar 1y ago
  They failed as a company?
  - NegativeLatency 1y ago
    Still around doing, eh fine. But they abandoned the url hash params with an id that references params on the backend (a mess!)

PaulHoule 1y ago

This is a classic pattern of web applications from the 1990s. Works amazingly well even w/o HTMX

nosefurhairdo 1y ago
One of the legitimate grievances of SPAs is that they made this pattern less obvious.
- PaulHoule 1y ago
  I find the whole thing where you configure your web server to serve the same thing from http://example.com/application and http://example.com/application/with/path?and=parameters to be absolutely nerve-wracking. Not hard to do but it's just batshit crazy and breaks the whole idea of how web crawlers are supposed to work. On the other hand, we had trouble with people (who we know want to crawl us specifically) crawling a site where you visit http://example.com/item/448828 and it loads an SPA which in turn fetches a well-structured JSON documents like http://api.example.com/item/448827 http://api.example.com/item/448828 http://api.example.com/item/448829 with no cache so it downloads megabytes of HTML, Javascript, Images and who knows what -- and if they want to deal with the content in a structured way and it put it in a database it's already in the exact format they want. But I guess it's easier to stand up a Rube Goldberg machine and write parsers when you could look at our site in the developers tools and figure out how it works in five minutes... and just load those JSON documents into a document database and be querying right out of the gate.
  - eadmund 1y ago
    What I would want is to GET http://example.com/item/448828 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 http://example.com/application/with/path?and=parameters and http://example.com/application http://example.com/application to return Link headers with rel=canonical appropriately. I’d also like world peace.

Twey 1y ago

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

wackget 1y ago
Dunno why you've been voted down; you're totally right. The method you mention is called token/cursor/keyset-based pagination.
- nebezb 1y ago
  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.
  - the_arun 1y ago
    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?
    - oxidant 1y ago
      Not if the items change relative position over time.
    - scarmig 1y ago
      This depends on use case and who or what is actually consuming the pages. Most of the time, humans don't actually want the same list for all time (though what follows would work for them). The only way to have a static list is to have an identifier for the state of the list at a certain time, or a field that allows you to reconstruct the list (e.g. a timestamp). This also means you need to store your items' data so the list of items can be reconstructed. Concretely, this might mean a query parameter for the list at a certain time (time=Xyz). When you paginate, either a cursor-based approach, an offset approach, or a page number approach would all work. This is not what most human users want: they would see deleted items, wouldn't see added items, and changes to fields you might sort on wouldn't be reflected in the list ordering. But it's ideal for many automated use cases. ETA: If you're willing to restrict users to a list of undeletable items that is always sorted, ascending, by time of item creation, you can also get by with any strategy for pagination. The last page might get new items appended, and you might get new pages, but any existing pages besides the last page won't change.

cloudking 1y ago

I like the simplicity. I've been building some web apps with Alpine.js recently, another lightweight React alternative. It's pretty powerful and capable for building reactive SPAs, only ~16kb. https://alpinejs.dev/ https://alpinejs.dev/ https://github.com/alpinejs/alpine https://github.com/alpinejs/alpine

aitchnyu 1y ago
There is Alpine Ajax, their HTMX counterpart. https://alpine-ajax.js.org/ https://alpine-ajax.js.org/

Arch-TK 1y ago

Next you'll tell me the URL can contain information which can be used to auto-scroll you to a specific heading.

aaronbrethorst 1y ago
Sorcery!
johnisgood 1y ago
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-scroll-to-it-using-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.

Gilipe 1y ago

Our dealership listings page is largely run with this pattern, as well as most of our plugins. Nothing new and very dependable. Forgo HTMX for one less dependency.

_heimdall 1y ago

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.

DimmieMan 1y ago

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/guide/search-params https://tanstack.com/router/latest/docs/framework/react/guid...

switz 1y ago
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. [0] https://nuqs.47ng.com https://nuqs.47ng.com [1] https://saewitz.com/server-components-give-you-optionality https://saewitz.com/server-components-give-you-optionality [2] https://saewitz.com/the-mental-model-of-server-components https://saewitz.com/the-mental-model-of-server-components

AdieuToLogic 1y ago

On a related note, I've found combining htmx with Parsley[0] to be very powerful for adding client-side validation to declarative server-rendered HTML form definitions. All that is needed is a simple htmx extension[1] and applicable data attribute use. 0 - https://parsleyjs.org/doc/index.html https://parsleyjs.org/doc/index.html 1 - https://htmx.org/docs/#extensions https://htmx.org/docs/#extensions

btown 1y ago

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

delifue 1y ago
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.
chii 1y ago
> 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.

vyrotek 1y ago

The syncing of the state reminded me a lot of datastar Signals. And a little bit of ASP.NET ViewState. https://data-star.dev/guide/reactive_signals https://data-star.dev/guide/reactive_signals

ashwinsundar 1y ago
Makes sense, HTMX and Datastar both have a common philosophical ancestor in HATEOAS

emmelaich 1y ago

Another reminder of Programming inside the URL String. https://apenwarr.ca/log/20121218 https://apenwarr.ca/log/20121218

TimTheTinker 1y ago

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 https://example.com/url/1afe9) from my server if they needed to share it.

sghiassy 1y ago
It’s still unfortunately contentious in many development circles :/

kazinator 1y ago

URL-driven state? Sounds like a "take that" upper cut to the jaw of the RESTful opponent.

bravesoul2 1y ago

Please do! Dropping deep links with state is very useful. It cant be used for everything. E.g. not dark mode!

aitchnyu 1y ago

My HTMX side project uses Rison to store nested objects without unreadable encoding or handmade parsing. https://github.com/Nanonid/rison https://github.com/Nanonid/rison

podgorniy 1y ago

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

edu 1y ago
I think they go with a PHP implementation on WASM so it runs on the client
mhd 1y ago
I'm voting for Cold Fusion on top of Golang.
- deleted 1y ago
  [deleted]
- pjmlp 1y ago
  Too advanced typesystem for Go folks, better keep it on top of Java. /s
inopinatus 1y ago
It’s about time. We already reinvented Lotus Notes.
- tonyedgecombe 1y ago
  Lotus Notes was great until they added email.
Etheryte 1y ago
Given you can run Doom on your fridge these days, it should be absolutely no surprise that you can already run PHP both in the browser and in Node [0]. [0] https://github.com/asmblah/uniter https://github.com/asmblah/uniter
bob1029 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. 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.

justsayinnnn 1y ago

Finally we are getting out of Hipster tech territory and back to something that makes sense. Thank you HTMX.

fny 1y ago
Putting JavaScript directly in your markup with bespoke attributes is extremely hipster.
robertoandred 1y ago
JS has always been able to work with URLs. Thinking it can't and HTMX is some sort of savior is the real hipster territory.

junto 1y ago

I find it deeply ironic that we have come full circle, and Javascripters have reinvented what we had 20 years ago.

lexicality 1y ago
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.

deleted 1y ago

[deleted]

tomtomistaken 1y ago

We were experimenting with saving states in URLs with https://libmap.org https://libmap.org. Sharing these URLs on mastodon.social would add the post to the map.

ac130kz 1y ago

>URLs up to ~2000 characters Exactly, this approach doesn't scale well without trickery involved. You have to have some sort of weird encoding in place to compact it down.

rbinv 1y ago
Yup, ASP's "__VIEWSTATE" hidden form parameter comes to mind. It was base64-encoded and POSTed because it could get loooong (hundreds of KB). Terrible for browser navigation/refresh though, because pretty much everything was a form POST. Thus no URL state sharing, either.
- bux93 1y ago
  Also a terrible idea to execute code from the client, even if it's supposedly signed. https://darkatlas.io/blog/critical-sharepoint-vulnerability-cve-2025-53770-remote-code-execution-via-viewstate-abuse https://darkatlas.io/blog/critical-sharepoint-vulnerability-...

gloosx 1y ago

It's just how web works – storing data in URL params to restore the same state later. With React or whatever library you do the exactly same thing. In this case HTMX doesn't particularly stand out or enable anything new here.

runeks 1y ago
> With React or whatever library you do the exactly same thing. There are many React SPAs where the address bar URL rarely changes, and I have to find some "share" button on the page itself to get the page's URL.
- gloosx 1y ago
  This is a generalization from personal exposure, availability bias. It just points out that some people implement things poorly — ignoring that many well-designed SPAs do use URL state effectively. React itself does not prevent or discourage URL-based state, it's just the developer's choice whether to use routing or no.

hamdouni 1y ago

Funny to see query parameters used as intended ... few decades ago

jarofgreen 1y ago

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

Chiron1991 1y ago
That's why you can give guidance to crawlers using sitemaps.
- Quarrel 1y ago
  Which, just like robots.txt, worked decently well until the AI bot crawlers overwhelmed all else.
lcnPylGDnU4H9OF 1y ago
> 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.

theanonymousone 1y ago

I'm currently writing a single-file web application in "Java" using JBang, J2Html, and Javalin (+htmx). It's so refreshing!

user____name 1y ago

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

0x445442 1y ago
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.

gortok 1y ago

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.

packetlost 1y ago
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.

teddyh 1y ago

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/ http://example.com/(tables,images)/developers/

robertoandred 1y ago

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

recursivedoubts 1y ago
depends how much state is accidental vs essential: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ while I certainly try to be funny online, I hope I'm reasonably even handed about the tradeoffs associated with the hypermedia approach: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand

colgandev 1y ago

HTMX has given me so much joy. I love Django and was there near the beginning. For a while I thought I had to switch to something like FastAPI and Vue etc to make relevant web apps and sites, but with Django recently adding async, Django Ninja, and HTMX, I'd reach for Django now for almost anything besides a few specific use cases. So many problems I've run into with newer tools feel like they were already solved years ago if you can SSR. Not that the newer tools don't have their place and they have plenty of good ideas, but it's been fun to see Django stay relevant and for more of the included batteries to be useful again (forms, templates, etc).