ES5 vs ES6 Round 2

On the previous post we looked at some of the important aspects of what is going to come in ES6, but we didn’t cover other features that the spec will bring to the table. So bring your best opinion as a weapon in order to figure out if ES6 is going to be a better change for the web programming nowadays.


Man holding a microphone

Iterators and for of

ES6 introduces a layer of abstraction in order to navigate at each one of the items of a collection. With an iterator you have a common API for item retrieval on any kind of type you may have,either strings and objects mixed themselves or items created dynamically,etc.

1
2
3
4
5
6
7
8
9
10
11
let word ='';
let letters=['a','b','c','d','e'];
let iterator =letters.**values**();
let next=iterator.**next()**;
while(!next.done){
word+=next.value;
next=iterator.next();
}
console.log(word); // prints 'abcde'

In the previous example we see that the iterator is being retrieved by the values() function, and a next() function is a flag that will tell us if we reach the end of the array.

There is also a new keyword which internally uses the iterator: the for of. These keyword allows us to access directly to each one of the elements of a collection without worring about the next() and also accessing the element by its index, which is what the for in syntax does.

1
2
3
4
5
6
7
8
let word ='';
let letters=['a','b','c','d','e'];
**for**(letter **of **letters){
word+=letter;
}
document.write(word); // writes'abcde'

This new features make the code for manipulating collections very clear and also there is no need for have external libraries for doing this kind of operations. Also you can create your iterator if there is something complex that you want to make to the collection.

This time I would say that ES6 wins on this aspect as doing this kind of stuff in ES5 is more complex.

Promises



Getting into the world of asynchronous programming is a pain.Because of that we require some external libraries in order to have better control of the processing and the error handling that they produce.

ES6 provides a new Promise object in order to handle this situations, in which syntax is similar to most of the promise libraries out there.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var promise= new **Promise**(function(resolve,reject){
var bigOperationResults=[1,2,3]; // Some results retrieved for a heavy operation.
if(someOperationIsTrue()) {
**resolve**(bigOperationResults);
}
else{
**reject**(Error('The operation failed.'))
}
});
promise.**then**(function(data){
console.log(data);
},function(error){
console.log(error.message);
});

The promise object wraps the whole asynchronous operation within a function that provides a resolve() and reject() functions to succeed or fail the promise.Then in the response handling block we have a similar syntax for libraries that provide promise functionality.

This battle also ES6 wins as the web applications nowadays require a bunch of async processing when communicating with the backend via web service calls and promises provide nice constructs to take the job.

Modules


Truck transport container to warehouse near sea

Tons of Javascript files and no way to organize them. That’s when modules come in play and whether this feature will take a long time to come due to constant changes and that AMD and CommonJS are very consolidated, is important to look at what ES6 will offer.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
**export class** Car{
constructor(model){
this._model=model;
}
get model(){
**return** this._model;
}
accelerate(){
** return** '${this._model} is accelerating';
}
}
**import** {Car} from './libraries/car'; // _assuming the class is on car.js
_
var car =new Car("MyCarModel");
car.accelerate();

Here you can see that the class has an special keyword, ‘export’ which makes it ‘loadable’ from other files, by using the keyword ‘import’ and a curly brace syntax for the object that we want to retrieve along with its path.

Im going to bet here for the already consolidated libraries like Require.js because they makes things simpler and because we have to wait a long time until the browsers start to implement this functionality.

IMHO


Opposition

In my point of view, the Javascript language has been evolving pretty quickly and there has not been any chance to enhance and organize some of the things that this language requires nowadays,and that is what ES6 is looking for.

By now, we should all know the disadvantages that the language provides and we have learned how to live with them.The community also created libraries to overcome this gaps, which those were useful for ECMA as it took its inspiration of.

Also, from my perspective, I dont think is time for take ES6 for shipping products, because by now it’s just seeing the light and some browsers doesn’t fully adapt its features, but I think is good that some tools like Traceur come to the market so we can start playing with ES6 and be prepared for the big come.

Now that the things are more in place, not like in the past, I just hope that the language gets a good pimp for the sake of the web development world, as it keeps getting bigger and demandant.

Thanks for reading!!

 

Share