How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I agree with what you're saying, of course, simplicity is better, etc.
But the nav on your blog is a terrible example.
Firstly, you don't get to just click on the links to go to where you want to go, you first have to click the three-lines button, even on a desktop with an enormous screen.
And secondly, despite your claims about an "enhanced experience with a modern browser", it seems to work exactly as if there was no enhancement at all? I click the three-lines menu and it takes me to a new page listing the links I can click. The "X" button to "close" the menu navigates me back particularly quickly, but that is all that I can tell that is unusual.
I'm using Firefox 136 on Ubuntu.
And in any event, this is all unnecessary, because you can make a nav by just putting a bunch of links at the top of the page, like HN does.
I have a question: After clicking on a blog in the listing page ("Collective Speed is..."), the page navigated to that particular blog. What CSS transitions are used to convert that title to a header? I saw some animation which pushed that title to become a header. How does that work? I'm curious
I like it. Simple, fast, easy to use. Much better than most of the web these days, although honestly, that's a regrettably low bar. Most of the web these days is horrible and has been for a while.
The joke tracks, but there's a real gap between the original hypertext vision and what we built. Nelson's Xanadu assumed transclusion and two-way links; we got one-way anchors and called it good. The "web of documents" framing obscures how much architectural debt we accepted early on.
The approach to have a separate page for a website's menu and leveraging bfcache and the CSS view transitions API for a smooth experience is not that traditional though, is it?
I'm only used to seeing menus as separate pages in book-like websites and as comprehensive sitemaps. Or, for very small sites, a "homepage" that also acts as a menu, instead of an on-page MPA menu (think a portfolio website, or Space Jam).
Not a fan of the nav, but loved the transitions. Applied them to my website (bespoke C++ static generator + template library): https://vittorioromeo.com/
When I first saw the title, I thought "great! Someone else has (re)discovered hypermedia".
But they have gone in a completely bewildering direction. Rather than swap/morph html fragments in, they're doing full page navigations and using view transitions to make it look smooth.
Worse, they are manipulating the history to cover these blasphemous tracks.
Datastar would make this particularly simple - just include whatever menu/nav stuff that you need and show/hide/toggle it with a few signals/attributes.
The history manipulation bothered me too at first, but after building with this pattern the URLs end up genuinely meaningful - each state is bookmarkable and shareable. With htmx fragment swapping you often get URL state that diverges from what the user sees. The view transitions are basically free once you're doing full navigations anyway.
No, they're not related. The submission's article is about CSS view transitions. HATEOAS seems to involve interacting with an API, but linking between pages on a blog does not require this.
I dunno, it wants to challenge our dependence on javascript and then to make it work it needs to inject a “back” behavior into a normal link?
Js and fallbacks for menus is a solved issue.
this is just another form of LLM dunning krueger derangement where you think the LLM-suggested solution is novel because you haven’t encountered it before, or because you fundamentally don’t understand the underlying problems that we have already solved.
Yeah, I don't think the menu should've been a separate page. It can be made JavaScript-less as a dialog opened by the popover HTML attributes,[0] and the escape key would be able to close it.
I guess it doesn't have to use JavaScript for the back behavior. It could use a server-side rendered referrer if that hasn't been stripped by the browser?
You say that JavaScript and fallbacks for menus is a solved issue but the number of menus that are just an absolute clusterfuck is ridiculous on the web today. They're really not a solved issue, Progressive enhancement is hard to do. Genuinely hard in some cases.
On balance, while this is not without flaws, it's interesting. Accessibility, deep linking, reduction in cognitive load for the developer. There's some merit here.
We did this with our internal tools last year. The trick that made it feel polished was the View Transitions API -- just a meta tag in each page head and navigations feel smooth. No SPA overhead, no hydration bugs. When it clicks, it really clicks.
Lots of important points already posted, from reliability over accessibility to SEO. To add a personal reason: speed. I hate slow computer things. If I open a page I e.g. don't have to use for work or similar (like Google Ads or Linkedin or similar horror shows), and loading the page takes longer than a second, I just bounce.
I built and maintain a static site for a company, and it's just wonderful. It opens instantly (which the search engines like), rebuilding and deploying is trivial, I am not forced to update every week because the JS framework has a new vuln.(There are a few dynamic, JS-based parts that load dynamically and fail gracefully.)
None of this refutes my post whatsoever. The amount of JavaScript to open a hamburger menu is literally around 500 bytes. It can easily gracefully degrade just like your last sentence said. You're going to load much, much more than that by following TFA. It loads an entire new HTML page! This argument just doesn't work here.
i'd say it really depends on the website you're building and what you define as "using javascript"
are you comparing fully client rendering vs SSR without client JS at all? are you building a marketing site or a dashboard type tool?
there is subtly to why each decision would be made based on these.
i think HN tends to demonize JS because we're all well aware of how bad the state of a lot of web apps have become with developers only knowing react and having no background in web fundamentals or accessibility.
i see no reason to completely shun JS, just use it intentionally and not reflexively.
Minor pedantic note: IIRC "client rendering" is usually called "client-side rendering" or CSR in the literature, not "fully client rendering." Small thing. But yeah, the nuance about what kind of site you're building is the crux of it — the distinction gets blurry fast.
Thank you so much for having one of the few measured takes in this thread. I'm not advocating for throwing React and NPM at every problem, but a little bit of hand-written JS is rarely an issue.
It's not "easier" using Javascript; raw Javascript websites are a nightmare to build, maintain and reason about. It is "easier" with Javascript + current-favourite-framework-of-the-day.
Also: accessibility, SEO, the all-new Generative Engine Optimization (GEO) thing, etc.
But the nav on your blog is a terrible example.
Firstly, you don't get to just click on the links to go to where you want to go, you first have to click the three-lines button, even on a desktop with an enormous screen.
And secondly, despite your claims about an "enhanced experience with a modern browser", it seems to work exactly as if there was no enhancement at all? I click the three-lines menu and it takes me to a new page listing the links I can click. The "X" button to "close" the menu navigates me back particularly quickly, but that is all that I can tell that is unusual.
I'm using Firefox 136 on Ubuntu.
And in any event, this is all unnecessary, because you can make a nav by just putting a bunch of links at the top of the page, like HN does.