Well, in short because JS is one of the more awful experiences you will ever have with programming in the modern world.
Nowadays you can't do anything remotely serious with it without a massive toolchain that makes setup really difficult, near impossible to figure out what goes on at every step, and challenging to debug things. Want to just write a quick little thing in JavaScript? You'll have to go to stack overflow to copy & paste a bunch of helper stuff into your code before you can even write the most basic "pick a random number between X and Y" into your app.
The NPM ecosystem is pretty terrible for many reasons, mainly poor design of NPM, and the fact that JavaScript having almost no useful standard functions at all means there's a library for everything - installing a few basic dependencies for your project will end up with you downloading hundreds of libraries, many littered with bad decisions, security implications, and gotchas. Then someone decides to just push a new version to GitHub but reuses an old tag and suddenly your builds break for no apparent reason.
There is no clear standard for formatting code, there are gotchas with the popular choice of not using semicolons, and there's roughly 16 different variants of the language - the JavaScript that actually runs on your browser (but just which parts depends on the browser hue hue), ES6, ES6 + flow, and so on. There is constant infighting about whose tool of choice is the best, and they keep evolving but there's no good documentation about anything, so you end up having to waste a ton of time guessing.
The community is full of people who think all of these issues are good, and like the new features with incomprehensible syntax, like apparently functions weren't clear enough when they were function(arg, arg2) { return "something"; }, but now need a shorthand syntax that looks like the nightmarish things from CoffeeScript, yet nobody is interested in trying to fix the serious and deep issues with the language. For some incomprehensible reason people like writing short code, like arg = ~~arg instead of clear code.
One such issues that is constantly causing pains to everyone working with anything where JS is related is that there is really no validation of arguments. People get lazy with using named arguments and doing checks, so they pass option objects, but these objects are never validated against any schema, so you end up e.g. writing configuration like {plugin: ["foo"]} and can't figure out why the foo plugin isn't loaded. No errors anywhere, it just doesn't work. Turns out you were supposed to use the key plugins, and you just wasted a day on one character.
The whole object and prototype system is like a massive hack and feels like an afterthought, which causes significant memory leaks and other issues all the time - think you can bind a reference to this.processClick on some event handler? No - this is another reason to end up with tons of pointless boilerplate in your applications to copy & paste a bunch of this.processClick = this.processClick.bind(this) in the constructor.
Then there are a lot of the just plain language design issues, like Number, clearly wrong choices for truthiness, lack of errors where clear errors in code occurred, poor error handling in general especially in the new async handlers, and so on.
There's probably quite a lot of other things that I quickly bump into every time trying to work with JavaScript, and these are just the ones I can quickly remember off the top of my head.
Really the best way to write JavaScript is to not write JavaScript and adopt another toolchain instead. TypeScript is ok, but ends up with most of the same convoluted toolchain anyway, and you end up with having to deal with npm and typings which are really poorly available. Elm and other such languages with their own ecosystem and tools that just compile into JavaScript are the biggest hope I have for the frontend world.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
It would be pretty amazing if in the near future WASM became a fully viable option, with full access to DOM and all the browser APIs, where you could load WASM code onto a browser as easily as JS code.
So many great languages compile to WASM now that it'd basically revolutionize the whole frontend experience, both for developers and users. This actually makes me ponder if Electron was nicer if you'd build WASM apps for it 🤔
Until then, these languages compiling into JavaScript are a glimmer of hope, Flutter maybe one of the bigger ones due to getting pretty significant performance benefits on mobile devices.
Also check out Bolero. It is F# MVU on web assembly. I haven't used it per se, but we are developing a product using its constituent elements (F# and Elmish, but built with JS toolchain similar to how we did Elm). I also have an Elm project in production a couple of years for comparison. For both technical and non-technical reasons, I prefer F# Elmish over Elm.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well, in short because JS is one of the more awful experiences you will ever have with programming in the modern world.
Nowadays you can't do anything remotely serious with it without a massive toolchain that makes setup really difficult, near impossible to figure out what goes on at every step, and challenging to debug things. Want to just write a quick little thing in JavaScript? You'll have to go to stack overflow to copy & paste a bunch of helper stuff into your code before you can even write the most basic "pick a random number between X and Y" into your app.
The NPM ecosystem is pretty terrible for many reasons, mainly poor design of NPM, and the fact that JavaScript having almost no useful standard functions at all means there's a library for everything - installing a few basic dependencies for your project will end up with you downloading hundreds of libraries, many littered with bad decisions, security implications, and gotchas. Then someone decides to just push a new version to GitHub but reuses an old tag and suddenly your builds break for no apparent reason.
There is no clear standard for formatting code, there are gotchas with the popular choice of not using semicolons, and there's roughly 16 different variants of the language - the JavaScript that actually runs on your browser (but just which parts depends on the browser hue hue), ES6, ES6 + flow, and so on. There is constant infighting about whose tool of choice is the best, and they keep evolving but there's no good documentation about anything, so you end up having to waste a ton of time guessing.
The community is full of people who think all of these issues are good, and like the new features with incomprehensible syntax, like apparently functions weren't clear enough when they were
function(arg, arg2) { return "something"; }, but now need a shorthand syntax that looks like the nightmarish things from CoffeeScript, yet nobody is interested in trying to fix the serious and deep issues with the language. For some incomprehensible reason people like writing short code, likearg = ~~arginstead of clear code.One such issues that is constantly causing pains to everyone working with anything where JS is related is that there is really no validation of arguments. People get lazy with using named arguments and doing checks, so they pass option objects, but these objects are never validated against any schema, so you end up e.g. writing configuration like
{plugin: ["foo"]}and can't figure out why the foo plugin isn't loaded. No errors anywhere, it just doesn't work. Turns out you were supposed to use the keyplugins, and you just wasted a day on one character.The whole object and prototype system is like a massive hack and feels like an afterthought, which causes significant memory leaks and other issues all the time - think you can bind a reference to
this.processClickon some event handler? No - this is another reason to end up with tons of pointless boilerplate in your applications to copy & paste a bunch ofthis.processClick = this.processClick.bind(this)in the constructor.Then there are a lot of the just plain language design issues, like
Number, clearly wrong choices for truthiness, lack of errors where clear errors in code occurred, poor error handling in general especially in the new async handlers, and so on.There's probably quite a lot of other things that I quickly bump into every time trying to work with JavaScript, and these are just the ones I can quickly remember off the top of my head.
Really the best way to write JavaScript is to not write JavaScript and adopt another toolchain instead. TypeScript is ok, but ends up with most of the same convoluted toolchain anyway, and you end up with having to deal with npm and typings which are really poorly available. Elm and other such languages with their own ecosystem and tools that just compile into JavaScript are the biggest hope I have for the frontend world.
+1 for the really honest rant - sounds like WASM support in other language ecosystems can't come quick enough :)
It would be pretty amazing if in the near future WASM became a fully viable option, with full access to DOM and all the browser APIs, where you could load WASM code onto a browser as easily as JS code.
So many great languages compile to WASM now that it'd basically revolutionize the whole frontend experience, both for developers and users. This actually makes me ponder if Electron was nicer if you'd build WASM apps for it 🤔
Until then, these languages compiling into JavaScript are a glimmer of hope, Flutter maybe one of the bigger ones due to getting pretty significant performance benefits on mobile devices.
Also check out Bolero. It is F# MVU on web assembly. I haven't used it per se, but we are developing a product using its constituent elements (F# and Elmish, but built with JS toolchain similar to how we did Elm). I also have an Elm project in production a couple of years for comparison. For both technical and non-technical reasons, I prefer F# Elmish over Elm.