one of the most tired and misleading claims I ever hear about JS: "JS doesn't have a stdlib".
this is total horseshit. JS has a massive stdlib. just because someone makes a util lib with a bunch of popular little helpers in it doesn't mean JS doesn't have a stdlib.
this is total horseshit. JS has a massive stdlib. just because someone makes a util lib with a bunch of popular little helpers in it doesn't mean JS doesn't have a stdlib.
lodash/underscore are NOT A FUCKING LANGUAGE-QUALITY STDLIB.
some of them are great, some of them quite frankly suck and promote terrible coding.
it's a mish mash, a grab bag. that's not a clean, well-designed lang stdlib.
some of them are great, some of them quite frankly suck and promote terrible coding.
it's a mish mash, a grab bag. that's not a clean, well-designed lang stdlib.
Not saying anything bad about lodash/underscore. they're fine libs, use them if you like.
guess what!? the good parts of those, just like the good parts of coffeescript, are now adopted into JS's... ahem... stdlib.
that's called language design. it's diff from util lib design.
guess what!? the good parts of those, just like the good parts of coffeescript, are now adopted into JS's... ahem... stdlib.
that's called language design. it's diff from util lib design.
please don't waste tweet space boring us with "no, no, but what about pick()" or whatever other little pet favorite util you love is.
liking a util in a lib is fine. using it a ton is fine. the whole world using it is fine. there's a more careful consideration for lang adoption.
liking a util in a lib is fine. using it a ton is fine. the whole world using it is fine. there's a more careful consideration for lang adoption.
the existence of popular util libs in userland isn't proof of lack of a stdlib.
it's proof that people like to make helpers for all sorts of tasks. it's proof the community can support itself thru userland innovation.
all good positive trends. in no way detractions against JS.
it's proof that people like to make helpers for all sorts of tasks. it's proof the community can support itself thru userland innovation.
all good positive trends. in no way detractions against JS.
good lang design doesn't bake every possible pet util helper into the language itself. it leaves stuff to the userland.
promotion to stdlib comes when you gain enough to overcome the downsides of stdlib inclusion, which are substantial.
promotion to stdlib comes when you gain enough to overcome the downsides of stdlib inclusion, which are substantial.
yes, that's right, utils which get baked into a lang are automatically less, by default, b/c now they can never be innovated on and changed. they're frozen forever.
we don't want to rush to put all of that in. we want to defer that adoption as long as possible, to give as much time as possible for things to grow and mature and evolve.
it should only go into the language once its evolution is all played out. or when there's a special factor such as perf gains that outweighs the loss of. flexibility.
this is called good, responsible language design and evolution... the restraint to NOT put something in is *far* more impressive than the rush to get your pet feature in.
I for one applaud TC39's caution, patience, and restraint. JS's stdlib is better off for it.
I for one applaud TC39's caution, patience, and restraint. JS's stdlib is better off for it.