NHacker Next
- new
- past
- show
- ask
- show
- jobs
- submit
login
Rendered at 00:14:57 GMT+0000 (Coordinated Universal Time) with Vercel.
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).
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.
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.
It's, um. Not the best kind of communication, and very easily leads to this kind of misunderstanding.
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.
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.
Regardless, this isn't really restricted to the usage of JavaScript. The website would likely have pretty bad UX if only half of the CSS loaded correctly, but no one programs defensively around it being absent.
An user opening a web page is not expecting a full-blown app with multi-second loading times. If that happens, they bounce, and you loose revenue. Web is supposed to have very short time to first content paint and very short time to interactive, the shorter, the better, less than 0.5s is the goal. It can deliver that, if built properly. Many SPAs, bulky JS apps are built this way for developer convenience, not for end users. The only real use case for SPA is when you deal with a lot of local data. A spreadsheet, document or image editor, a diagram tool (but then wasm is probably a better choice).
You may say, you are not building enterprise grade frontend. But if you are small enough, you don’t need SPA either.
Is it just that you're ashamed that you have made such poorly designed web apps that can't handle a few broken HTTP calls?
Is it just that you can't simply accept that JavaScript is a requirement for the modern web which is what this entire discussion is hinged upon?
You dismissed A/B testing as unnecessary. That is sufficient for this judgement. A/B tests mostly run on the happy path scenario of a customer: An A/B test breaks, the company is losing money at light speed.
The loading-related issues overall may eat 0,5-1% of the revenue. It is not something that should be an afterthought.
I didn't dismiss A/B testing. I'm just saying that, if the analytics don't load on the client, you should already have A loaded and ready to render. It's literally just a matter of a try/catch, and you shouldn't be waiting to load this stuff on the client-side anyways if this is truly supposed to be the "Happy Path".
Yes, I know that legacy software like Google Tag Manager requires client-side integration, but I would argue that is an orthogonal concern. You don't need to use that for your A/B testing. It's pretty easy to integrate this stuff into SSR-- especially if you stream in the HTML. This is why cookies exist.
And, again, none of this changes the central concept of this comment thread: JavaScript is necessary for the modern web experience.
Literally none of those things are necessary for a working website. If your site breaks when your analytics don't load, then that's just horrible design at any scale.
And if they're deliberately going somewhwre where there's no signal for an extended period of time, and really want it to work, they'll ensure they've loaded everything before doing so.
And I say this as someone who is developing a pwa that is for people with low end phones and very inconsistent and/or connections. I'm very cognizant and empathetic to their situation.
Something like Datastar would enable this with like two html attributes, and only require 10kb of js (and would also allow for endless other things via declarative html).
Good that you are asked. Did I say anything like that in my comment above?
Downvotes should give you a hint that the few users that know what javascript is, don't like it, and the rest of them, if they learned, most likely won't like it either. Your attitude shows that you don't care.
Let me get this right, you're saying that people on HackerNews don't know about JavaScript-- one of the most popular programming languages in the world?
Exactly! I agree with you 100%! I, and many others, don't like the modern web experience and JS is the foundation that makes it all possible.
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.)
If anything, hiding the hamburger menu behind an HTTP response is *less accessible*!
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.
I'm currently building a web-based tool that uses dynamic forms for UI, without the help of of a framework (yeah I know; I have reasons). This is the result: https://github.com/KaliedaRik/sc-filter-builder/blob/main/js...
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.
https://docs.astro.build/en/concepts/islands/
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.
Maybe it is you who are mobile centric?
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.