I have to admit it. I was a big Javascript hater. I used to criticize the language on every possible aspect: syntax, maintainability, error prevention and management, and so on. Let me be clear, I still have a lot of concerns on all this things. I wasn’t wrong. Javascript’s syntax can be a nightmare (and this is why there are so many languages that transpile to Javascript), maintainability is a state-of-the-mind more than a language feature and a lot of Javascript design issues are an infinite-bug-spawner. But, after all, it is not so bad and it is going to improve significantly in the future.

In the last months, I get used a lot to the Javascript ecosystem and community and it becomes a language in which I feel quite happy to work with. Let’s see why (and why still is not a perfect language).

Ecosystem

Javascript has an huge community. It is the language with the most vibrating and productive (in raw numbers) community (various sources, but you can look at the GitHut stats). As a consequence, the JAvascript community have produce an huge effort into making the Javascript workflow as smooth as possible. There is a tool for everything: task automation (Gulp, Grunt, etc), unit testing, both asynchronous than synchronous (Mocha, Karma), code coverage (Istanbul and others), documentation, package management. In other words: everything. Many of these tools works wonderfully and are also very fun and cool to work with. If you want to understand what I’m talking about, just take a look at the Mocha’s reporters.

On the other hand, this abundance of tools is also the big problem in Javascript ecosystem. A lot of tools overlaps with others, new tools are continuously being born and the best practice is continuously shifting. The Javascript ecosystem is a so quickly moving target that it is hard to keep track with everything. This can be confusing for sure.

Another source of confusion is about NPM and Bower. NPM is the package manager for Node.js while Bower is a package manager for the browser. In short: NPM is a package manager for Javascript projects running in the back-end and Bower is the package manager for the front-end. Or not, and that’s the problem. Often Javascript libraries are so generic that they can works both in the front-end than in the back-end. Many libraries live in both NPM and Bower. Some front-end libraries are only present in NPM. Bower itself is installed through NPM. It is a bit of mess, indeed. I really hope that in the future there will be a simplification for this. Maybe, NPM could be the unified package manager for front and back-end. Who knows…

However, this confusion is payed out by an huge amount packages and resources. The benefits of this will show up dramatically when you are working with really young languages (such as Rust) or niche languages (such as Haskell). Languages in which the community is still not so big (or not interested) into providing all the development support tools happy developers deserve.

The Language

The language itself it is considered the worst part. For many reasons, it is. But when Douglas Crockford says that there is a gem buried in the pile of bad design choices of Javascript, well, this is absolutely true. The language is elastic, powerful and definitely fast for a dynamic script language (only Lua JIT can compare). Moreover, a lot of functional programming patterns can fit perfectly inside the language (and this is a big pro for me).

The main problem for the language is that is old and it wasn’t designed for the tasks it is used today! Fortunately, the new standard ES6 will fix a lot of problem (for instance, introducing block scoped variables with the let statement, modules and a proper class declaration syntax). Then ES7 will fix another pile of things. The language is evolving and this is the most exciting and important thing Javascript is doing for itself. Personally, I’m really happy of the new features in ES6 and ES7 (with the implementation of the Future monad) will be even more interesting.

There is another “problem” in JavaScript: static types. Optional types annotation could be an huge boost in the scalability and maintainability of a JavaScript codebase. However, this seems not to be something we will see in the core language soon enough. But we have a solution! TypeScript is doing an amazing job here! The main strength of TypeScript is that it is a superset of the standard Javascript. This means that you can start with a plain Javascript file and this is already a valid TypeScript source code. Then you can start adding types annotation in order to obtain all the advantages that a static typed language can guarantee in terms of bug prevention, clarity of the code and refactoring possibilities. The goal for TypeScript to be “just JavaScript but with types” is the real killer-feature against all the other contenders.

With ES6, JavaScript will still be covered in crap, but less. And this is a very good news, for Javascript developers and not.

Javascript as the “assembly of the web era”

I’d like to end with a small opinion. There is just one big thing that is slowing down the Javascript evolution: browser compatibility. Every time a small change want to be implemented, we have to wait for the standard to be approved and then, that every browser will implement the change. On the other end ES5 is already well implemented in every browser. For this reason, in the last years, an huge amount of transpiler is born. I think that almost everything can be transpiled into Javascript, from other web languages to C++. So I started to think something… ES5 is a bad language, unsafe, clumsy, hard to handle… but it is well supported and, in other words, it is actually the “machine code” of the web.

It is so important to implement in the browser level all the ES6 (and ES7) standard when we can just transpile all the existing languages (and not only ES6) into a working ES5? Is this work worth to just avoid a compilation step? Transpiled languages have a faster evolution, they do not require that every browser in the world start implementing them. If I want to add an amazing feature in Javascript, I can just implement it and then add “compilation” step, and all the existing browser will be ok with it!

The extra compilation step will never disappear anyway! Now, everyone is starting using Babel to port ES6 code into ES5. They think that this is just a temporary step: when ES6 will be fully implemented, there will be no more need for Babel compilation. I don’t think so. Because at that time, we will start to use Babel for ES7, and so on. The need for a better Javascript (and a better web language in general) is too strong and transpilation is the key which free us from the chains of browser compatibility tables.

Think about that. I think it is and will be interesting in the future.