5 ms·

Oh no! It's already out of date! (That's a JS changes too fast joke) But seriously, calling it 'modern' is pointless. It's not adding anything valuable and its

Oh no! It's already out of date! (That's a JS changes too fast joke) But seriously, calling it 'modern' is pointless. It's not adding anything valuable and its just going to become out of date (and thus wrong).

corytheboyd 6y ago
Honestly, it’s fine if documentation goes out of date, otherwise what’s the point of writing anything at all? The onus is on the reader to check the publish date of what they are reading, and to cross reference it with other sources to ensure accuracy.
- kaycebasques 6y ago
  I'd be careful about relying on "updated" dates too heavily. As a professional technical writer, I've seen that some people bump the "updated" timestamp for any update, no matter how small. At other times it's bumped automatically by the build system. I think the best practice is to only bump the timestamp for substantial updates, or to use an explicit changelog at the bottom of the doc. But that practice isn't standardized across docs sites.
  - corytheboyd 6y ago
    That’s a good point to call out, thanks! There is so much involved in being a “defensive reader” heh
  - olnluis 6y ago
    I encounter this "article update" problem a lot with Java blogs... Baeldung instantly comes to mind. Every article I find there was last updated on 2020, but don't seem to have actually changed.
willio58 6y ago
I think it’s precisely the fact that js is constantly changing that they’ve branded this as “modern”.
simonw 6y ago
Disagree. I've been writing JavaScript for twenty years, and I'm very aware that there's a lot of "new" stuff that I need to brush up on. When I saw it call itself "modern" I instantly assumed that it would be covering the kind of information I need to know.
- joshxyz 6y ago
  i think it's great on how it brushed on forms and web api's, but in your case it seems exploringjs.com would be a fit (grouped by ecmascript versions). OTOH out of scope are server-side JS (NodeJS), transpilers like babel, bundlers like webpack, and of course package managers like npm and yarn
- wolfadex 6y ago
  I, as a JS dev of 10+ years, wouldn't consider this "modern". I didn't see - for in loop - for of loop as a couple examples, and those have been around for at least a few years now. There's probably more missing too. To what the above person said. The usage of "modern" or "latest" or similar is going to fall behind and make for bad searching.
  - wa1987 6y ago
    > - for in loop - for of loop It's 2020 and you still use loops? ;-) source: https://github.com/buildo/eslint-plugin-no-loops https://github.com/buildo/eslint-plugin-no-loops
    - hombre_fatal 6y ago
      for/of is an iterator. It consumes the Symbol.iterator interface and is totally different from the for(i++) statement. That eslint rule is a good example of a cargo cult. The second link in its rationalization argues for using underscore over touching a dangerous loop yourself.
    - graup 6y ago
      Disallowing for..of iterators is the reason I cannot use or recommend the Airbnb lint preset. A very nice example of an anno 2014-2017 cargo cult that clearly hasn't held up. https://github.com/airbnb/javascript/issues/1271 https://github.com/airbnb/javascript/issues/1271
root_axis 6y ago
It's not pointless. In the context of JS 'modern' generally means es6+ or node as opposed to es5.
- jonnycomputer 6y ago
  just say es6, though, i guess?
mixmastamyk 6y ago
Make a merge request.
0df8dkdf 6y ago
to be fair. anything after 'use strict' can be consider 'modern'. However with the rate ES7 - 10 is going. Yeah this wouldn't be modern.
brundolf 6y ago
Nothing will become inaccurate, because JS never introduces breaking changes. The guide might come to lack some newer things over time, but I doubt those will include any major paradigm shifts, because the past ~10 years have likely been the most dynamic that JS will ever see in terms of idioms and best-practices. JS made a radical shift into a mature language, and now it is mostly on the other side of that transition. So writing a "modern" (post-transition) tutorial makes perfect sense to me, and I don't think it will become irrelevant any time soon.
- reificator 6y ago
  > Nothing will become inaccurate, because JS never introduces breaking changes. Can you help me debug why `document.createElement('button').attachEvent('onclick', e=>alert('attachEvent!'))` isn't working then? You might object that DOM APIs aren't part of JS proper and that's true, but this guide covers `addEventListener` on this page: https://javascript.info/introduction-browser-events https://javascript.info/introduction-browser-events Sticking only to JS language features, I assume you can help track down why my `with()` statement doesn't work. Or why `function testing() { console.log(this.location.href); } testing();` throws an error but only if I package my code as an ES Module instead of an AMD bundle. I agree that breaking changes like this are increasingly unlikely to happen, and I think the changes that have been made are easily net positive. But the claim that they never happen is simply not true.
  - brundolf 6y ago
    I do include the DOM API in my statement, but I do not include non-standardized browser APIs, which attachEvent seems to be. I'll refine my statement to "The JS standard never introduces breaking changes". attachEvent never was part of any standard, and is therefore subject to breakage. Non-standard APIs should never be part of a comprehensive guide to the language in the first place.
    - reificator 6y ago
      I was worried that leading with `attachEvent` would get a response about only `attachEvent`. The `with` statement is described on page 75 of the ES3 standard[0]. It does not work in an ES Module or in a strict mode context. This is a breaking change. [0]: https://www-archive.mozilla.org/js/language/E262-3.pdf https://www-archive.mozilla.org/js/language/E262-3.pdf

corytheboyd 6y ago

Honestly, it’s fine if documentation goes out of date, otherwise what’s the point of writing anything at all? The onus is on the reader to check the publish date of what they are reading, and to cross reference it with other sources to ensure accuracy.

kaycebasques 6y ago
I'd be careful about relying on "updated" dates too heavily. As a professional technical writer, I've seen that some people bump the "updated" timestamp for any update, no matter how small. At other times it's bumped automatically by the build system. I think the best practice is to only bump the timestamp for substantial updates, or to use an explicit changelog at the bottom of the doc. But that practice isn't standardized across docs sites.
- corytheboyd 6y ago
  That’s a good point to call out, thanks! There is so much involved in being a “defensive reader” heh
- olnluis 6y ago
  I encounter this "article update" problem a lot with Java blogs... Baeldung instantly comes to mind. Every article I find there was last updated on 2020, but don't seem to have actually changed.

willio58 6y ago

I think it’s precisely the fact that js is constantly changing that they’ve branded this as “modern”.

simonw 6y ago

Disagree. I've been writing JavaScript for twenty years, and I'm very aware that there's a lot of "new" stuff that I need to brush up on. When I saw it call itself "modern" I instantly assumed that it would be covering the kind of information I need to know.

joshxyz 6y ago
i think it's great on how it brushed on forms and web api's, but in your case it seems exploringjs.com would be a fit (grouped by ecmascript versions). OTOH out of scope are server-side JS (NodeJS), transpilers like babel, bundlers like webpack, and of course package managers like npm and yarn
wolfadex 6y ago
I, as a JS dev of 10+ years, wouldn't consider this "modern". I didn't see - for in loop - for of loop as a couple examples, and those have been around for at least a few years now. There's probably more missing too. To what the above person said. The usage of "modern" or "latest" or similar is going to fall behind and make for bad searching.
- wa1987 6y ago
  > - for in loop - for of loop It's 2020 and you still use loops? ;-) source: https://github.com/buildo/eslint-plugin-no-loops https://github.com/buildo/eslint-plugin-no-loops
  - hombre_fatal 6y ago
    for/of is an iterator. It consumes the Symbol.iterator interface and is totally different from the for(i++) statement. That eslint rule is a good example of a cargo cult. The second link in its rationalization argues for using underscore over touching a dangerous loop yourself.
  - graup 6y ago
    Disallowing for..of iterators is the reason I cannot use or recommend the Airbnb lint preset. A very nice example of an anno 2014-2017 cargo cult that clearly hasn't held up. https://github.com/airbnb/javascript/issues/1271 https://github.com/airbnb/javascript/issues/1271

root_axis 6y ago

It's not pointless. In the context of JS 'modern' generally means es6+ or node as opposed to es5.

jonnycomputer 6y ago
just say es6, though, i guess?

mixmastamyk 6y ago

Make a merge request.

0df8dkdf 6y ago

to be fair. anything after 'use strict' can be consider 'modern'. However with the rate ES7 - 10 is going. Yeah this wouldn't be modern.

brundolf 6y ago

Nothing will become inaccurate, because JS never introduces breaking changes. The guide might come to lack some newer things over time, but I doubt those will include any major paradigm shifts, because the past ~10 years have likely been the most dynamic that JS will ever see in terms of idioms and best-practices. JS made a radical shift into a mature language, and now it is mostly on the other side of that transition. So writing a "modern" (post-transition) tutorial makes perfect sense to me, and I don't think it will become irrelevant any time soon.

reificator 6y ago
> Nothing will become inaccurate, because JS never introduces breaking changes. Can you help me debug why `document.createElement('button').attachEvent('onclick', e=>alert('attachEvent!'))` isn't working then? You might object that DOM APIs aren't part of JS proper and that's true, but this guide covers `addEventListener` on this page: https://javascript.info/introduction-browser-events https://javascript.info/introduction-browser-events Sticking only to JS language features, I assume you can help track down why my `with()` statement doesn't work. Or why `function testing() { console.log(this.location.href); } testing();` throws an error but only if I package my code as an ES Module instead of an AMD bundle. I agree that breaking changes like this are increasingly unlikely to happen, and I think the changes that have been made are easily net positive. But the claim that they never happen is simply not true.
- brundolf 6y ago
  I do include the DOM API in my statement, but I do not include non-standardized browser APIs, which attachEvent seems to be. I'll refine my statement to "The JS standard never introduces breaking changes". attachEvent never was part of any standard, and is therefore subject to breakage. Non-standard APIs should never be part of a comprehensive guide to the language in the first place.
  - reificator 6y ago
    I was worried that leading with `attachEvent` would get a response about only `attachEvent`. The `with` statement is described on page 75 of the ES3 standard[0]. It does not work in an ES Module or in a strict mode context. This is a breaking change. [0]: https://www-archive.mozilla.org/js/language/E262-3.pdf https://www-archive.mozilla.org/js/language/E262-3.pdf