Why We Won’t Be Writing JavaScript in Five Years
As you probably know, JavaScript was created by Brendan Eich in 1995 in only ten days. Many developers love to make fun of it, but it’s an excellent language if you consider how little designing it took. Most of us can’t event finish a sprint in ten days, let alone implement a programming language.
Of course, it’s far from perfect and through they years it got updated, although not as much as it should have. Luckily TC39, the committee responsible for evolving the language, decided to release one new version every year starting from 2016.
We already saw the first benefits of this work with ES6. All the new features (arrow functions, generators, modules, …) make it almost look like a new language.
Despite all these efforts, JavaScript still falls behind if compared to other programming languages and will have a very hard time catching up. There’s no support for data types, it’s difficult to work with double precision numbers, we need to use libraries like Lodash or Moment to have a decent standard library. It’s functional but pales if compared to other languages like Haskell or Elixir.
The list goes on and on. After all, its initial purpose was to allow creating basic interactive pages far from what we are building today.
What’s making improvements to the language so slow is the fact that JavaScript is always retro-compatible. Every new change must not break existing code. There are more than one billion websites out there, and all of them must still work after every browser update.
We need a new language. A language that is better suited to help us create the web of tomorrow. The problem is that browsers won’t get one anytime soon.
The one language that got closest to being adopted by browsers was Dart. When Google released it, people were afraid it was part of a secret plan to substitute JavaScript in Chrome. Needless to say, this never happened.
Even if all browser vendors decided to switch from JavaScript to a new language, developers would still have to support older browsers. In other words, we would have to build two versions of the same application. Remember when we had to create a mobile version for websites or add specific CSS code for one browser? This would be 1000 times more painful.
So why am I saying that I won’t be coding in JavaScript in 5 years? Rest assured it’s not because I decided to become a native developer. Nothing against native development but I love the web, and I hope I’ll keep creating web applications for many years to come.
I attended Jafar Husain’s talk at the last Full Stack Fest in Barcelona. His talk was about the future of ES6 and, in particular, new ways to handle asynchronous code.
During the Q/A I asked this question:
He also gave a longer answer on stage. He claims we should be happy to use tools like Babel. They allow us to use the latest features of JavaScript today without having to wait for browser vendors to implement them.
He also added that, since we have source maps, we don’t even have to deal with the transpiled code anymore.
In 5 years JavaScript will look very different from what we have now. Still, that code will be transpiled to ES6 or even 5.
And that got me thinking: if I must use a transpiler anyway, why not choosing one that works with a better language? A language built to create rich web applications.
You may argue that since we transpile to JavaScript, this new language could not be too much different and would be bound to JavaScript’s internal logic. It would just be some syntactic sugar on top of it. Similar to TypeScript or JSX.
Well, I’m happy to tell you that we’re already working on a low-level format, and it is called WebAssembly. It’s not ready yet, but when it will be, new languages will flourish. These languages will be compiled and executed by the browser almost as fast as native code. And they won’t have to be retro-compatible because developers will compile them, the source code won’t be sent to the client.
Think of what assembly is to C but built for the web.
So, I don’t know which programming language I will be using in 5 years. Elm is currently the top candidate, and it expressed intent to support WebAssembly at some point. What I can tell you is that in the future instead of having a new front-end framework every week we’ll have new front-end languages. And that, if you ask me, is a good thing.
