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.
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.
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.
He probably wants to freeze the state of the page. Maybe he should consider saving it via ctrl s
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.
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.
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?
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
"it's too slow" is a thing a lot of customers have mentioned to me over the years.
Have you heard of these things called smartphones? I hear they're getting quite popular.
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.
var reportPartial = @$"
<h1>{report.Name}</h1>
<table>
{string.Join('\n', report.Items.Select(reportItem => @$"
<tr>
<td>{reportItem.Col1}</td>
<td>{reportItem.Col2}</td>
</tr>
"))}
</table>
";
This is how I've been building my .NET web apps for the last ~3 years. @+$ = PHP in C# as far as I'm concerned.
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.
It’s a chance to start all over yet again! Come on- we’re all up for that, we do it every few months!
https://blog.platformatic.dev/laravel-nodejs-php-in-watt-run...
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’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.
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...
Forms are also hard because they involve many different data-types, client-side state, (client?) and server validation, crossing the network boundary, contextual UI, and so on. These are not simple issues, no matter how much the average developer would love them to be. It's time we accept the problem domain as complex.
I will say that React Server Components are a huge step towards giving power back to the URL, while also allowing developers to access the full power of both the client and the server–but the community at large has deemed the mental model too complex. Notably, it enables you to build nuanced forms that work with or without javascript enabled, and handle crossing the boundary rather gracefully. After working with RSCs for several years now, I can't imagine going back. I've written several blog posts about them[1][2] and feel the community should invest more time into understanding their ideas.
I have a post in my drafts about how taking advantage of URL params properly (with or without RSCs) give our UIs object permanence. How we as web developers should be relying on them more and using it to reflect "client-side" state. Not always, but more often. But it's a hard post to finish as communicating and crystalizing these ideas are difficult. One day I'll get it out.
[1] https://saewitz.com/server-components-give-you-optionality
[2] https://saewitz.com/the-mental-model-of-server-components
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.
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?
That's your job. Frankly, anything more would be over kill. Why should my url param manager handle new or removed form fields?
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.
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.
http://example.com/application
http://example.com/application/with/path?and=parameters
http://example.com/item/448828
http://api.example.com/item/448827
http://api.example.com/item/448828
http://api.example.com/item/448829
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 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.
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.
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.
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.
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).
EDIT: Hmm. Is this comment controversial? Obviously some people disagree strongly. Mind sharing why?
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
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.
Terrible for browser navigation/refresh though, because pretty much everything was a form POST. Thus no URL state sharing, either.
https://darkatlas.io/blog/critical-sharepoint-vulnerability-...
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.
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.
It's so refreshing!
It cant be used for everything. E.g. not dark mode!
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.
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:
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-...
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?
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.
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.
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://stackblitz.com/edit/github-8ssor8-rqkyew8w?file=src%...
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 ...
The first one that comes to mind was twitter...