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).
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).
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.
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’.
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?
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.
Someone said he is being downvoted for suggesting cursor-based pagination, yet one of your suggestions was the cursor-based approach, and as thus, I do not understand why he is being down-voted if it is a legitimate approach, which I believe it is.
I guess we would have to hear nebezb's solutions.
If you are already sorting by price and you bookmark at the second page (which now would be in the 3rd), what would you do? I personally do not care about the item in a sorted list enough to expect a bookmarked URL to start from there, or I cannot remember when I did and why. Any ideas why would one want this? If I bookmark second page, I know that the items on page 2 may not always be on page 2. Why would anyone expect different? If you want to bookmark an item, just go to the product itself and bookmark that. I do not think I ever bookmarked a specific page expecting that to never change.
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.
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.
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.
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.
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 does closing a modal mean? What does a sidebar mean? How about closing it? Pretty soon, you're in half-an-SPA already.
And since you don't want a 2000 character URL, you're either storing half of the session on the server or having to build an abstraction with local storage. And since our frameworks didn't evolve to handle that, what is the purpose?
The key insight into the SPA is that you are writing a coherent client experience. No SSR framework figured out how to do this because they thought about pages rather than experiences.
Let me be clear: I am speaking about web applications. If you're providing information and only have a small number of customer interactions, an SSR is superior. CNN should not be an SPA.
All of the SSR webapps I've built had these solved at a framework level. Dot net and PHP.
Like, the back button: there is no logic because this isn't react. It's just the browser back button. You don't have to do anything if you're using SSR. Back button problems only apply to SPAs or hybrids.
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.
The original idea behind an SPA was to enable API-only backends (with static file service). I still think that's a very worthy use case.
Why not decouple the backend from the concerns of particular views? It makes for a more complex frontend, but it also allows multiple, highly differentiated frontend apps to be build on top of a single set of backend APIs. Esri's ArcGIS Online powers a lot of specialized frontend-only web apps. I used to be on their Business Analyst team (that's a web app) - and I have to say I really like the pattern of building apps this way.
That's not a use case, that's an implementation. What is the end user actually getting with this architecture that can't be obtained by the server-side one? Offline functionality is the only differentiating feature.
A use case for an architecture pattern is a way it could be used to implement something. The concept of a "use case" doesn't just apply to end-users of a software product.
> What is the end user actually getting
More things implemented in the products with less development time.
I'm not sure what you're trying to argue. SSR sites and apps still have scripting and client-side interactivity, the only difference is where the rendering is happening. That's what SSR stands for. SSR switches from APIs exchanging JSON with heavy client-side rendering, to REST endpoints returning hypertext which eliminates the majority of client-side rendering.
How would you implement Google Maps as a SSR app? -- same question for ArcGIS, Figma, an arcade game, or a Zoom clone. It's a serious question -- do you think that would be possible for any of those?
I contend that to build a coherent, usable web app of any of those types, there has to be a lot of client-side scripting. Hence, a SPA is the best architectural pattern.
Sure, you could use SSR for the layout of the page... but in that case, why not skip HTML rendering altogether by shipping raw HTML/CSS for the app's layout? Then you'd only need JS to power the contents of <div>s where the app's functionality is located.
> How would you implement Google Maps as a SSR app? -- same question for ArcGIS, Figma, an arcade game, or a Zoom clone. It's a serious question -- do you think that would be possible for any of those?
> I contend that to build a coherent, usable web app of any of those types, there has to be a lot of client-side scripting. Hence, a SPA is the best architectural pattern.
"Lot's of scripting" does not automatically entail "SPA".
That's a very impressive demo of Datastar, and I like his minimalist approach to frontend architecture.
However, the display logic is implemented as a web component containing (a) a lot of tags written as a big HTML file for streaming state from the backend, and (b) a canvas element rendered by a WASM component. If that fits your definition of SSR for frontend apps, no problem and I think it's great. But that's not what I would have defined as SSR.
Some hurdles I imagine Datastar will need to overcome before this pattern can see widespread adoption:
- there doesn't seem to be a straightforward way to statically bind the frontend markup to the backend, so scaling this to multi-team apps will be a challenge.
- the markup and associated binding feels very similar to template-driven SPA frameworks (data- attributes for everything, really? That's fine in the resulting DOM tree but it's got to be a pain to author and maintain for large apps). Perhaps if someone could build a JSX-like code-to-markup DSL, that problem could be ameliorated.
- he is demoing it from his local machine, so we don't get to see (a) how much server-side compute is required at any scale (even >10 users), (b) how strongly latency can affect rendering, and (c) overall bandwidth requirements.
That being said, I know video game companies have streaming games deployed, so in theory this approach has merit (though I suspect only users who lack beefy home computers and have great internet connections opt for it).
Overall, this feels like less of an indictment of the SPA pattern in general* and more of a "let's see what happens if we change what we assume the constraints are."
*Yes, he's right that a lot of modern SPA development tooling is terrible. Dojo from the 2000s is still arguably easier to develop in than most modern SPA frontend stacks, especially since it can be run with only a static file server, no build required.
I'm not indicting anything, I'm simply pointing out that there are a lot of assumptions that SPAs are the only or best way to have a great user experience, that server interactions are slow, that DOM updates are slow, and that API-based SPAs are the only way to solve all of these issues. The Datastar demo disproves all of these, regardless of how you feel about Datastar's specific approach to it.
Which leads me back to my original point that the only feature an SSR can't intrinsically provide is offline functionality.
> 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.
My contention is that this may not be the traditional client side app, but you are still placing these on a single page. Just because you are replacing the HTML on the page doesn't mean it is a multi-page app. It's an interesting SPA/MPA hybrid but just because you are not writing javascript doesn't mean that the infrastructure isn't using javascript to handle the plumbing.
So, let's use this as an example. Let's say you bring out a side drawer to edit the details of one row on the table. The side drawer pops up. The user edits details and clicks submit. (To answer this question, the user scrolls to other parts of the table to look at other rows.) There is an error in the user's input based on business logic. The user corrects it, and the row is changed. The side drawer goes away.
How many times is the whole page loaded from scratch? In a traditional SPA, the page is loaded once. With a strict MPA, the page is loaded from scratch four times. With Laravel + Livewire, to my understanding, the page is loaded once and divs are replaced with HTML from the server.
Even if it is not a react app, it is still a collection of single page apps with server side intermediations using html.
> The key insight into the SPA is that you are writing a coherent client experience.
This is the best way to put it I've yet seen. HN articles keep saying things like "now that navigation transitions are solved in CSS, there's no use case left for SPAs". Is everyone just writing apps for widespread content consumption or something?
> CNN should not be an SPA.
Yes, and we need canonical "that should be an SPA"-type apps to bring up in these discussions--which can be hard, since all the best SPAs are for getting work done, not publishing content for the public to consume. Thus, as a class they tend to be department-procured B2B apps and not as generally recognizable. I propose GMail and Google Docs/Sheets/Slides for starters.
> 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?
> 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
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.
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.
Have you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings:
There are a lot of ways to manage this problem. My preferred path is to wrap interpolated fields with HttpUtility.UrlEncode() when I know a user can touch it and there are plausible reasons for allowing 'illegal' characters at form submit time.
In terms of performance, it is definitely faster. The amount of time it takes to render these partials is negligible. You'd have to switch up your tooling to measure things in microseconds instead of milliseconds if you wanted any meaningful signal.
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 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.
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.
HTML templating isn't just string interpolation, Its a whole templating engine. It's not like JSX, which is fake templating. Server side frameworks have real templating.
Plus, you have to convert data to HTML somewhere. If you're using react you do this typically on the front end. You traverse and read JSON and convert it to HTML... Just like you would in PHP. Just, on the front end.
> You traverse and read JSON and convert it to HTML
It gets converted to DOM nodes, and there is zero HTML source involved when using a component toolkit. Whereas in PHP, you can do things like this and it won't make a peep:
Other template engines like twig or blade will at least escape it by default, but of course have a syntax for interpolating it raw, otherwise they wouldn't be very useful as template engines. That's the sort of templating I'm talking about. JSX is a tree builder syntax that doesn't even produce strings at all on the client side, and when rendered in SSR, produces HTML source that's correct by construction (syntactically anyway). You can call that "fake templating", I'd say it's not templating at all.
Obviously there are other server-side template engines out there that are also correct in this fashion (HAML comes to mind), but I'm not referring to those, and neither is most of the "server-side is all you ever need" crowd.
I haven't seen a project that uses PHP for templating in many, many years. PHP backends use a templating engine, not PHP. They also feature components.
Its the same level of abstraction as JSX but you also get type checking.
I would love to see more server template engines on the abstraction level of JSX/TSX or better, but I can assure you that neither Blade nor Twig are among them. And I actually like Twig (yes, I still occasionally do templating).
That's just bad coding no matter the framework. Too many devs pull too many packages in....Saving themselves minutes at the expense of all the users waiting longer. So much compute and co2 is wasted on it.
Major differences that I can think of between the two are (with regarding to warts and ease of use):
PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on.
PHP 8 has strong support for static typing now, thank goodness.
PHP 8 introduces union types (int|float|null).
PHP 8.1 introduces intersection types (A&B).
PHP 8.1 added the "never" return type.
PHP 8 has less repetitive boilerplate.
PHP 8 has consistent function signatures now.
PHP 8 has consistent object/array syntax now (to be honest, some asymmetries remain).
PHP 8 has named arguments for clarity and flexibility.
PHP 8 has the nullsafe operator which simplifies deeply nested null checks.
PHP 8 has arrow functions which makes closures concise and easier to use.
PHP 8 has attributes, e.g. "#[Route("/users")]".
PHP 8 has "match" expressions which is a more predictable, type-safe, and expression-oriented alternative to "switch".
PHP 8 has many more tools for testing and debugging (incl. static analyzers).
PHP 8 has many new functions (incl. utility functions).
PHP 8.1 introduces native enums.
PHP 8.1 has "readonly" properties for enforcing immutability.
PHP 8.1 has cleaner syntax for referencing callables.
PHP 8.1 has "fibers" which enables cooperative multitasking and is a foundational building block for upcoming async/await features.
Global namespace pollution has been pretty much resolved (Composer autoloading[1]).
There are other ecosystem-level improvements such as PSR standards[1], better async story, etc.
This list is non-exhaustive. These are just the improvements that come to mind off the top of my head so I probably missed a lot of other major improvements. PHP 8+ is definitely much easier to use and they greatly reduced PHP's warts. There may be some inconsistencies left here and there, but they are not a deal-breaker IMO, if you even run into them.
I strongly recommend taking a fresh look at PHP 8+. It is very different from the PHP you have once known. It is "modern" now. There are lots of deprecations and removal of old warts. I did not like PHP as much ages ago, but it was a pleasure to use PHP 8+.
If you are looking to (re)learn PHP, the book “PHP & MySQL: Novice to Ninja” is a good starting point[1]. There are many other, high-quality books and resources as well.
If you have any specific warts or whatnot, or if you want more resources, please do feel free to let me know.
---
I wrote this comment on my phone, so it is not as detailed and it is not structured as well, but I hope that it will still provide some insight into the differences between legacy PHP and modern PHP.
I missed an important difference (because I did not consider it to be relevant to "warts"[1] and "ease of use"), which is that modern PHP has Just-in-Time (JIT) compilation now, not an interpreted runtime, which offers significant performance improvements!
[1] On second thought, poor performance could be considered a wart.
I’ve been building web apps since the ’90s, and I never understood the appeal of PHP. It was always a terrible language, and there were usually better alternatives available.
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].
It has been wild to realize I've now seen one full technology cycle of thin client to thick client to thin client again. Maybe PHP this time around will be able to be more robust with the lessons learned.
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.
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.
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.
> 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?
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?
> 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.
> why do you think that this must happen on the front-end?
It must happen on both frontend and backend, because it's about their communication with each other. So that includes frontend.
> a) serve an error page, leaving that to the backend (at some point the backend must validate anyway)
> b) serve the regular front-end and react to the invalid state with error messages. there are libraries like zod that should make your job easier.
I mean, that is exactly what makes me so frustrated! Sorry, you are just giving a good example of what I'm complaining about. Both of those solutions are sub-optimal.
Here is how I'd implement that by hand if I would write something like nextjs/django:
1.) The frontend always sends a version in each of it's request (in the payload, the header, wherever)
2.) The backend compares that version against what it is expecting and compatible with. If it detects an outdated/incompatible version then there are two options: it is somehow possible to automatically fix it. For example because the used protocol has some mechanism and the developer uses that (such as default values for missing values) or because the developer has manually provided a migration for old versions.
3.) If it can be fixed, all good. If not, the backend sends a message back, saying that the request cannot be processed because the version is too old. The user can then decide to e.g. save their state elsewhere and reload, or just reload. Or do something completely different.
4.) Bonus: while we are at it, why don't have that fronted send regular requests to backend and ask if the version is still up-to-date (especially if it's the type of user that has their browser tab open forever). That would help to prevent data loss or other problems before they even occur, because the user gets an info and can refresh early.
Why should I implement all of that myself over and over again? Are you guys really thinking that this should not be handled, or at least made very easy, by typical weblibs/frontends such as nextss or django?
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.
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.
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
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.
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.
it felt like this was an opportunity for AI craze to adopt on top of the existing standards, instead they all invented their own stuff with llm.txt and MCP *sigh*
> 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.
> 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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
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.
> 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.
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.
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.
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.
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/
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.
You don't need to do anything different to the other URLs on the page, by default all parameters are passed along in every request, so you just need to retrieve any expected url parameters in the server code
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"
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.
I have something similar setup for toast notifications in Django (Python). I have a notifications "partial" defined, which gets returned as part of an out-of-band swap by any view function that desires to use it. This includes other partials as well. It's how I chain fragment replacements together.
As an aside, I love that we can have this conversation - people in entirely different stacks can talk a similar language, through the glue of HTMX. This is why htmx is good for web development
I'll eventually make my repo public on Github, but I'm hesitant because it's still pretty half-baked. In the meantime, I'll do my best to capture the essentials. It's been a minute since I implemented it, so I apologize if I miss some details.
I use the same ViewModel structure for all renders, a struct called Content. It has a members to help with rendering and whatnot, and the data being rendered in my HTML template is stored in a Data type for the content that will be displayed:
Data any
So whether I'm rendering complex data, a form, or just a snippet of text, that's where it lives. That allows for all sorts of patterns for rendering data and re-using templates if that's what you want to do. Or you can just keep things simple.
Hat-tip to the Pagoda framework, which was used sometimes as an inspiration and other times as a guideline for this (and other) patterns that I used. You can find it here: https://github.com/mikestefanello/pagoda
I also have, as part of my ViewModel, a `Notifications` slice that specifies messages to send to the user and their type:
Notifications []messages.Notification
I have a HTML layout for my full page that includes a section that CSS uses to pick up notifications and display them via a toaster message:
<div id="user-notifications" class="toaster-container">
{{ range .Notifications }}
<div class="toaster{{ if .IsSuccess }} success{{ else if .IsError }} error{{ end }}">
{{ .Message }}
</div>
{{ end }}
</div>
I managed to get it working without any need for JavaScript (other than what HTMX needs to work).
My partial renders use a layout that includes a section for the partially rendered code and my oob Notifications:
{{ block "Content" . }}
Loading content.
{{ end }}
<div id="user-notifications" class="toaster-container" hx-swap-oob="true">
{{ range .Notifications }}
<div class="toaster{{ if .IsSuccess }} success{{ else if .IsError }} error{{ end }}">
{{ .Message }}
</div>
{{ end }}
</div>
So the hx-swap-oob results in my user-notifications <div> being replaced with new notifications content, if there is any. I have a base renderer that handles injecting the layouts and injecting data into `Notifications`. As a result, my handlers can be generally oblivious that this is all happening underneath.
This model can work for updating links, updating breadcrumbs, writing messages to the console, or whatever.
I'm still scratching the surface with HTMX, but I'm convinced HTMX is perfectly appropriate and a much simpler alternative for 95% of the web dev being done today.
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?
> 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.
> 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.
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/
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 ...
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.
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).
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).
It doesn't have the problem if a timestamp or similar is used.
Only if you order by that timestamp.
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”. The latter isn’t something you’d bookmark.
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’.
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?
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.
Someone said he is being downvoted for suggesting cursor-based pagination, yet one of your suggestions was the cursor-based approach, and as thus, I do not understand why he is being down-voted if it is a legitimate approach, which I believe it is.
I guess we would have to hear nebezb's solutions.
If you are already sorting by price and you bookmark at the second page (which now would be in the 3rd), what would you do? I personally do not care about the item in a sorted list enough to expect a bookmarked URL to start from there, or I cannot remember when I did and why. Any ideas why would one want this? If I bookmark second page, I know that the items on page 2 may not always be on page 2. Why would anyone expect different? If you want to bookmark an item, just go to the product itself and bookmark that. I do not think I ever bookmarked a specific page expecting that to never change.
+1000.
There are always trade-offs for architectural decisions.
Not if the items change relative position over time.
archive.org
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.
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".
> 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.
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.
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.
Indeed, thats weird.
He probably wants to freeze the state of the page. Maybe he should consider saving it via ctrl s
Datomic + put the database version in the URL :)
also significantly better for performance
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 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.
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 does closing a modal mean? What does a sidebar mean? How about closing it? Pretty soon, you're in half-an-SPA already.
And since you don't want a 2000 character URL, you're either storing half of the session on the server or having to build an abstraction with local storage. And since our frameworks didn't evolve to handle that, what is the purpose?
The key insight into the SPA is that you are writing a coherent client experience. No SSR framework figured out how to do this because they thought about pages rather than experiences.
Let me be clear: I am speaking about web applications. If you're providing information and only have a small number of customer interactions, an SSR is superior. CNN should not be an SPA.
All of the SSR webapps I've built had these solved at a framework level. Dot net and PHP.
Like, the back button: there is no logic because this isn't react. It's just the browser back button. You don't have to do anything if you're using SSR. Back button problems only apply to SPAs or hybrids.
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.
> The only real use case
The original idea behind an SPA was to enable API-only backends (with static file service). I still think that's a very worthy use case.
Why not decouple the backend from the concerns of particular views? It makes for a more complex frontend, but it also allows multiple, highly differentiated frontend apps to be build on top of a single set of backend APIs. Esri's ArcGIS Online powers a lot of specialized frontend-only web apps. I used to be on their Business Analyst team (that's a web app) - and I have to say I really like the pattern of building apps this way.
That's not a use case, that's an implementation. What is the end user actually getting with this architecture that can't be obtained by the server-side one? Offline functionality is the only differentiating feature.
A use case for an architecture pattern is a way it could be used to implement something. The concept of a "use case" doesn't just apply to end-users of a software product.
> What is the end user actually getting
More things implemented in the products with less development time.
For ArcGIS? Have you ever used that?
A similar system would be Figma - how do you build a server side Figma?
I'm not sure what you're trying to argue. SSR sites and apps still have scripting and client-side interactivity, the only difference is where the rendering is happening. That's what SSR stands for. SSR switches from APIs exchanging JSON with heavy client-side rendering, to REST endpoints returning hypertext which eliminates the majority of client-side rendering.
How would you implement Google Maps as a SSR app? -- same question for ArcGIS, Figma, an arcade game, or a Zoom clone. It's a serious question -- do you think that would be possible for any of those?
I contend that to build a coherent, usable web app of any of those types, there has to be a lot of client-side scripting. Hence, a SPA is the best architectural pattern.
Sure, you could use SSR for the layout of the page... but in that case, why not skip HTML rendering altogether by shipping raw HTML/CSS for the app's layout? Then you'd only need JS to power the contents of <div>s where the app's functionality is located.
> you think that would be possible for any of those?
You think the web didn't have interactive maps or maps with directions before SPAs?
> How would you implement Google Maps as a SSR app? -- same question for ArcGIS, Figma, an arcade game, or a Zoom clone. It's a serious question -- do you think that would be possible for any of those?
Yes: https://www.youtube.com/watch?v=0K71AyAF6E4#t=21m21s
> I contend that to build a coherent, usable web app of any of those types, there has to be a lot of client-side scripting. Hence, a SPA is the best architectural pattern.
"Lot's of scripting" does not automatically entail "SPA".
That's a very impressive demo of Datastar, and I like his minimalist approach to frontend architecture.
However, the display logic is implemented as a web component containing (a) a lot of tags written as a big HTML file for streaming state from the backend, and (b) a canvas element rendered by a WASM component. If that fits your definition of SSR for frontend apps, no problem and I think it's great. But that's not what I would have defined as SSR.
Some hurdles I imagine Datastar will need to overcome before this pattern can see widespread adoption:
- there doesn't seem to be a straightforward way to statically bind the frontend markup to the backend, so scaling this to multi-team apps will be a challenge.
- the markup and associated binding feels very similar to template-driven SPA frameworks (data- attributes for everything, really? That's fine in the resulting DOM tree but it's got to be a pain to author and maintain for large apps). Perhaps if someone could build a JSX-like code-to-markup DSL, that problem could be ameliorated.
- he is demoing it from his local machine, so we don't get to see (a) how much server-side compute is required at any scale (even >10 users), (b) how strongly latency can affect rendering, and (c) overall bandwidth requirements.
That being said, I know video game companies have streaming games deployed, so in theory this approach has merit (though I suspect only users who lack beefy home computers and have great internet connections opt for it).
Overall, this feels like less of an indictment of the SPA pattern in general* and more of a "let's see what happens if we change what we assume the constraints are."
*Yes, he's right that a lot of modern SPA development tooling is terrible. Dojo from the 2000s is still arguably easier to develop in than most modern SPA frontend stacks, especially since it can be run with only a static file server, no build required.
I'm not indicting anything, I'm simply pointing out that there are a lot of assumptions that SPAs are the only or best way to have a great user experience, that server interactions are slow, that DOM updates are slow, and that API-based SPAs are the only way to solve all of these issues. The Datastar demo disproves all of these, regardless of how you feel about Datastar's specific approach to it.
Which leads me back to my original point that the only feature an SSR can't intrinsically provide is offline functionality.
> 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.
My contention is that this may not be the traditional client side app, but you are still placing these on a single page. Just because you are replacing the HTML on the page doesn't mean it is a multi-page app. It's an interesting SPA/MPA hybrid but just because you are not writing javascript doesn't mean that the infrastructure isn't using javascript to handle the plumbing.
So, let's use this as an example. Let's say you bring out a side drawer to edit the details of one row on the table. The side drawer pops up. The user edits details and clicks submit. (To answer this question, the user scrolls to other parts of the table to look at other rows.) There is an error in the user's input based on business logic. The user corrects it, and the row is changed. The side drawer goes away.
How many times is the whole page loaded from scratch? In a traditional SPA, the page is loaded once. With a strict MPA, the page is loaded from scratch four times. With Laravel + Livewire, to my understanding, the page is loaded once and divs are replaced with HTML from the server.
Even if it is not a react app, it is still a collection of single page apps with server side intermediations using html.
> The key insight into the SPA is that you are writing a coherent client experience.
This is the best way to put it I've yet seen. HN articles keep saying things like "now that navigation transitions are solved in CSS, there's no use case left for SPAs". Is everyone just writing apps for widespread content consumption or something?
> CNN should not be an SPA.
Yes, and we need canonical "that should be an SPA"-type apps to bring up in these discussions--which can be hard, since all the best SPAs are for getting work done, not publishing content for the public to consume. Thus, as a class they tend to be department-procured B2B apps and not as generally recognizable. I propose GMail and Google Docs/Sheets/Slides for starters.
I think the easy answer is "could you see this system being rewritten in QT or Visual Basic 6?"
If this would have been a desktop app in the 90s, it's within this scope.
> 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?
> 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
Complexity merchant... I like that.
https://chrlschn.dev/blog/2025/05/beware-the-complexity-merc...
> 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.
What about a feature like query completion?
The query completion can also be SSR. The example below is HTMX for Active Search, but the principle is the same:
https://htmx.org/examples/active-search/
I suppose that is a rather neat way to do it.
SSR doesn't mean "no JavaScript." See "progressive enhancement."
html native datalist?
The behaviour of an HTML datalist is basically completely different in every browser. It is a highly flawed element.
there probably is a jQuery plugin for that /s
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.
Have you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings:
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 .NET web apps for the last ~3 years. @+$ = PHP in C# as far as I'm concerned.
Some dangers with injection attacks if you don't santitize inputs correctly, but this is probably faster than most templating languages like razor.
There are a lot of ways to manage this problem. My preferred path is to wrap interpolated fields with HttpUtility.UrlEncode() when I know a user can touch it and there are plausible reasons for allowing 'illegal' characters at form submit time.
In terms of performance, it is definitely faster. The amount of time it takes to render these partials is negligible. You'd have to switch up your tooling to measure things in microseconds instead of milliseconds if you wanted any meaningful signal.
The only thing that would be comparable might be something like RazorSlices.
It's super easy to add sanitization middleware in .NET.
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 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.
This is truly beautiful. Art, even.
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.
HTML templating isn't just string interpolation, Its a whole templating engine. It's not like JSX, which is fake templating. Server side frameworks have real templating.
Plus, you have to convert data to HTML somewhere. If you're using react you do this typically on the front end. You traverse and read JSON and convert it to HTML... Just like you would in PHP. Just, on the front end.
> You traverse and read JSON and convert it to HTML
It gets converted to DOM nodes, and there is zero HTML source involved when using a component toolkit. Whereas in PHP, you can do things like this and it won't make a peep:
Other template engines like twig or blade will at least escape it by default, but of course have a syntax for interpolating it raw, otherwise they wouldn't be very useful as template engines. That's the sort of templating I'm talking about. JSX is a tree builder syntax that doesn't even produce strings at all on the client side, and when rendered in SSR, produces HTML source that's correct by construction (syntactically anyway). You can call that "fake templating", I'd say it's not templating at all.Obviously there are other server-side template engines out there that are also correct in this fashion (HAML comes to mind), but I'm not referring to those, and neither is most of the "server-side is all you ever need" crowd.
I haven't seen a project that uses PHP for templating in many, many years. PHP backends use a templating engine, not PHP. They also feature components.
Its the same level of abstraction as JSX but you also get type checking.
I would love to see more server template engines on the abstraction level of JSX/TSX or better, but I can assure you that neither Blade nor Twig are among them. And I actually like Twig (yes, I still occasionally do templating).
I'd prefer not to download 2MB of JavaScript and feel my phone get uncomfortably hot just to fill out your online form.
That's just bad coding no matter the framework. Too many devs pull too many packages in....Saving themselves minutes at the expense of all the users waiting longer. So much compute and co2 is wasted on it.
Like a super rich and very well tested front end client, that doesn't need a server to template everything for it?
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!
Glad I skipped the whole "JavaScript only" webdev phase. My mad PostNuke skills are relevant again.
I'm voting for Cold Fusion on top of Golang.
Too advanced typesystem for Go folks, better keep it on top of Java. /s
Indeed, the Platformatic folks announced just that last week:
https://blog.platformatic.dev/laravel-nodejs-php-in-watt-run...
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.
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.
Unless they have abandoned backwards compatibility then I don't think that is what I meant.
Major differences that I can think of between the two are (with regarding to warts and ease of use):
PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on.
PHP 8 has strong support for static typing now, thank goodness.
PHP 8 introduces union types (int|float|null).
PHP 8.1 introduces intersection types (A&B).
PHP 8.1 added the "never" return type.
PHP 8 has less repetitive boilerplate.
PHP 8 has consistent function signatures now.
PHP 8 has consistent object/array syntax now (to be honest, some asymmetries remain).
PHP 8 has named arguments for clarity and flexibility.
PHP 8 has the nullsafe operator which simplifies deeply nested null checks.
PHP 8 has arrow functions which makes closures concise and easier to use.
PHP 8 has attributes, e.g. "#[Route("/users")]".
PHP 8 has "match" expressions which is a more predictable, type-safe, and expression-oriented alternative to "switch".
PHP 8 has many more tools for testing and debugging (incl. static analyzers).
PHP 8 has many new functions (incl. utility functions).
PHP 8.1 introduces native enums.
PHP 8.1 has "readonly" properties for enforcing immutability.
PHP 8.1 has cleaner syntax for referencing callables.
PHP 8.1 has "fibers" which enables cooperative multitasking and is a foundational building block for upcoming async/await features.
Global namespace pollution has been pretty much resolved (Composer autoloading[1]).
There are other ecosystem-level improvements such as PSR standards[1], better async story, etc.
This list is non-exhaustive. These are just the improvements that come to mind off the top of my head so I probably missed a lot of other major improvements. PHP 8+ is definitely much easier to use and they greatly reduced PHP's warts. There may be some inconsistencies left here and there, but they are not a deal-breaker IMO, if you even run into them.
[1] https://www.phptutorial.net/php-oop/php-composer-autoload/ (I do not use "dump-autoload"), https://github.com/php-fig/fig-standards/blob/master/accepte..., https://www.php-fig.org/psr/psr-4/ (https://www.php-fig.org/psr/)
---
I strongly recommend taking a fresh look at PHP 8+. It is very different from the PHP you have once known. It is "modern" now. There are lots of deprecations and removal of old warts. I did not like PHP as much ages ago, but it was a pleasure to use PHP 8+.
If you are looking to (re)learn PHP, the book “PHP & MySQL: Novice to Ninja” is a good starting point[1]. There are many other, high-quality books and resources as well.
[1] Available on libgen. The source code examples from the book are available on GitHub: https://github.com/spbooks/phpmysql7.
---
If you have any specific warts or whatnot, or if you want more resources, please do feel free to let me know.
---
I wrote this comment on my phone, so it is not as detailed and it is not structured as well, but I hope that it will still provide some insight into the differences between legacy PHP and modern PHP.
Happy to answer any questions!
Wow very in depth comment. Maybe I'll spin up a dev container and play around with php
I missed an important difference (because I did not consider it to be relevant to "warts"[1] and "ease of use"), which is that modern PHP has Just-in-Time (JIT) compilation now, not an interpreted runtime, which offers significant performance improvements!
[1] On second thought, poor performance could be considered a wart.
That’s called Python or Ruby.
I’ve been building web apps since the ’90s, and I never understood the appeal of PHP. It was always a terrible language, and there were usually better alternatives available.
It’s about time. We already reinvented Lotus Notes.
Lotus Notes was great until they added email.
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
It has been wild to realize I've now seen one full technology cycle of thin client to thick client to thin client again. Maybe PHP this time around will be able to be more robust with the lessons learned.
program like it's 1999
It’s called nextjs
I think they go with a PHP implementation on WASM so it runs on the client
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...
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
[1] https://saewitz.com/server-components-give-you-optionality
[2] https://saewitz.com/the-mental-model-of-server-components
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.
I prefer how Angular handles it. It's just HTML with bindings to an object
> 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?
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?
> 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.
why do you think that this must happen on the front-end? you can make a breaking change and when the user submits an invalid state
a) serve an error page, leaving that to the backend (at some point the backend must validate anyway)
b) serve the regular front-end and react to the invalid state with error messages. there are libraries like zod that should make your job easier.
> why do you think that this must happen on the front-end?
It must happen on both frontend and backend, because it's about their communication with each other. So that includes frontend.
> a) serve an error page, leaving that to the backend (at some point the backend must validate anyway)
> b) serve the regular front-end and react to the invalid state with error messages. there are libraries like zod that should make your job easier.
I mean, that is exactly what makes me so frustrated! Sorry, you are just giving a good example of what I'm complaining about. Both of those solutions are sub-optimal.
Here is how I'd implement that by hand if I would write something like nextjs/django:
1.) The frontend always sends a version in each of it's request (in the payload, the header, wherever)
2.) The backend compares that version against what it is expecting and compatible with. If it detects an outdated/incompatible version then there are two options: it is somehow possible to automatically fix it. For example because the used protocol has some mechanism and the developer uses that (such as default values for missing values) or because the developer has manually provided a migration for old versions.
3.) If it can be fixed, all good. If not, the backend sends a message back, saying that the request cannot be processed because the version is too old. The user can then decide to e.g. save their state elsewhere and reload, or just reload. Or do something completely different.
4.) Bonus: while we are at it, why don't have that fronted send regular requests to backend and ask if the version is still up-to-date (especially if it's the type of user that has their browser tab open forever). That would help to prevent data loss or other problems before they even occur, because the user gets an info and can refresh early.
Why should I implement all of that myself over and over again? Are you guys really thinking that this should not be handled, or at least made very easy, by typical weblibs/frontends such as nextss or django?
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.
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.
Next you'll tell me the URL can contain information which can be used to auto-scroll you to a specific heading.
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.
Sorcery!
This is a classic pattern of web applications from the 1990s. Works amazingly well even w/o HTMX
One of the legitimate grievances of SPAs is that they made this pattern less obvious.
More like we have a whole generation educated in bootcamps that think they need SPAs for doing anything.
I find the whole thing where you configure your web server to serve the same thing from
and 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 and it loads an SPA which in turn fetches a well-structured JSON documents like 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.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.
it felt like this was an opportunity for AI craze to adopt on top of the existing standards, instead they all invented their own stuff with llm.txt and MCP *sigh*
Coming up next: moving JS outside of markup with selectors.
> 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.
> 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.
The example they used for "in progress" state was form inputs. Don't you count those as in-page state?
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.
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.
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.
It’s still unfortunately contentious in many development circles :/
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).
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.
I find it deeply ironic that we have come full circle, and Javascripters have reinvented what we had 20 years 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.
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://github.com/alpinejs/alpine
There is Alpine Ajax, their HTMX counterpart.
https://alpine-ajax.js.org/
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
Makes sense, HTMX and Datastar both have a common philosophical ancestor in HATEOAS
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.
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.
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?
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
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
1 - https://htmx.org/docs/#extensions
>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.
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.
Also a terrible idea to execute code from the client, even if it's supposedly signed.
https://darkatlas.io/blog/critical-sharepoint-vulnerability-...
> 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.
That's why you can give guidance to crawlers using sitemaps.
Which, just like robots.txt, worked decently well until the AI bot crawlers overwhelmed all else.
Funny to see query parameters used as intended ... few decades ago
Finally we are getting out of Hipster tech territory and back to something that makes sense. Thank you HTMX.
Putting JavaScript directly in your markup with bespoke attributes is extremely hipster.
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.
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.
> 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.
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.
My HTMX side project uses Rison to store nested objects without unreadable encoding or handmade parsing.
https://github.com/Nanonid/rison
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/
I'm currently writing a single-file web application in "Java" using JBang, J2Html, and Javalin (+htmx).
It's so refreshing!
> 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.
depends how much state is accidental vs essential:
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/#on-the-other-hand
Please do! Dropping deep links with state is very useful.
It cant be used for everything. E.g. not dark mode!
We were experimenting with saving states in URLs with https://libmap.org. Sharing these URLs on mastodon.social would add the post to the map.
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-...
You don't need to do anything different to the other URLs on the page, by default all parameters are passed along in every request, so you just need to retrieve any expected url parameters in the server code
https://htmx.org/attributes/hx-params/
Isn’t that what hx-swap-oob is for?
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"
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.
I have something similar setup for toast notifications in Django (Python). I have a notifications "partial" defined, which gets returned as part of an out-of-band swap by any view function that desires to use it. This includes other partials as well. It's how I chain fragment replacements together.
As an aside, I love that we can have this conversation - people in entirely different stacks can talk a similar language, through the glue of HTMX. This is why htmx is good for web development
Gotcha, I think I looked at hx-swap-oob before for inspiration, but didn't see it working for this case, I'll look again.
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.
I'll eventually make my repo public on Github, but I'm hesitant because it's still pretty half-baked. In the meantime, I'll do my best to capture the essentials. It's been a minute since I implemented it, so I apologize if I miss some details.
I use the same ViewModel structure for all renders, a struct called Content. It has a members to help with rendering and whatnot, and the data being rendered in my HTML template is stored in a Data type for the content that will be displayed:
So whether I'm rendering complex data, a form, or just a snippet of text, that's where it lives. That allows for all sorts of patterns for rendering data and re-using templates if that's what you want to do. Or you can just keep things simple.Hat-tip to the Pagoda framework, which was used sometimes as an inspiration and other times as a guideline for this (and other) patterns that I used. You can find it here: https://github.com/mikestefanello/pagoda
I also have, as part of my ViewModel, a `Notifications` slice that specifies messages to send to the user and their type:
I have a HTML layout for my full page that includes a section that CSS uses to pick up notifications and display them via a toaster message: I managed to get it working without any need for JavaScript (other than what HTMX needs to work).My partial renders use a layout that includes a section for the partially rendered code and my oob Notifications:
So the hx-swap-oob results in my user-notifications <div> being replaced with new notifications content, if there is any. I have a base renderer that handles injecting the layouts and injecting data into `Notifications`. As a result, my handlers can be generally oblivious that this is all happening underneath.This model can work for updating links, updating breadcrumbs, writing messages to the console, or whatever.
I'm still scratching the surface with HTMX, but I'm convinced HTMX is perfectly appropriate and a much simpler alternative for 95% of the web dev being done today.
Another reminder of Programming inside the URL String. https://apenwarr.ca/log/20121218
URL-driven state? Sounds like a "take that" upper cut to the jaw of the RESTful opponent.
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?
> 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.
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.
> 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.
> 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
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%...
Doesn't react-router do something like this?
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/
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 ...
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.
Oh boy, hashbangs are back.
The first one that comes to mind was twitter...
I think LinkedIn won the stuffedURLbufferOverflow Olympics back in the day.
They failed as a company?
Still around doing, eh fine. But they abandoned the url hash params with an id that references params on the backend (a mess!)
When people start using or buying your software you are going to quickly find out that 64K won't work
640K oughta be enough for everyone.