I recommend reading through this issue [1]. It's amazing how much the JS community is firing against a bigger standard library, just because stuff like lodash exists and everyone can make their own packages anyways.
As a (mostly) C dev this is like bizarro world to me but I've noticed on HN and elsewhere that JS devs are very quick to move from one framework to an other, declaring a library dead if it hasn't received a significant update in mere months. I'm sure that there are plenty of JS devs out there who have fundamentally changed the way they code several times over the past few years.
With this mindset I can understand that there might be some reluctance to consider a standard library that would be "set in stone" and shape the language basically forever (and potentially create a burden of legacy feature that needs to be maintained, C++ style).
That's going to happen whether they expand the stdlib or not. Witness Array.prototype.flat() (because .flatten() would break websites using MooTools). I think the staged process they use and compilers like Babel work to get the proposed API in use so it can be evaluated against actual in-the-wild use, without contributing to ossification.
Yeah, why get an uniform experience when you can have a different hard time in each new code base ?
Why have basic features defined such as namespace, hashing, basic data structures manipulation, and uuid when you can have the unpleasure of rewritting it everytime ?
Why avoid making your users download primitives they have a 100 copies of on their machines in all those dll and so ?
It's not like those are solved problems in all other languages that don't have an accidental monopoly on the Web.
somewhat cynical/defeatist: Because those languages came along at a time previous to the web era and were often ruled by a single entity but in the web era XKCD standards rules https://xkcd.com/927/
I wonder how many of those people rallying against a standard library ever had to support a legacy codebase where all the design decisions were made by someone else. Doesn't sound like they have that kind of experience at all.
Funny thing is, eventually Google will decide that they do need a standard library and all those freedom fighters will do a 180 flip in terms of what they support. This already happened so many times in the community. (Classes being the most notorious example. I'm not saying Google was behind them, but there was a definite 180 flip on whether classes were needed.)
Maybe this is the first step towards Google establishing a standard library.
With this mindset I can understand that there might be some reluctance to consider a standard library that would be "set in stone" and shape the language basically forever (and potentially create a burden of legacy feature that needs to be maintained, C++ style).