#node 4

How are you holding up, Rugan? 'NodeContext: relieved after a fight, checking up on his companion'

Brem: Did I see you drawing something earlier?

Garias: So? Can do a better job than that ponce you sold.

Brem: Huh. Keep it up, little brother - might be I can sell you some day.

Garias: Aw.

Before ES6, the most you could do to optimize JavaScript code efficiency was to reduce steps in algorthims and try to store less data. Though due to JavaScripts dynamic scripted nature, memory management is imprecise. So ArrayBuffers were introduced which store a fixed length of raw binary data. And since the length is fixed, it is possible to calculate memory usage for that data precisely. In a browser this level of optmization would very rarely be required, but with server side JavaScript code could have a few applications because performance can matter a lot there. It is also cool that JavaScript is probably the only scripting language that provides optional memory management (it is usually only available in low level languages like C).

As always, with performance there is a trade off in implementation difficulty; ArrayBuffers cannot be accessed directly due to performance reasons. So Typed Arrays provide a way of accessing an ArrayBuffer which stores fixed length raw binary data. DataViews can also be used to provide more basic access.

The use cases for Typed Arrays are generally highly specific to an application or server, but here is a simple example that demonstrates the memory difference of using regular Arrays vs Typed Arrays for creating an integer array. Creating a Typed Array:

var largeArray = new Int16Array(10000000); console.log('Typed Array heap used: ', process.memoryUsage().heapUsed); // Typed Array heap used: 4376184 (your number may differ)

Creating a regular Array:

var largeArray = new Array(10000000); console.log('Regular Array heap used:', process.memoryUsage().heapUsed); // Regular Array heap used: 84373912 (your number may differ)

The memory difference occurs because the Typed Array is given only 16 bits to store each number while the other Array will default to the current JS environments Number storage length of 64 bits. Finally, since this feature relies on integrating with the surrounding OS environment at some point, there is no way to polyfill it.

This is part of a series of posts on new ES6 features introduced as of Node 4.0 (Although const has been in Node.js for awhile).

Generators are functions that can be exited then reentered. When a generator function is called, an Iterator object is returned. Then each time that iterators next function is called, the original function is executed until the yield statement:

var incrementor = function*() { var index = 0; while(index < 2) { yield index += 1; } }; var increment = incrementor(); console.log(increment.next().value); // 0 console.log(increment.next().value); // 1 console.log(increment.next().value); // undefined console.log(increment.next().done); // true

There is no way to pause one function then restart it because JavaScript is single threaded. So the only solution that does not do dynamic source code rewrites is to collect the results and display them one by one:

var generator = function(callback) { var results = [], nextIncrement = -1; // Collect the results callback(function(result) { results.push(result); }); // Return the collected result at the increment var next = function() { nextIncrement += 1; return { value: results[nextIncrement], done: nextIncrement >= results.length }; }; return function() { return { next: next }; }; }; var incrementor = generator(function(_yield) { var index = 0; while(index < 2) { _yield(index += 1); } }); var increment = incrementor(); console.log(increment.next().value); // 0 console.log(increment.next().value); // 1 console.log(increment.next().value); // undefined console.log(increment.next().done); // true

This is part of a series of posts on new ES6 features introduced as of Node 4.0.

Let provides an alternative to var that only applies to the current block of code. This helps prevent many variable overriding issues without having to use any kind of wrapper function. Below the timer reflects what would happen with an asynchronous call like one to an API:

for (var i = 1; i <= 5; i += 1) { var j = i; setTimeout(function() { console.log(j); }, 1); }// 5\n5\n5\n5\n5

vs let:

for (var i = 1; i <= 5; i += 1) { let j = i; setTimeout(function() { console.log(j); }, 1); }// 1\n2\n3\n4\n5

JavaScript does not create any state for blocks. So the only way to simulate let is to use var within self executing function expressions:

for (var i = 1; i <= 5; i += 1) { (function() { var j = i; setTimeout(function() { console.log(j); }, 1); })(); }// 1\n2\n3\n4\n5

Let statements also have a bunch of other advantages like throwing errors when a duplicate let statement is used. You can read about these issues here.

This is part of a series of posts on new ES6 features introduced as of Node 4.0.

Symbols are a new JavaScript type used to create unchangeable unique values that can be used for object properties. This is useful when a property needs to be implemented on an object and that property should not be overridden and should not accidentally override new methods introduced by libraries or new language versions. Here is an example use case. Anyways, this post will focus on a pre ES6 implementation. Firstly, in ES6:

var test1 = Symbol('test1'), test2 = Symbol('test1'); console.log(test1);// Symbol(test1) console.log(Symbol('foo') === Symbol('foo'));// false var object = {}; object[test1] = 'value1'; object[test2] = 'value2'; console.log(object[test1], object[test2])// "value1" "value2"

Note that the string passed in is just a descriptive value for telling which symbol is which so symbols can be differentiated when printed out. It is not used for any other purpose. Symbols can also be created globally on the global symbol registry by using Symbol.for() and retrieved using that or Symbol.keyFor():

var symbolForTest = function() { return Symbol.for('test2'); }; var test2 = symbolForTest(); console.log(Symbol.for('test2'));// "Symbol(test2)"" console.log(Symbol.keyFor(test2));// "test2"

Here is a close pre ES6 version:

var test1 = Symbol2('test1'), test2 = Symbol2('test3'); console.log(test1.description());// Symbol(test1) console.log(Symbol2('foo') === Symbol2('foo'));// false var object = {}; object[test1] = 'value1'; object[test2] = 'value2'; console.log(object[test1], object[test2])// "value1" "value2" // Using the global symbol registry var symbolForTest = function() { return Symbol2.for('test2'); }; var test2 = symbolForTest(); console.log(Symbol2.for('test2').description());// "Symbol(test2)"" console.log(Symbol2.keyFor(test2));// "test2"

The toString method is used automatically by JS when an object is passed in as a property for another object, so the toString here has to return something that is very unlikely to be overridden (But it cannot gauranttee that unlike the real Symbol). Also, since the toString is already used for that purpose, a separate description method was also needed. Here is the implementation:

var Symbol2 = (function() { var symbolIncrement = 0, propertyPrefix = 'symbol2_custom_override_property_', globalSymbolRegistry = {}; var _Symbol = function(description) { var _Symbol = function(increment) { var self = {}; self.description = function() { return 'Symbol(' + description + ')'; } self.toString = function() { return propertyPrefix + increment; }; return self; }; return _Symbol(symbolIncrement += 1); }; _Symbol.for = function(key) { if (globalSymbolRegistry[key]) { return globalSymbolRegistry[key]; } globalSymbolRegistry[key] = _Symbol(key); return globalSymbolRegistry[key]; }; _Symbol.keyFor = function(symbol) { for (key in globalSymbolRegistry) { if (globalSymbolRegistry[key].toString() === symbol.toString()) { return key; } } // return undefined when not found }; return _Symbol; })();

Since this is already complex, this implementation does not implement the large number of special cases with symbols, like certain type conversions rules or how they do not appear in for in loops. You can read about those here.

This is part of a series of posts on new ES6 features introduced as of Node 4.0.