The end of JavaScript?

 We will no longer write pure JavaScript really soon

I’ve been keeping an eye on the arrival of some ES6 and ES7 features and proposals, as well as some trending JavaScript technologies (particularly Compile-to-JavaScript languages like TypeScript, BabelJS or CoffeeScript) and I dare to predict that we will not longer write pure JavaScript really soon.

 What are your arguments?

I have some arguments to back up my idea:

 1. Compiler emitted metadata

We can find online proposals to add Decorators to ES7, along with a prototype for an ES7 Reflection API for Decorator Metadata. The idea behind decorators and reflection is that we can add some metadata to JavaScript objects in order to add support for some JavaScript features (like Dependency Injection, Runtime Type Assertions or Reflection/Mirroring) that were not possible no longer ago.

These new features will help us to improve the quality (reduced maintenance cost) of our JavaScript code and will allow us to create things that we were not able to create before (technological competitive advantage).

Since using these features can help corporations to save money it is likely that we will engage this new features really soon.

We are going to need metadata but who is going to write it? The idea is that developers will not have to write this metadata themselves and the compiler will generate the metadata for us. I don’t see myself thinking every morning “I can’t wait to get to the office and spend 8 hours writing metadata!” so I believe that we will use a compiler.

 2. Compilation security

Compilation-time errors can prevent us from dealing with many potential run-time errors. As we know run-time errors is something that we will potentially deal with during the maintenance phase of a project and that’s where most of the cost of developing a software product is allocated.


If using a Compile-to-JavaScript languages can reduce software development cost then, we will eventually use then because as we all know is all about the money.

 3. Compilation optimizations

If you have a depth understanding of JavaScript you will be able to ensure that closures are used only when they are necessary. You will also ensure that the performance of the application is as optimum as you can but what about those interns and junior developers in your team? Will they be able to do it? Is not their fault (they are just learning) but wouldn’t it be great if there was a tool able to prevent some of their performance mistakes?

Using a Compile-to-JavaScript languages compiler can help us to improve the performance of our applications without even needing to be aware of it. For example, we can use a BabelJS plugin to eliminate closures from your JavaScript wherever possible..

Good application performance could save a lot of money in infrastructure to your organization and (sadly or not) if something can be used by corporations to save some money then it is unstoppable.

If you are a JavaScript lover (like myself) please don’t panic, JavaScript, as we know it today will continue to, exists for many years but maybe only at run-time. As the level of abstraction continues to increase, maybe JavaScript will become a kind of CLR or JMV for the browser. The good news is that (if I’m right) developers with a good understanding of JavaScript will become a valuable resource just like somebody that knows enough java to understand the JVM or enough C# to understand the CLR.

 Which Compile-to-JavaScript language will we use?

Is hard to know because we are just getting started but if I have to choose one of the currently existing Compile-to-JavaScript languages I would go for TypeScript. I choose TypeScript because my own personal experience with it and because TypeScript seems to be becoming a really popular tool.

However, I won’t dare to attempt to predict how long we will be using TypeScript for.

 UPDATE (18 June 2015) just published the following headline:

Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web.

The source of the new is the Brendan Eich (creator of javaScript and CEO of Mozilla) personal blog. Brendan Eich wrote the following this week when he announced WebAssembly:

In a few years I believe all the top browsers will sport JS engines that have become truly polyglot virtual machines.

This makes me even more sure about the idea of all of us using a compiler in the future to develop a web application. What I wasn’t expecting is that Instead of compiling to JavaScript we may compile to a new binary format.

This could mean the end of JavaScript not just as a design-time language but also as a run-time language.

I don’t know how to feel about this because I love JavaScript but at the same time It would be amazing to be able to write web apps with a language like C# (especially for very large projects).

 UPDATE (19 June 2015)

Investigating about WebAssembly I have found two interesting talks about the rise of the compilers:

 UPDATE (9 October 2015)

Another interesting new related with this topic:

The V8 team (the JavaScript engine that powers Chrome, Opera, Node.js, MongoDB, etc…) are moving forward with an experiment in defining a stronger version of JavaScript that ensures that code being run is behaving well, and introducing run-time typing based on TypeScript’s typings.


The TypeScript team have started looking at what it might take to pass through your TypeScript code so it can be emitted in strong mode.



Now read this

Announcing InversifyJS 2.0.0 Release Candidate ?

Learn what’s new in InversifyJS 2.0.0 and what can you expect to see in the future of this powerful lightweight IoC container for JavaScript and Node.js apps powered by TypeScript As many of the readers of this blog already know, over... Continue →