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.
Really awesome new(ish) feature of the web platform. It doesn't yet have full support in Firefox unfortunately, but is supported in Chrome and Safari.
Because if I click on a menu button on a desktop browser, I generally don't expect it to take over the entire page with a menu.
This seems like an example of unhelpfully mobile-centric website design, which has been becoming more prevalent in recent years.
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.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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.
Google Search doesn't work without JavaScript.
Seriously, what's the point? Don't just reflexively downvote me. Try to articulate why this is a good idea. It's not that hard to use your words.
This article is my usual go-to and lists several reasons why JavaScript might not be available, and thus why you shouldn't take it for granted: https://piccalil.li/blog/a-handful-of-reasons-javascript-won...
- the user explicitly disabled JavaScript
- the browser does not support JavaScript (I sometimes view websites using elinks)
AFAIK screen readers also work better without JavaScript, so it's also an accessibility issue.
As I just said, users who explicitly disable JavaScript cannot even use Google Search. Why should I accommodate those users when even Google refuses to do so? They are actively choosing to have a limited web experience. The vast majority of the internet is completely broken for them.
That link is not nearly as convincing as you seem to think it is. I suppose that I will need to refute the points if I want you to stop sharing it, so here we go:
A browser extension has interfered with the site - okay? That can be true of literally anything. An extension can interfere with View Transitions too.
A spotty connection hasn’t loaded the dependencies correctly - Either they load or they don't. How would the dependencies load "incorrectly"? Does this author know how JavaScript works?
Internal IT policy has blocked dependencies - How? Are they bundled? Does this author still think modern websites load things like jQuery from a CDN? What year is it? (WYII from this point on, for the sake of brevity)
WIFI network has blocked certain CDNs - WYII
A user is viewing your site on a train which has just gone into a tunnel - The CSS and HTML won't load either!
A device doesn’t have enough memory available - WYII???
There’s an error in your JavaScript - and, you don't have any tests? You didn't notice when developing the site? Can you not have errors in your CSS? Sure, an error in JS is worse, but that doesn't mean you should never use it.
An async fetch request wasn’t fenced off in a try catch and has failed - This usually wouldn't change anything. fetch failures are rarely actual errors (even a 500 response doesn't result in an exception), and it's async so it wouldn't affect the initial load.
A user has a JavaScript toggle accidentally turned off - The <noscript> tag exists.
A user uses a JavaScript toggle to prevent ads loading - <noscript>
An ad blocker has blocked your JavaScript from loading - Modern ad blockers are URL based. How are they loading literally anything else from my domain?
A user is using Opera Mini - No, they aren't.
A user has data saving turned on - Okay... And!??!?!
Rogue, interfering scripts have been added by Google Tag manager - Do I really need to explain how module scoping works here?
The browser has locked up trying to parse your JS bundle - This literally doesn't happen.
Let‘s say you have 5-7 dependencies to load, but 3 of them timed out because your train entered the tunnel. Your app ends up in incorrect state, fails silently and UX degrades unpredictably. This is where the conversion often drops visibly and the reason SSR is now a go-to solution for any marketing website.
