If you are a developer who hates JavaScript it’s most likely due to memories (or nightmares) from trying to use a primitive language in a primitive development environment, that has admittedly not always been the most productive tool to use to make a tight deadline.
Much has changed since then. This is not your father's JavaScript, and it merits a new look and an open mind. Things have improved, but additionally there's simply no practical way to avoid the de-facto standard operating system of the client-side Internet, which is a web browser, JavaScript, and a hotbed of constant and rapid improvement compared to the past.
As of 2013 there are important reasons for developers to understand what the good things JavaScript has to offer. If you haven't embraced it yet, it probably doesn't mean you’re a less capable engineer rather, you just haven't repeated your cycle yet. By that I mean, all good developers intentionally place themselves in a never-ending cycle of ignorance, discovery, learning, and experience. On the contrary, if you've never felt lost as a developer, you’re probably not pushing the boundaries of what your talent will allow you to learn.
The most common reasons I hear developers still rail against JavaScript are:
- It Did Suck in the Past, This is True
- Functional Languages are Painful
- Concern that Language X is More Elegant
It Did Suck in the Past, This is True
Lots of people first tried JavaScript back when web sites first started becoming interactive. Coding JS web pages back then was indeed a nightmare. The browser consistency alone would make you pull your hair out (before jQuery helped normalize things). The language itself also had much less functionality at that time. For example, there was no exception handling and not even decent string handling. Oh, and you didn’t mind not having a debugger, right? Of course I had lots of frustration with JavaScript too back then, but things have changed.
First off, the language is now based on standards and ECMAScript has been actively making improvements to the language for the last 15 years. ECMAScript 6 and other standards like CommonJS are making JS suitable for larger scale software development.
Not by accident, JavaScript is the only language to have native support for JSON, which has become one of the most popular data formats for web services.
Tooling has vastly improved. There are first class developer tools available in the browser and for JS outside of the browser. Microsoft has made JavaScript a first-class citizen for it’s most strategic upcoming platform to build native mobile apps. There are many nice IDE’s to choose from like WebStorm. Collaborative debugging and prototyping are excellent due to tools like Plunker and JSFiddle.
Perhaps most importantly, the ecosystem of frameworks, libraries, and components available for JS in 2013 is incredibly rich. Ecosystem strength directly drives productivity for developers.
Ouch - Functional Languages are Painful at First
This is a real problem because JavaScript looks very similar to C based (imperative) languages but behaves very differently as a functional language.
Developers can quickly feel an initial level of familiarity, and then get a jarring, bad taste in their mouth when forced to retrain their basic expectations. It’s a cruel joke to be lured in with comfortable curly braces and then be forced to learn what a closure is.
The key here is to not fall for the joke, and instead simply read a tiny bit on the differences between JavaScript and other languages. This won’t make you an instant functional programming expert, but you’ll know exactly what to look out for and won’t be burned by false expectations.
There are other comfort issues, such as static vs. dynamic typing that may seem like a philosophical schism but are more about how much time you spend in the saddle of one or the other. After you’ve written a certain number of lines of JS code the discomfort will simply disappear, believe it or not.
Concern that Language X is More Elegant
Being concerned about what is the absolute most elegant programming language is valid and critically important for language designers.
However most of us are not pure theoreticians, and as engineers, we know good engineering is the art of compromise. This doesn’t mean engineering isn’t or can’t be elegant. It means we don’t think about the elegance of one component in a vacuum. It’s our job to weigh many factors and optimize for the big picture.
Is Google’s Dart a more elegant language than JavaScript (not to pick on Google but Dart has received a lot of positive press recently)? Maybe. Should I learn Dart in my spare time? Probably. Should I use Dart for my next work project? Not necessarily.
Besides the advantage conferred by the massive JavaScript ecosystem, you can’t underestimate the power of ubiquity. JS started as a browser scripting language, and now it’s used in node.js to drive some very large and scalable server applications. It’s also big in mobile app development where it’s built-in as a hybrid app solution for Android and iOS, and a native solution for Windows 8 mobile devices.
If nothing else, think of your return on investment as a developer. Once you learn JavaScript well, you have the option to use it for a wider range of problems than almost any other language. A corollary to this is you have more options to participate in work you really care about.
This is not a JavaScript Love Fest
In the same spirit of why we shouldn’t hate JavaScript, we also shouldn’t become too attached to it, or any other tool or technique. JS is useful for many scenarios and is relevant to the world as of this moment. When (not if) the world is different next year, we should neither hate nor love it.
We should just start asking questions again as good engineers are supposed to do and push the standard bodies to keep pushing the envelope. It’s unstoppable and getting better rapidly.
If you’re not sure you even want to hear the word closure let alone spend time learning about such a thing, I can at least try to offer the comfort it’s not a JavaScript specific concept. It’s becoming a more common concept in many languages (specifics vary; however, the concept is common and is the hardest part to digest).
The bottom line is, most likely you’ll end of benefiting from mastering not only closures, but also many other JS and functional language concepts, whichever direction your career takes you, and regardless of how much you end up using the language.