The Case Against JavaScript
It’s not a language with warts; it’s a minefield
Once in a while, I come across an article so beautiful in its elegance, and so persuasive in its delivery, that I am compelled to give it great tribute. The JavaScript Minefield is such a masterpiece.
My personal experience with this language has been less than edifying. It’s an awful, horrible, detestable language. I’ve been told by Douglas Crockford that there are “good parts” to the language; if you use a carefully chosen subset of JavaScript, you can write wonderful software. That may be, but the suggestion goes counter to every intuitive sense that I’ve acquired over 30 years in the IT industry.
I have used many languages in my career. I’ve used FORTRAN, Modcomp assembler, Tandem TAL, C, C++, C#, Smalltalk, Objective-C, Java, Python, and Go. NONE of these languages advocate avoiding certain parts of the language. What the hell kind of language is it that needs this kind of cautionary?! I’ll tell you: an extremely poorly designed one. A pathological one.
I have NEVER used a language that fails silently for syntactical reasons. Jesus Christ, how can this be???
How can this be?
(Yes, I know, it’s the browser’s fault; it’s an implementation issue. But given that JavaScript is the language of the web, you have to conflate the language with its implementation. There has to be a proper way to handle errors in the browser. Silent failure is not an option.)
Look, I know there is no such thing as a perfect programming language. Every language has its “warts.” But JavaScript is problematic on an epic scale.
Watch Where You Step
As Jeff Walker says, if you’re going to enter a minefield, you need one of two things: 1) a safe path through the minefield; 2) a detailed map of all the mine locations.
Douglas Crockford’s book, JavaScript: The Good Parts, provides such a safe path. However, it is all too easy to accidentally stray off the path. And sometimes, you have to step off the path.
Crockford’s book, as well as others, offer a map of the mines. This is problematic, too. Having to use a map while you’re programming is a major P.I.T.A. To paraphrase Crockford: “Programming is difficult business. It should never be undertaken using an inferior tool that imposes a heavy burden.” The added cognitive load of keeping the JavaScript minefield map in your head makes your job that much harder. Why should you take it upon yourself?
Why?
Linting is the best bad option of all the bad options
Tools such as JSHint and JSLint go some way to mitigate the awfulness of JavaScript. But it is not a complete solution and it suffers from some major drawbacks, the most egregious of which is this:
You have to drop out of your browser workflow to manually run the linters.
Sorry, I cannot abide by this. Linting should be directly integrated into the workflow. It should not take away the convenience of coding/testing in your browser and IDE. (Disclosure: I write applications using Go, Python, and JavaScript from within an IDE.)
And even if you could solve this problem, linting has genuine limitations. It won’t protect you 100 per cent. (Read Walker’s article.)
Recommendations
Don’t use JavaScript. Or at least use it as sparingly as possible. That’s what I do. I use jQuery to spiff up my web applications; I expect that will be my only exposure to JavaScript.
Use a tool that sits atop the minefield. Something like Dart or Go compiling into JavaScript is a possibility. There aren’t any good options at the moment, though (Dart is probably a dead-end) [1]. So I shall have to be patient and wait…
Until I do find the answer, I shall avoid JavaScript like Ebola. When I use jQuery, I shall don my hazmat suit and get the hell out as soon as I’m done.
[1] Actually, there is a good option: it’s called Amber. https://medium.com/@richardeng/a-gentle-introduction-to-amber-8c532631e9ab
