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.
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.