3 ms·

1) well look at that! I guess i've gotten a bit spoiled relying on lodash as much as I do! 2) There are aspects of prototypes that JS makes much worse (mainly

1) well look at that! I guess i've gotten a bit spoiled relying on lodash as much as I do! 2) There are aspects of prototypes that JS makes much worse (mainly the whole "this" clusterfuck), but the base is pretty sane and easy to understand. But at that point i'm not even talking about javascript any more, so I guess you are right here too. 3) I still disagree with you here. Yeah, there should be a way for the stdlib to do simple low level things (like isNumber()), but for others "one true way" isn't the best. I'd love a better stdlib, but I don't want something like Go's stdlib. I'd rather the language define a "bare minimum" and let libraries take over the rest. Now, as with anything in life this should be taken in moderation, if there are massive gains to be had by including something, then it probably should be included. Maybe this is stockholm syndrome setting in, but I'd rather have the choice of implementation of something in-language, because there are so many different engine implementations. 4) I was more speaking of things like a python library that only runs on 2.7, or a java application that only works on 6. For the most part, those things just don't happen in javascript. Yeah, you need to not use newer features until they roll out everywhere, but once they do, you are safe in using them for a pretty damn long time. In your example, you can't use const/let right now because safari is the last big holdout here. iOS 10 was just released, and with it Safari 10. In another month, i'd feel comfortable using const/let without transpiling it, and I won't need to worry about it again. But another benefit of multiple different implementations is they are free to optimize for different things. For example, Espruino is a JS engine that runs on microcontrollers and is EXTREMELY low power. Chakra (Edge's engine) shoots for really fast startup speed. V8 is pretty much the king in terms of raw execution speed. Contrast this with the Java way of having a million settings, knobs, options, and flags in the engine to tune the system the way you want. Yeah, you can do that, but most don't because of the complexity and risk involved. And there is only so much that you can do while having to support every option in the same engine. Like i said earlier, i'm not sure if it's stockholm syndrome taking effect, but JS is by far my favorite language, and despite all it's flaws, issues, problems, and mistakes, it's also the language i'm most productive in. And with ES2015+ it's only getting better. (although i'm dreading the time when modules start getting into implementations, and how they conflict with current solutions, that's going to be a NIGHTMARE in just about every way).

jomamaxx 10y ago
"But another benefit of multiple different implementations is they are free to optimize for different things." Every language has that. There are different JVM's, different C/C++ compilers, different python interpreters. JS is not 'at any advantage' here - and again - the drawback is the ridiculous fragmentation we see across browsers - which is ... bad - at least compared to other languages.
- Klathmon 10y ago
  But I wouldn't even say that. Look at the C/C++ situation. Microsoft as a platform doesn't support a ton of C, every compiler has it's own ways of using undefined behavior, there are tons of extensions and "only works on compiler X". Look at python where even if you ignore the 2/3 split, you have ironpython, cpython, pypy, and more that all have their own quirks, differences, and incompatibilities. It's pretty often you see a python library that only works on cpython. For all it's issues, JS has mostly moved past that. It's pretty rare to see a javascript program or library (that's not just a tech demo) that only works on one implementation. Hell Microsoft released a node.js fork that runs on chakra, and to my surprise every single one of our node applications runs on it without a single change or hitch. (i haven't looked up if this is "normal" or if i got lucky though, so take it with a grain of salt). Now obviously it's not perfect, and we should strive to be better, to fix these issues, but it's not like javascript is in some unprecedented scenario here. I actually think that the IE6 days have pushed JS to fix a lot of the problems that are plaguing other languages in this area.

jomamaxx 10y ago

"But another benefit of multiple different implementations is they are free to optimize for different things." Every language has that. There are different JVM's, different C/C++ compilers, different python interpreters. JS is not 'at any advantage' here - and again - the drawback is the ridiculous fragmentation we see across browsers - which is ... bad - at least compared to other languages.

Klathmon 10y ago
But I wouldn't even say that. Look at the C/C++ situation. Microsoft as a platform doesn't support a ton of C, every compiler has it's own ways of using undefined behavior, there are tons of extensions and "only works on compiler X". Look at python where even if you ignore the 2/3 split, you have ironpython, cpython, pypy, and more that all have their own quirks, differences, and incompatibilities. It's pretty often you see a python library that only works on cpython. For all it's issues, JS has mostly moved past that. It's pretty rare to see a javascript program or library (that's not just a tech demo) that only works on one implementation. Hell Microsoft released a node.js fork that runs on chakra, and to my surprise every single one of our node applications runs on it without a single change or hitch. (i haven't looked up if this is "normal" or if i got lucky though, so take it with a grain of salt). Now obviously it's not perfect, and we should strive to be better, to fix these issues, but it's not like javascript is in some unprecedented scenario here. I actually think that the IE6 days have pushed JS to fix a lot of the problems that are plaguing other languages in this area.