Your website should work without JavaScript (2021)

.js-only { display:none !important; }

this won't work on failed script loads, only on actually disabled javascript, though

There is nothing inherent to the internet or the promises thereof that require the kinds of interactivity that have driven the tidal wave of front end scripting that has flooded the space. The overwhelming majority of it comes down to designers being cute for no obvious reason and business entities that aggressively abuse their client's browsers and bandwidth solely because cross-browser compatibility is notionally cheaper than maintaining software across several operating systems. The rest is monkey see monkey do.

An example: At my last job (a museum), accessibility was a business need (and grantmaker requirement), and part of that is ensuring that our content was accessible by people using screen readers. At the same time, the website was owned by the marketing department, who had strong thoughts on design and "modern" UX. It was a constant tug-of-war between the two and the JS had to be carefully balanced.

For something as simple as a list of exhibitions or blog posts, it was essential that everybody and any browser be able to see a list with titles, a short blurb, and a thumbnail. That was the "must-have". Nobody should be excluded from reading our actual content.

Then, because we have posts stretching back years, we also wanted a good filtering system, so people could search for certain topics or keywords or whatever. That's the "nice to have" that we decided was OK to sacrifice for certain edge cases.

It is possible to write such a system using plain HTML (by sending HTTP GETs/POSTs and having the backend do the filtering). But such a system was much much slower for the user (multiple seconds instead of single-digit milliseconds, because the backend had to process the request, generate the HTML, and send the whole HTML back... instead of client-side JS that can just filter an already-loaded array in a few milliseconds, or at most request a JSON of filtered post summaries that's much much smaller than a full HTML page).

So we looked at our analytics and determined that almost nobody (I'm not saying that this is the ideal approach, just that it is AN approach -- dictated more often by business needs and resource limits, not developer ideologies. Some of our peer institutions (other museums) went opposite ways... some wrote in pure HTML and a sprinkling of bespoke vanilla JS, with very fast and lean pages that didn't have much clientside interactivity. Others went to the other end of the spectrum, creating richly animated interactive stories that are more like a educational game than a webpage. As a developer I have my own preferences on such things, but in the grand scheme of things, our ideologies rarely matter.

What practical frameworks like Next do is allow us to find an acceptable middle-ground between a lot of stakeholders, balancing UX, DX, DevOps, business requirements, resource costs, etc. Next is itself a frankenstein of technologies -- mirroring the modern JS and cloud service ecosystem -- that doesn't try to preach any particular ideology. It looks at the chaos out there, accepts it for what it is, and tries to harness the bits and pieces of it that makes sense to use in an average website. I think it does a pretty good job.

You can, of course, make similar evaluations and tradeoffs as an individual dev. But it's a LOT of work to think through and build and maintain. It was easy to make a JS site and no-JS site side-by-side back in the day (along with frames and no frames!), but that's not really a practical approach for the complexities of modern sites and stakeholders; it would increase development time by an order of magnitude or more. Progressive enhancement is great for simple sites that are really more "documents" than "apps", but even that starts to break down once you move from "documents" to "document store", as in you have a pile of documents originated from some content management system / production pipeline / editorial review process that multiple stakeholders work on together. At an organization of any real scale, you can't have your webmaster editing raw HTML every time somebody wants to update a blog post.

Web dev isn't a place for purists. The whole history of the web is "hack on top of hack". HTML is a barebones document markup language more aligned with Gopher than modern web apps, and JS itself was a me-too panicked reaction to Java (and later, ActiveX and Flash). That it grew to such popularity was an unfortunate coincidence of history, as the lowest common denominator that browser vendors could accept. V8's massive improvements to the JS runtime cemented its own fate, taking the web from "JS is useful for adding a little bit of interactivity" to "JS is now fast enough to BE the web". Now V8 is pretty the de facto operating system of the web, for better or worse. As individual developers, this isn't a system we work in, it's a system we work around because it's just what history left us. Every page we build is a hack on top of a hack, a workaround for another workaround that somebody wrote into spec or engine a decade ago for the needs of those days.

I hate it as much as anyone, but until we can get a new web ecosystem (crypto-web doesn't count), we're just kinda stuck with it...