The ES6 Conundrum
ECMAScript6 or ES6 is the evolution of JavaScript and it is the future. It is the technology innovation for the web we’ve all been waiting for. It is full of great functionality we always craved and it finally enables us to build huge applications for the web in a scalable and easy to maintain manner. It empowers thousands of developers coming from Java or C# or other “higher” languages to finally write JavaScript and bring all the goodness of their experience to a market in dire need of organization and direction.
That’s the sales pitch and — to be fair — a lot of it is true. However, it also makes a lot of assumptions as to what needs fixing on the web. And there is a real problem with evolving a language as ubiquitous as JavaScript without having control of the environments it is executed in. The web is a distributed platform. It is much harder to change the wheels on a vehicle that is constantly in motion than on one you can bring back to the shop, lock up, upgrade and drive out again.
JavaScript Doesn’t Seem to Cut It Any Longer
The, shall we say, lenient architecture of JavaScript has always been a source of confusion for programmers coming from other languages. Especially the lack of classes and prototypical inheritance is a no-go for a lot of people. It feels counter-intuitive and it doesn’t represent what is being taught in schools about computing. To make matters worse, we have the beautiful, but confusing construct of closures and a lack of constants and type safety. All that meant that JavaScript got a reputation for being badly architected and not to be trusted with large code bases. Despite all this, it managed to evolve into one of the most used languages in software development now – to a large part thanks to the rise of the web.
ES6 and the following versions of the language are meant to do away with these annoyances and make JavaScript a better, more reliable and more efficient language.
This, to be fair, is nothing new. We had a few languages that built on JavaScript in the past and tried to fix these issues. TypeScript, Dart, CoffeeScript and even Flash’s ActionScript all tried to solve the same issue. The difference was that they all needed some kind of conversion or container to show up in the browser. ES6, now that it is finalized, is intended to be native to the browser and run just like JavaScript using a script element pointing to it. ES6 has a lot of impressive features:
- Arrow functions as a short-hand version of an anonymous function.
- Block-level scope using let instead of var makes variables scoped to a block (if, for, while, etc.)
- Classes to encapsulate and extend code.
- Constants using the const keyword.
- Default parameters for functions like foo(bar = 3, baz = 2)
- Destructuring to assign values from arrays or objects into variables.
- Generators that create iterators using function* and the yield keyword.
- Map, a Dictionary type object that can be used to store key/value pairs. and Set as a collection object to store a list of data values.
- Modules as a way of organizing and loading code.
- Promises for async operations avoiding callback hell
- Rest parameters instead of using arguments to access functions arguments.
- Template Strings to build up string values including multi-line strings.
Considering what we’re doing with JavaScript these days, this seems to be a real need. Gaming, App Development and even server side development all are possible in JavaScript. And with each environment we have developers that are used to different tools and methodologies. The wild west web development of the past seems to be counterproductive to the performance and maintenance needs of today. This reminds me of the time when we moved from DHTML to DOM Scripting. Order, we need order and reliability.
Where this falls apart is that currently ES6 is far from ready to be deployed on the web. That is not the fault of the language, but of the nature of the web. We can’t and shouldn’t dictate what people use to surf the web. But the support for ES6 in different current browsers is not encouraging.
The bigger problem is that ES6 breaks the device and browser-independent idea of the web for the first time in the history of JavaScript.
Continue reading %The ES6 Conundrum%
LEAVE A REPLY
You must be logged in to post a comment.