i personally think javascript ECMAScript committee needs to take a break and chill for a bit. they are changing too fast. it's to the point one forgets if a certain new syntax is available in the whatever version they are and need to check the manual several times. it was fine from es5, 6,7, but if this keeps up at this rate, it's getting too much.
> one forgets if a certain new syntax is available in the whatever version they are and need to check the manual several times
You know that the current standard practice in JS-land is to always target the latest version, transpile specifying what browsers/runtime version you target, right? ...heck, even the way to config things like Babel sort of implicitly assumes this. Or pick something like Typescript that is practically always a superset of the current bleeding edge.
...it took me a while to grok the philosophy, but the only way to survive in modern JS-land is to fully adopt the "always bleeding edge" mindset. Any other way to think about it will end up driving you insane, as all the tools, framework etc. assume the "let tools handle versions compatibilty and always code for latest version" :P
JS is a "tooling ecosystem language", you don't just "write JS" you "write JS using tools X, Y, Z etc." The tools you use practically define the language. You can even say "fuck standardization" from time to time if you like need full-featured macros for a project and pull in some tool that adds this feature to JS and just use it. This kind of theoretically infinite power in the end made me "stop worrying and love the bomb" :)
Yet we're always transpliling JS anyway, all the time, for browser support. Might as well just bite the bullet and leave it as a compilation target and use something better, with less foot-guns.
