ES6 Rant

TL;DR, My first thought about ES6 was “but you’re just making things worse!”. I think the thumb-rule for improving a language will it be easier to learn it and not more difficult, and clearly that’s not gonna happen when you keep adding more arbitrary tools to do the same things but slightly differently (best example for this is for…of which iterate over object’s iterable elements, as oppose to for…in which iterates over all of the object’s elements.

To cut things short – JS is missing official versioning, that will allow it to purge bad code. It actually does have some  versioning, because when you add a new feature it does mean that an older browser won’t support your code and additionally, we already have “use strict”; which is actually versioning. So instead of ‘use strict’, we’ll have ‘use es6’ and everyone know how to handle it. We can later think of backward-computability to weird folks who still use IE6 by trans-piling and stuff. That’s a different story and isn’t that complicated, especially as I’m aiming mainly to clean to language and less on adding new features.

So looking at First steps with ECMAScript 6, I compiled my own remarks/suggestions of how I believe things should be done:

1. Scoping: var, let, const, IIFE and blocks

Originally {…} was suppose to be a block that contains privately-own local variable. JS screwed this up by keeping the variable to the use of the external function. I’m not sure why, but now they try to patch it up by using ‘let’. So let’s make it much more simple – {…} has its own variables that die as soon as the block ends, unless they’re being used by an internal block that outlives the original block. This is how to should have been to being with. Fixing is better than patching.

Const” my be a nice concept but when talking about pointers, which we do in 99% of the time, it’s actually meaningless.

2. Template literals = `hello ${name}!`

It’s a nice feature, but to be honest, is it really critical to be a core part of the language? I agree that the ability to write multi-line string can be incredibly useful. if we could only enforce having semi-colons at the end of commands, are code will become much more concise and everyone should know that line breaks means nothing to the compiler. And again, I don’t think template-engines are wrong – I just don’t think they should be part of a core language. Keeping them as a separate library will allow them to evolve independently. Why evolve? because we might want conditionals, loops, sub-templates and millions other things. why limit it?

3. Arrow function

Array functions are less readable. don’t. just don’t.

4. Multiple return values

Functions return a single value. It’s a mathematical thing. This single value might contain an array, or a set of values. We might want to be able to easily parse to values (talk about splat in a second), but the bottom line is that function return a single value. Trying to return weird things like { obj1, obj2 } which is actually an abbreviation of { obj1: obj1, obj2: obj2 } create syntax anomalies which in turn makes the code less readable.

reduce the anomalies! stop adding more of them! On a side note, I never really understood why typeof and instanceof cannot be simply treated as functions. or why the are different from one another. inconsistencies is what makes any language dreadful. This is something I would have like fixed.

5. For (;;) => For (…in…) => forEach(function) => for (…of…)

So For…of is just like For…on, only it’s more useful as it actually return the iterable elements of an object and not all its elements (which might include functions, for example). we’re having a zillion of loop and iterations that one cannot deny that this is a money-pit and there’s never going to be a solution that makes everyone happy. And that’s ok – but why incorporate ALL the solutions in the language? it only makes it more complicated.

why can’t we simply say that object has an iterables property, returning an array of its iterables so “for (key,value in Object.iterables(map)) {}” would iterate over ONLY the relevant items and in each iteration key will be index and value will be the iterable object itself. there. problem solved without adding a new command.

We already have Object.keys, so it shouldn’t be a problem to add Object.values and Object.iterables.

6. Parameters default values

Avoiding the need to handle default values within the code is very nice, but it leaves the devil an opportunity to introduce hell when my default value is actually a function that runs… when?

This is one complexity I think we should avoid.

7. Splat, Spread, Splat and Handling named parameters

We’d like a feature that says – “hey, all these values should actually be part of an array” and vice versa – “hey, this object is actually is a bunch of separate variables”

Here comes splat – “” which is an ok idea. so why can’t we simply have the other way around

  function myFunc (...numbers) {

  return number[2];


myFunc (1,2,3); // return 3
function myFunc (values..., ...other) {

  return (first + second + other[2]);

myFunction ({first:1, second:2}, 3,4,5) // return 8

in my example “values” doesn’t exists anywhere – it’s created and immediately breaks apart to it sub-elements.

In the current proposal “…” is actually used for both scenarios – either to collect variables and to spread them. I suggest the position will hint it action – …collect, spread… making it much more readable

It’s worth mentioning that whenever you invent a new element in a language someone is very likely to use it in a way you didn’t expect. For example, what will happen if I write source…target. well, you guessed it, it will break source to different elements and recollect back them to target.

8. Method definitions instead of function expressions in object literals to

the ability to write var obj = { myFunction () { … } } is pure laziness and breaks the consistency of the code. That’s bad.

9. Classes and Class extends

There’s ruling paradigm called “object oriented”. But javascript isn’t about it. JS is about manipulating JSON objects. JS is perfectly fine without classes. stop forcing it into something it’s not. All JS apps start small and fast but as soon as they become robust, they also become incredibly slow. So, people, please trying to make complicated JS. you’re killing our web!

Prototypical development means that whenever I get a JSON from the server I can easily apply function unto it – cat.prototype = catBehaviour. so now the cat JSON I got can cat.meow(). I don’t really need to create a new object for that. why do you insist to make thing more complicated?

I agree that the current prototype mechanism is slightly too complex but why not simply fix it?

10. From objects to Maps

Javascript’s Object suffers from having string keys. not only that but there’s an escape issue with them. so ES6 introduces a new element type just to solve the escaping issue. seriously? I’ve never bothered with that. If you go ahead and fix that (and not clear why not update the existing object) – why not have the keys as any object (you can flatten with JSON.stringify internally if you want)

11. New String and Array functions

Yes, with ES6 you can now have string.startsWith(). but, seriously who care?

you do realise that because you now decided to use this stupid function, you’ll no longer support ES5-only browsers, right?

and maybe this is what it really comes down to – Languages should have extremely long cycles – let’s say update a language every 5 years if not more, in order to give it time to propagate everywhere. Javascript is the most important language de-facto in the world today not because it’s a great language, rather than because everyone uses it. If you make it into something that not everyone uses – they’ll just keep using ES5. All those small nice-to-have function should be on external layer, or framework. Let’s call the language coreJS, and this will be scaffoldJS, and this can be easily updated, let’s say every 2 years. On top of that we can have libraries that every developer decided which to use – a reasonable update time for this should be 6 months.

js-core should be super-stable, super-consistent with itself, super-reliable, super-simple (and not super-easy) and super-fast. once we can have that, we can start talking about the external layers or silly features like startsWith or arrow functions.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: