Backward compatibility and not seeing the future. Some decisions are taken at one point in time, then a new use case show up, then a new paradigm evolve, then… etc etc.
It’s really the same thing that holds back a lot of languages and libraries. And even when replacement shows up, old habits from devs and old projects maintenance keep all these things well alive too.
“I want predictable behavior for all possible inputs” is hardly a requirement that requires a fortune teller to see coming.
JavaScript has a particularly insane stdlib because this language wasn’t designed, it is a botched chimera with deformities so severe it should have died 15 times over but people just won’t let it.
Then to rub salt in the wound this horrific mess became the most popular language in the world by virtue of being the only language for the most popular application ecosystem in the world (the web). So the cancer is spreading and now you can find JavaScript in servers and fucking desktop environments and now your windows start menu takes five seconds to load because fucking react.js is loading the 75 polyfills necessary to make up for the fact that JS’s “standard” library looks like it was designed by 3 cocained-up gibbons.
Wow, prejudiced much. The JS ecosystem evolved a lot over the year, and polyfills for most environment are next to non existant. The worst environment to me (react-native) do heavily use them, but they’re built-in anyway.
Also, about stuff being slow when made in JS… people that make slow clusterfuck in JS would also make slow clusterfuck in other languages. React is guilty of that too, trying to re-implement core language features OVER the language itself, and that is stupid. Still, as with every language, it is possible to use it decently. You’ll never get to the point of raw optimized assembly performance, but even higher level scripting language can leverage JIT compilation and work well on any modern (<10 years) computer. Taking as an example the worst developers out there using the worst way to do things is not exactly a good benchmark.
Is it prejudice if I have extensive first-hand experience with it?
The worst environment to me (react-native)
Which is exactly what the Windows start menu runs on, doesn’t it?
I don’t even care that JS is slow, in most circumstances. I like Python, it’s not any faster necessarily (though it is much easier to debug CPython than V8 when you do eventually run into low-level issues, and python is still a lot better at multithreading than javascript even if the GIL is an issue, but that’s besides the point). My real problem is that the ES “standard” “library” is a complete clusterfuck, absolutely diseased, like engineers heard of the concept of technical debt and decided to build a shrine to it.
Sure, you can technically use JS decently. That’s hardly an achievement. Any sufficiently fast Turing-complete apparatus can be “used decently” if you start by re-implementing a python interpreter. But the entire ecosystem is fucked. The appeal of javascript, the entire reason it has taken over, is that the lowest bidder is not going to use decently but will do the wildest, most insane shit imaginable to get a product out the door.
I commented the other day about PHP. Same problem. The language is too easy to use badly. Sure, you can write magnificent code in either, if you have enough experience and discipline to avoid every footgun. But when every other tool in your shop is an unlabeled footgun, maybe it’s time to admit that there are some deep-seated issues.
Speaking of treating JS like a turing machine; that’s what TypeScript does. And, I have to admit, it solves maybe 40 % of the problems I have with JavaScript. I still don’t like it, because the stdlib and ecosystem still sucks donkey balls and V8 is a subpar JIT interpreter in every way besides raw single-threaded performance, but at least TS itself is decent enough and lends itself to static analysis well enough for senior engineers to have a hope of safely defusing or refactoring away most footguns set off by the junior/offshore devs. Most.
early js/html liked to do something in all cases instead of throwing or whatever. I think it’s mostly just a collection of them trying to do something smart on nonsense input and not being consistent about it.
side note, I’m so excited for Temporal, some browsers already support it and you can polyfill for the rest.
I … this seems like a std library made to troll you. Is there a (good) reason it is like that?
Backward compatibility and not seeing the future. Some decisions are taken at one point in time, then a new use case show up, then a new paradigm evolve, then… etc etc.
It’s really the same thing that holds back a lot of languages and libraries. And even when replacement shows up, old habits from devs and old projects maintenance keep all these things well alive too.
“I want predictable behavior for all possible inputs” is hardly a requirement that requires a fortune teller to see coming.
JavaScript has a particularly insane stdlib because this language wasn’t designed, it is a botched chimera with deformities so severe it should have died 15 times over but people just won’t let it.
Then to rub salt in the wound this horrific mess became the most popular language in the world by virtue of being the only language for the most popular application ecosystem in the world (the web). So the cancer is spreading and now you can find JavaScript in servers and fucking desktop environments and now your windows start menu takes five seconds to load because fucking react.js is loading the 75 polyfills necessary to make up for the fact that JS’s “standard” library looks like it was designed by 3 cocained-up gibbons.
Wow, prejudiced much. The JS ecosystem evolved a lot over the year, and polyfills for most environment are next to non existant. The worst environment to me (react-native) do heavily use them, but they’re built-in anyway.
Also, about stuff being slow when made in JS… people that make slow clusterfuck in JS would also make slow clusterfuck in other languages. React is guilty of that too, trying to re-implement core language features OVER the language itself, and that is stupid. Still, as with every language, it is possible to use it decently. You’ll never get to the point of raw optimized assembly performance, but even higher level scripting language can leverage JIT compilation and work well on any modern (<10 years) computer. Taking as an example the worst developers out there using the worst way to do things is not exactly a good benchmark.
Is it prejudice if I have extensive first-hand experience with it?
Which is exactly what the Windows start menu runs on, doesn’t it?
I don’t even care that JS is slow, in most circumstances. I like Python, it’s not any faster necessarily (though it is much easier to debug CPython than V8 when you do eventually run into low-level issues, and python is still a lot better at multithreading than javascript even if the GIL is an issue, but that’s besides the point). My real problem is that the ES “standard” “library” is a complete clusterfuck, absolutely diseased, like engineers heard of the concept of technical debt and decided to build a shrine to it.
Sure, you can technically use JS decently. That’s hardly an achievement. Any sufficiently fast Turing-complete apparatus can be “used decently” if you start by re-implementing a python interpreter. But the entire ecosystem is fucked. The appeal of javascript, the entire reason it has taken over, is that the lowest bidder is not going to use decently but will do the wildest, most insane shit imaginable to get a product out the door.
I commented the other day about PHP. Same problem. The language is too easy to use badly. Sure, you can write magnificent code in either, if you have enough experience and discipline to avoid every footgun. But when every other tool in your shop is an unlabeled footgun, maybe it’s time to admit that there are some deep-seated issues.
Speaking of treating JS like a turing machine; that’s what TypeScript does. And, I have to admit, it solves maybe 40 % of the problems I have with JavaScript. I still don’t like it, because the stdlib and ecosystem still sucks donkey balls and V8 is a subpar JIT interpreter in every way besides raw single-threaded performance, but at least TS itself is decent enough and lends itself to static analysis well enough for senior engineers to have a hope of safely defusing or refactoring away most footguns set off by the junior/offshore devs. Most.
early js/html liked to do something in all cases instead of throwing or whatever. I think it’s mostly just a collection of them trying to do something smart on nonsense input and not being consistent about it.
side note, I’m so excited for Temporal, some browsers already support it and you can polyfill for the rest.
No.
I can only imagine it wasn’t planned properly, cuz that’s so many quiet behaviours without good parsing errors