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

just say es6, though, i guess?

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.

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.

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.

That’s a good point to call out, thanks! There is so much involved in being a “defensive reader” heh

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.

> 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

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.

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.

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

Strict mode was invented as a way of introducing a handful of "breaking" changes without them actually being breaking, since it's opt-in. JavaScript had some egregious design issues from the beginning and strict mode is a remedy to some of them.

But when most people say "breaking changes" they mean things that suddenly cause legacy code to stop working, and non-strict mode will almost certainly be supported ad infinitum, so I don't really count that. It's also almost certainly never going to happen again.

JS (the language) may never introduce breaking changes, but JS (the ecosystem) sure does. With a quite normal react app, breaking changes are a constant battle. Clone the repo, oops, one package was upgraded that broke another; upgrade that one, oops, it breaks another. The package manager is supposed to deal with that, but it (effectively) doesn't.

This aspect is irrelevant to the discussion because the OP only covers the language itself.

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

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.

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.

> - for in loop - for of loop

It's 2020 and you still use loops? ;-)

source: https://github.com/buildo/eslint-plugin-no-loops

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

Don't worry, there's plenty of 2020 cargo culting to replace it.

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.

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

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.

Make a merge request.