3 ms·

But it’s also frightfully easy with such stacks to end up with invisibly broken functionality, e.g. a form that you maybe even intended to work without JavaScri

But it’s also frightfully easy with such stacks to end up with invisibly broken functionality, e.g. a form that you maybe even intended to work without JavaScript, but accidentally broke in some way; or a widget that is just blank in the HTML and gets filled afterwards (this is very common). As an example of that: in https://www.joshwcomeau.com/css/custom-css-reset/ https://www.joshwcomeau.com/css/custom-css-reset/, the first code block is a loading spinner. Why it’s different from the second one which has the content unhighlighted in a pre tag, I have no idea. And then later on there’s the “code playground” widget, which works (so long as you don’t try editing it), including syntax highlighting this time. Why? I can’t be bothered speculating. 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.

solardev 4y ago
Good points. I might even go a step further and say that not only should you be AWARE of how your page behaves after the magic (what breaks without JS, what doesn't), you should deliberately pick and CHOOSE what's OK to break and what is essential content, and design around it. 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...
- chrismorgan 4y ago
  > you should deliberately pick and CHOOSE what's OK to break 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.
  - solardev 4y ago
    > 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".

solardev 4y ago

Good points. I might even go a step further and say that not only should you be AWARE of how your page behaves after the magic (what breaks without JS, what doesn't), you should deliberately pick and CHOOSE what's OK to break and what is essential content, and design around it. 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...

chrismorgan 4y ago
> you should deliberately pick and CHOOSE what's OK to break 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.
- solardev 4y ago
  > 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".