4 ms·

Really almost all of this comes down to, "don't use JavaScript to replace HTML". Everything else on this post derives from that one guideline. For example, "Imp

by _bxg1 7y ago

Really almost all of this comes down to, "don't use JavaScript to replace HTML". Everything else on this post derives from that one guideline. For example, "Implementing custom div layouts for forms while removing items like select or radio" is only possible if you're replacing native functionality with JavaScript. Which is perfectly fine advice if you aren't doing anything really novel. You probably don't need a custom library for dropdowns or forms or whatever else and would gain performance, accessibility, and stability by hooking into the native versions instead. The one part I disagree with is necessarily using <table> in place of divs with CSS Grid. The latter is native and is a perfectly legitimate replacement, with some added benefits like responsiveness. Also the title is a bit of a misnomer, because lots of the HTML features that allow you to forego JavaScript are pretty recent: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation#Using_built-in_form_validation https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Fo... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input/color https://developer.mozilla.org/en-US/docs/Web/HTML/Element/In...

doc_gunthrop 7y ago
> Content being heavily reliant on JavaScript “injection” Salient point right here. Being served a blank white page (when JS is disabled) can deter a person from ever visiting a site again. Some peope out there want to vet a site before allowing it to run arbitrary code on their machine.
- darepublic 7y ago
  Hence the move toward static site frameworks like react static and gatsby
- _bxg1 7y ago
  > run arbitrary code on their machine That's a bit of an exaggeration. JavaScript is strongly sandboxed and has a pretty good permissions system. The only malicious things it can really do are 1) based on cookies or 2) crypto mining. Personally I think it's unreasonable to expect today's sites to work without JavaScript completely. The real benefits of using it sparingly are: - Pages load faster - Pages are more responsive - Applications are less stateful and call out to systems that have a larger number of eyes on them, making them less fragile and lowering maintenance complexity Minimalism is a virtue in any programming context
  - patrick5415 7y ago
    About the only time JavaScript is useful is something like google docs. The rest is just fluff and there’s no reason a webpage should require it.
  - tomjen3 7y ago
    I am split: web pages can be enhanced with JS, but webpage mostly shouldn't need them (exception: some data visualization does benefit from being able to dynamically change values). Web apps on the other hand, probably do need them. I use newsblur and definitely enjoy the shortcuts.
  - gugagore 7y ago
    The microarchitectural side-channel attacks that have received a lot of attention lately really challenge the idea of a "sandbox". Also the poster said that webpages shouldn't be blank without having, not that they should be fully functional. I think it's reasonable to expect some function without javascript.
  - bo1024 7y ago
    3) Fingerprinting and tracking in general are heavily javascript-focused. Less common in practice (I assume), but still possible, are 4) Rowhammer or Spectre/Meltdown style attacks that break out of the permission system. Finally, there's general trickery, manipulation, and malware, like trying to embed a frame from Facebook and steal user credentials or so on (I'm fuzzy on these sorts of attacks, not an expert).
    - dlhavema 7y ago
      Before javascript took over tracking the 1x1 white pixel ruled the land. No javascript needed there.
    - _bxg1 7y ago
      3) Right - and I guess "fingerprinting" goes slightly beyond cookies - but when people say "execute arbitrary code" they typically imply something has free-reign, which JavaScript generally doesn't. 4) True, although it's my understanding that the exploits are hard to implement, doubly-so from an abstracted layer like JavaScript. > trickery, manipulation...like trying to embed a frame from Facebook and steal user credentials or so on This falls under "cookies-based", and I'm pretty sure no JavaScript is necessary for these kinds of attacks.
- JustSomeNobody 7y ago
  Sadly, the majority of web devs don’t give a rat’s butt about those users.
  - SquareWheel 7y ago
    All they do is complain, make special demands, then go on to block ads anyway. It makes it hard to care about those users.
    - sgift 7y ago
      Could've been different if web devs listened when they got told "your ads get overbearing, no one can even try to concentrate on the content anymore" - but they were greedy and ad blocking came about as self defense.
    - cameronbrown 7y ago
      Seems that ad-blocking has made ads worse.
      - grogenaut 7y ago
        It's called an arms race for a reason
Lorkki 7y ago
> The one part I disagree with is necessarily using <table> in place of divs with CSS Grid. I suppose the soundness depends on how you read the word "table". For actual tabular data, <table> is probably the right choice for accessibility reasons. It's also why it's usually a bad idea to abuse tables for grid layouts in other cases.
- _bxg1 7y ago
  CSS Grid is intended to be a wholesale upgrade from <table>. Do screen readers actually factor in the semantics of table markup? > It's also why it's usually a bad idea to abuse tables for grid layouts in other cases. This isn't so much about semantics, it's about the way it kills responsiveness
- sodapopcan 7y ago
  I felt it was clear that the argument was <table> should be used for tables. S/he made no mention of layout.

by _bxg1 7y ago

doc_gunthrop 7y ago

> Content being heavily reliant on JavaScript “injection” Salient point right here. Being served a blank white page (when JS is disabled) can deter a person from ever visiting a site again. Some peope out there want to vet a site before allowing it to run arbitrary code on their machine.

darepublic 7y ago
Hence the move toward static site frameworks like react static and gatsby
_bxg1 7y ago
> run arbitrary code on their machine That's a bit of an exaggeration. JavaScript is strongly sandboxed and has a pretty good permissions system. The only malicious things it can really do are 1) based on cookies or 2) crypto mining. Personally I think it's unreasonable to expect today's sites to work without JavaScript completely. The real benefits of using it sparingly are: - Pages load faster - Pages are more responsive - Applications are less stateful and call out to systems that have a larger number of eyes on them, making them less fragile and lowering maintenance complexity Minimalism is a virtue in any programming context
- patrick5415 7y ago
  About the only time JavaScript is useful is something like google docs. The rest is just fluff and there’s no reason a webpage should require it.
- tomjen3 7y ago
  I am split: web pages can be enhanced with JS, but webpage mostly shouldn't need them (exception: some data visualization does benefit from being able to dynamically change values). Web apps on the other hand, probably do need them. I use newsblur and definitely enjoy the shortcuts.
- gugagore 7y ago
  The microarchitectural side-channel attacks that have received a lot of attention lately really challenge the idea of a "sandbox". Also the poster said that webpages shouldn't be blank without having, not that they should be fully functional. I think it's reasonable to expect some function without javascript.
- bo1024 7y ago
  3) Fingerprinting and tracking in general are heavily javascript-focused. Less common in practice (I assume), but still possible, are 4) Rowhammer or Spectre/Meltdown style attacks that break out of the permission system. Finally, there's general trickery, manipulation, and malware, like trying to embed a frame from Facebook and steal user credentials or so on (I'm fuzzy on these sorts of attacks, not an expert).
  - dlhavema 7y ago
    Before javascript took over tracking the 1x1 white pixel ruled the land. No javascript needed there.
  - _bxg1 7y ago
    3) Right - and I guess "fingerprinting" goes slightly beyond cookies - but when people say "execute arbitrary code" they typically imply something has free-reign, which JavaScript generally doesn't. 4) True, although it's my understanding that the exploits are hard to implement, doubly-so from an abstracted layer like JavaScript. > trickery, manipulation...like trying to embed a frame from Facebook and steal user credentials or so on This falls under "cookies-based", and I'm pretty sure no JavaScript is necessary for these kinds of attacks.
JustSomeNobody 7y ago
Sadly, the majority of web devs don’t give a rat’s butt about those users.
- SquareWheel 7y ago
  All they do is complain, make special demands, then go on to block ads anyway. It makes it hard to care about those users.
  - sgift 7y ago
    Could've been different if web devs listened when they got told "your ads get overbearing, no one can even try to concentrate on the content anymore" - but they were greedy and ad blocking came about as self defense.
  - cameronbrown 7y ago
    Seems that ad-blocking has made ads worse.
    - grogenaut 7y ago
      It's called an arms race for a reason

Lorkki 7y ago

> The one part I disagree with is necessarily using <table> in place of divs with CSS Grid. I suppose the soundness depends on how you read the word "table". For actual tabular data, <table> is probably the right choice for accessibility reasons. It's also why it's usually a bad idea to abuse tables for grid layouts in other cases.

_bxg1 7y ago
CSS Grid is intended to be a wholesale upgrade from <table>. Do screen readers actually factor in the semantics of table markup? > It's also why it's usually a bad idea to abuse tables for grid layouts in other cases. This isn't so much about semantics, it's about the way it kills responsiveness
sodapopcan 7y ago
I felt it was clear that the argument was <table> should be used for tables. S/he made no mention of layout.