JS goes ES6

You may have asked yourself why the IT business uses acronyms so much. Or should I say abuse? There is no more justification for abbreviations and acronyms in a world of Terabyte disks with 12 GB memory on personal computers. So please pardon my conformity, here is the title again:

JavaScript is going to be EcmaScript 6

ECMA originally was the acronym for European Computer Manufacturers Association, but "the name is no longer considered an acronym and no longer uses full capitalization". So we have a meaningless acronym more. Didn't you get used to it yet?

---

This Blog is a short look into the coming ES-6 world, syntactically sugared with my own opinion :-)

If you're still on a year 2015 desktop-browser, you could update to e.g. Firefox 47 and try out ES-6 code, most of it is already working. Except that nasty little thing called "dependency management", until now solved by CommonJS and AMD, but going to be a browser responsibility. We have to wait for that? The browser support page doesn't even mention it.

And then it may take 2 more years until Internet users will be able to consume ES-6 web applications. So there's no reason to hurry. On mobile browsers, ES-6 support is missing widely.

ES-6 Links

You may want to read the facts first.

• Features: http://es6-features.org
• Browser support: https://kangax.github.io/compat-table/es6/
• Cheat Sheet: http://help.wtf/es6

Here are articles about the urgently needed dependency management:

• http://exploringjs.com/es6/ch_modules.html
• https://leanpub.com/understandinges6/read/#leanpub-auto-encapsulating-code-with-modules

ES-6 is much more complex than JS. Like Scala, it adopts techniques of functional languages.

It has constants. It has block-scoped variables and functions. It has classes. It has arrow-functions (lambdas, closures). It has typed arrays, maps, sets, even weak ones. String and Number support improved, internationalization basics are also provided.

Long Missed Spice

Encapsulation

Comes as export statements and modules. The top-level variables and functions of a module are not global in the window context. To make a function or constant globally available you need to export it. No more global namespace pollution.

Within a module, the this object is undefined, and the mode is always "strict", that means we do not need "use strict"; any more.

Modules are not scripts. Scripts still can not have imports or exports, just modules can. There will be a new type of script-tag for defining modules within HTML: <script type="module">.

Dependency Management

The import statement uses relative URLs as you would use on an <IMG> tag. There is a one-to-one mapping between modules and files: a module must be in a file.js, and a file is a module.

You can then locally rename the things you imported. You can import selectively, i.e. just one function or constant, not the whole module. You can not change any imported variable, it will be a constant.

A Promise based module loader API can be used to load modules programmatically in scripts.

Classes

So now JS actually is going to be object-oriented. What I saw on the features-page convinced me. The keywords new, this and super work as expected. We'll see what gotchas are behind it.

What did not convince me is the multiple-inheritance example. Multiple inheritance is unsafe, confusing, and mostly not needed. For example, Java doesn't have it, except on interfaces, but here you inherit just responsibilities, no concrete implementations. Moreover the example is too complex, and seems to be not generic. Showing muscles :-?

Block Scope

We can forget about variable hoisting and keep our code refactorable. The var keyword is dead, long live the let keyword.
Although - is this intuitive?

Constants

Why did this last so long? Constants definitely are needed in any programming language, not only the functional ones. In JS everything is public, thus we want to protect certain immutable values from being changed unintentionally.

Default Values for Parameters

In the parameter list of a function, you can assign default-values to the parameters, for the case that the caller does not define them. This makes the error-prone value = value || "(not given)"; statements dispensable.

Sugar

I do not mention the other ES-6 features because I do not consider them to be important. Moreover they are perfectly introduced on their web page. E.g. the arrow-function is just a shorthand for an anonymous function, and in JS this was a solid closure. So why promote copy & paste code in lambdas against anonymous functions that we could quickly refactor to be named and reusable?

Generally I think that ES-6 will make JS code harder to read. Look at the Generators and Iterators. I bet I'm not the only one that skipped these chapters.

Writing source code may be fun, but is just 20% of the real efforts related to a product that you sell to customers. The 80% maintenance start after the code has been written virtuoso, using all possible tricks, ignoring any convenience. Some temporarily hired high-paid expert then will look at those uncommented tirades and try to fix the bugs within them.

Code written in a simple and restrictive programming language is much easier to maintain. "Freedom of expression" refers to human social behaviour, not to communication with machines. Programming languages should not provide a playground. Here the idea of "reducing to bare minimum" (see below) would be valuable: reduce syntactical sugar!

So, you might know what it means to consume too much sugar :-) ES-6 is rich of it. This is going to be an expert language, inducing even more per-developer-dialects than JS. We will need further books with titles like "The Useful Parts of ...".

Finally a Semicolon :-)

ES-6 encourages you to leave out the semicolon:

.... But this era is gone ... perfectly support automatic semicolon inference/insertion ... coders nowadays can get rid of nearly all semicolons and remove clutter from their source code. Ralf S. Engelschall is a strong promoter of reducing source code to its bare minimum. Hence, in his personal opinion ECMAScript 6 should be coded with as less syntactic sugar as possible and hence without semicolons. ....

... clutter ... reducing code to its bare minimum ... All human expressions need a context, there is no meaning without context. When you read source code, you know the rules of the programming language. A semicolon denotes the end of a context. Although it's not a statement terminator in JS, it's still a statement separator. It makes the code more readable, and it also makes lots of other things easier.

For example I use JavaScript in articles of this Blog. When I back-up all my Blog articles, I get a big XML file, where the HTML of one article is packed into a single line of text, with all newlines removed. Without semicolons, the JS of that article would not work any more when I unpack and view the HTML. Yeah, we could file an issue to the Blog exporter ....

No, I don't want to take part in any semicolon discussion. Thank god it's still optional in ES-6, and that's what I'll use. But I'm not sure whether I will use the arrow-function, it's too sweet :-)