> [] + []
>
> {} + []
>
> [] + {}
>
> {} + {}
It means that if you feed it nonsense it does not stop you but happily carries on and explodes a few milliseconds later somewhere else. Another can of worms is the difference between null, 0,undefined, '', ....Ok, you got me worked up. I need to go for a run to blow off steam.
> "There are only two kinds of languages: the ones people complain about and the ones nobody uses".
I'm not a fan of JavaScript but I do like TypeScript.
Coercion rules are terrible, but they were only added to the language due to developer demands.
If you worry about zero or empty string, you’ll have problems in tons of other languages. Null vs undefined is less understandable along with the old ability to redefine undefined as it was a variable . In any case, I agree that one of the two shouldn’t exist.
Complaints like integers come from not studying the language and not keeping up to date.
Asm.js type directives have offered 31-bit integers for years now on all major JITs. That is slowly not working again as wasm takes over, but BigInt has been included for quite a few browser versions now.
Perhaps, or perhaps fixing one too many bugs where someone thought floats were appropriate for all the things. Regardless, forced change, even if it is a good change, is still forced.
I think a lot of the arguments are due to the clash of these two opposing mindsets, people who start in javascript and build things in a browser think it's great, people who build enterprise applications with typed languages disagree, often strongly.
Want to create/maintain a modern JS/TS stack? Well, you are going to need npm, webpack, probably babel, linters, need to understand how to setup source maps and get those working for debugging server side. etc.
It's a nightmare and it's all very fragile and that isn't even touching on the poor quality of the libraries outside of React/big ones.
It's definitely not there yet but they have the right idea.
Better JIT, real threads (also Loom coming which is better than async/await or Promises), better standard library, better library ecosystem, better profilers, better debuggers, better metrics/monitoring for the VM, better portability.
It seems to me that the core server-side JS benefit is isomorphic code on browser and server which is probably useful if your team is small enough to have the same people working on both but for companies of the size I generally work for this is rarely the case beyond maybe small fixes I might do in JS/TS.
For me personally this can't offset the absolutely gigantic difference in quality between say JS/TS and Kotlin/Java.