You touch on a good point, but I'm not sure it has to do with this particular piece. Rather, the author seems really confused:
There are great projects like Underscore, Sugar,
Prototype, jQuery, CoffeeScript and many many more that
help to work around JavaScript’s language quirks.
Unfortunately they don’t mix and match very well. Also,
which map() or forEach() implementation should I use if I
have multiple available?
That's like comparing barricuda, rubberbands, and bolts. Only one of the projects he mentions has anything to do with "JavaScript’s language quirks," and that's CoffeeScript. Just another person who did not know JavaScript/frontend development, expected it to be like any other programming environment, and bailed rather than stepping back and reconsidering his original assumptions.
I understand what you're saying but I'm humbly disagreeing.
I do believe that all the mentioned frameworks (while positioned differently) do offer solutions to work with/around JavaScript language quirks. e.g. simple things like
* working with collections
* working with objects
* extending 'things'
* iterating over 'things'
* working with async
That's one of the main things that I (and probably more) people find confusing about the JavaScript ecosystem even while I'm not new to it.
JavaScript provides arrays and objects, and also functions for grouping data (via closures). What else would you expect it to come with? The quality `goog.structs` package speaks to how easy it is to create very high-level data structures.
Are you perhaps thinking of the baroque and once-very-inconsistently-implemented DOM API?
Regarding your other points, JS is an extremely object-oriented language. I really don't think you need more "working with obejcts" things out-of-the-box. Iteration is very straightforward in all cases, unless you find hasOwnProperty confusing. The Node.js project has demonstrated well how easily Async maps to JS outside of the browser model (where Async has always reigned).
JS is a strange beast in certain ways, but it is a featureful language.
JavaScript is extremely poor at expressing OOP, it requires so much un-intuitive boilerplate to express your intent that many don't bother and will just hack together the simplest thing that works. Which causes the current situation of having so many different libraries to declare classes and they all do it their own unique way which are not compatible with each other.
It's the same for iteration, the hasOwnProperty is mostly omitted because it works most of the time without it and specifying it adds un-necessary boiler plate.
Same with async, there's a zillion async libraries that try to manage async in different ways and they aren't interchangable either. By standardizing on Futures/Streams it means all libraries can build on consistent and composable foundations and build higher-level functionality.
