As most people well know, all programming languages have their faults. Some have more than others. However, JavaScript is especially bad. That’s why you can find so many complaints about JavaScript on the web. One of the most amazing and distressing things about JavaScript is that it can actually fail silently at runtime due to syntactical errors! Another thing is “callback hell” which promises can mitigate but are otherwise not a perfect solution. The most notorious of JavaScript’s faults is probably in its weak typing (not to be confused with dynamic typing) which manifests in the profusion of WATs and WTFs that make JavaScript the butt of so many industry jokes. Here is one of the funniest (from a JavaScript proponent, no less!):

I won’t regurgitate the web only to say that a simple Google search will reveal JavaScript’s many internal inconsistencies and traps that literally make JavaScript a “digital minefield.”

The language is so bad that the use of a linter (such as JSLint or ESLint) is practically mandated for all JavaScript programmers. This, despite the fact that ECMAScript has undergone many, many improvements in recent years culminating in ES6. Apparently, the ECMA TC39 committee is unable to completely eliminate all of JavaScript’s most egregious faults. So ask yourself this question: What other modern programming language is so bad that a linter is most recommended for safety sake?

And let’s not overlook the fact that no linter is perfect. It cannot catch everything, and it may even produce false positives. Yes, that’s just the kind of thing you want from a static code analyzer.

When it comes to web development, JavaScript is a necessary evil. It’s the only language native to the web browser. In effect, it’s holding you hostage (and not surprisingly, many JavaScript programmers have grown to love the language, thanks to the Stockholm syndrome).

But you do have options! You can use languages that transpile to JavaScript. Here are some of the better ones, but there are many, many languages to choose from. For front-end development, you don’t have to choose JavaScript unless you’re sheep.

On the back end, you don’t have to choose Node (JavaScript) because the back end is already rich with many superior languages such as Java, Python, C#, Ruby, Erlang, and Go. Go, in particular: see The Fall of the House of Node.

I’ve been writing web applications for over a decade and it’s utterly shocking how little JavaScript I know! You don’t have to use much JavaScript at all, except perhaps to interface with jQuery and the like. I’ve done all my web development work with Java, Python (web2py), C#, PHP (Drupal), Smalltalk (Seaside), and Go (Beego). For the front end, in particular, I’ve used Amber Smalltalk.

So it’s really your choice. It’s up to you whether you want to dive into the chaotic world of JavaScript. That’s where the money is in terms of front-end jobs. But that’s also where the unholy mess of JS web frameworks is, which leads to “framework fatigue.” Angular 1, Angular 2, React, Ember, Meteor, Backbone, Knockout, Mercury, Polymer, Aurelia, Mithril, Vue, etc. (React is the current “hotness” but Vue could very well overthrow it.) These frameworks have the lifespan of a fruit fly!