What's wrong with JS, exactly, that isn't made up for by its advantages?
I see these 'kool-aid' / 'JS is cancer' comments all the time, but they don't come with any real details.
I feel like you've probably never really used JS, if I'm being honest.
What's wrong with JS, exactly, that isn't made up for by its advantages?
I see these 'kool-aid' / 'JS is cancer' comments all the time, but they don't come with any real details.
I feel like you've probably never really used JS, if I'm being honest.
JS's only unique, redeeming quality is its availability through the deployment of web browsers, and the benefits that come with such widespread use. JS wins marketshare because it has marketshare. Any language could have taken JS's place, and most would have been better. WebAssembly, when DOM integration and others become a thing, might allow us to throw JS off its throne.
JS doesn't have advantages on its own to make of for its disadvantages, and relies heavily on extremely advanced JITs to make it borderline acceptable. The language itself still has very clear signs of having been designed on the back of a used napkin (its number type, its "array of int16's" string, "this", "prototype", ...).
I would like to acknowledge that ES2016 brought some things that did remove some retarded areas of JS (like arrow functions, which do not have its own "this" context, unlike the old function expression, class definitions that can briefly make you forget the terrible underlying "prototype" madness, and ways to access proper unicode code points in strings), but we are very far away from having actual advantages here.
I wrote bleeding-edge games and other crazy stuff in JS you might be using right now in your business, so my opinion is not unfounded.
On the web, and now suddenly on the desktop, velocity is not what we need. We need quality and consolidation. Down the line can you see any ES6 based API lasting as long as win32? Hell no. Why would I want to risk building a major capital product on such guarantees?
From a technical perspective, there are couple disadvantages in the long run that can make large codebases unmaintainable. In particular JS and PHP are resistant to static code analysis since they support functions like exec. So it becomes difficult to deprecate functions because the references are not necessarily explicit, thus can lead to tech debt buildup. ES6 does a better job but its backwards compatibility can leave the code vulnerable.
I think the prestige comment is a bit unfair, but today at work I had to educate a JS dev on what headers are in a HTTP request/request and some other pretty basic things (a dictionary/record type object and a JSON string are not the same thing for one). They were like "I know I've got to do these things, but I don't know why/how they work".
So yeah, I don't think disliking it because that's the average quality of JS dev I see is an unreasonable position. I'm sure there's some great ones out there doing impressive things, but I'm sure you could point them towards nearly any language and they'd produce something equally cool.
I'd say they'd produce something massively cooler ;-)
The language has some very ugly warts (although ES6+ fixes many things), I find that the quality/maturity/stability of third party libraries lags behind other languages, and the whole build/dev environment best practices is constantly in flux and breaking things all the time. Also Electron, for all it's advantages, is renowned for being a massive resource hog making what is otherwise a fairly fast and efficient language appear horribly slow at times.
That being said, developing in JS today is a lot better than 3-4 years ago, and I suspect that that pattern will continue.