All I mean to convey is that the likes of Next.js aren’t a panacea: you do still need to be aware of what’s going on and sometimes adapt your code to work with Next.js. 80%, as you said.
And as an example of another sort of unnecessary brokenness, there’s a “Show more” later in that page that should have been serialised as a <details> element, but it’s done as a <button>. Here the lesson is: lean on what HTML offers, where possible.
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 (< 1%) was using the filtering system at all. Mostly people were just going directly to individual blog posts (social shares or whatever) or looking at the top few most recent ones. It was such a rarely used feature to begin with that we decided that it was OK to sacrifice for the non-JS users.
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...
Absolutely. Unfortunately this is harder to do in a Next.js world, because it’s obscured by abstractions. Life was much easier when you were clearly writing regular HTML and enhancing it with specific JavaScript because the whole thing was deliberate. With JavaScript frontend frameworks plus server-side rendering, the default is to be unaware of all of this stuff and you have to go at least a little out of your way to do it properly.
Too true. In 20 years of web dev, my job has largely gone from "writing inscrutable code" to "reverse engineering someone else's inscrutable code".
Heh, that's part of the joy though. Now it's no longer "production is down again, fix it!" it's "oh, AWS is down, wanna grab a coffee while we wait?". Or on the FE, "oh, I found the bug and submitted an issue on their Github, hopefully they'll fix it in the next version".
A form is just an bunch of input fields and a submit handler.
If you write your fields as real HTML input fields (instead of, say, weird bespoke divs that happen to have key handlers, yuck), you can still add JS to them for autocomplete and validation and such. But they'll still work without JS.
The other part is the submit handler. If you capture the submit button onclick to do something (like submit it using AJAX) then that won't work. But it's easy to add a HTTP POST fallback, and honestly that should be a best practice with or without Next. It's been like that since the jQuery days and before.
Beyond that, I can't think of anything specifically involved in SSR that would affect forms. Have an example?
Edit 1: If you're using a third-party module/framework/service to create a form, whether it will work with JS depends on its specific implementation. The MUI framework, for example, has higher-order form input abstractions (like the <Input> component here https://mui.com/base/react-input/#introduction) that depend on React and JS, but are really just wrappers around the HTML <input> element. It will still accept text without JS, just lose some of its secondary features. On the other hand, with something like Typeform... I couldn't even get the actual form to load without JS enabled: https://www.typeform.com/templates/t/demo-feedback-form-temp...
Edit 2: I thought of another way to interpret your question. In addition to the frontend parts of Next, which the above addresses, Next also has API endpoints and edge functions that can act as form handlers if you want them to. That only works if you're hosting on a live Node server (like Vercel), not if you're baking to static clientside HTML for CDN distribution. (The difference between `next start` and `next build`)
But that's kinda a tortured way to deal with form submissions. Usually the webforms would POST to someplace that's a preexisting business requirement (a Salesforce or Hubspot endpoint, for example, or even an email address), so you don't really have to use the Next middleware to handle submissions. You COULD do that in Next if you really wanted to, but I wouldn't myself... it would just be reinventing the wheel for no good reason.
that's a humble baseline, isn't it?
So while Next & SSR isn't a perfect solution, it is often the only practical thing to do when the team or company doesn't want to spend resources on a no-JS solution.