As soon as I started attending the great London JS community meetups I immediately noticed mixed feelings around ES6.
It seems people is definitely looking forward to it becoming mainstream and they’re hungry for information about it, but at the same time they tend to stand clear of it in production.
Skepticism? Lack of success stories? maybe…
Hence, where ES6 is not supported the code we wrote is NOT what gets executed, and all the new cool features provided by ES6 become mere syntactical sugar that comes at a high potential cost:
- bugs\incompatibilities difficult to debug (as, again, the code we wrote is not the code that is executed)
I can imagine some pioneers’ smirk right now. Yes we can run our node app using the ES6 staged features, or even the features currently under development, but is it really a choice? Are we confident enough to run our production app on a beta (or even alpha depending on the maturity of the single feature we plan to toggle) ?
So, let’s consider the bright side for a minute…
Last time I checked the Node docs I read that some ES6 features are ALREADY supported with NO RUNTIME FLAG REQUIRED.
So, I would not go for yet another post on how to fake… ehm…”transpile” ES6 in your Node project, nor I would suggest you to enable all the WIP features.
I’d rather check what is possible to use AS TODAY in Node (version 4.1.0), and identify what are the benefits they come with.
Our trip is going to be long, so let’s start from listing what is available from the menu:
- Block scoping
- Typed arrays
- Binary and Octal literals
- Object Literal extensions
- New String methods
- Template strings
- Arrow functions
let & const
These new features are real game changers (even if you are a “var” aficionado).
While the memory allocated by var lives within the function scope, the memory allocated by let and const lives within the code block.
Syntax sugar aside, a much more granular memory management is VERY welcome.
Before ES6, each time a var was declared a memory location was kidnapped for the entire function scope.
Check the examples in the reference docs, but also consider this example using files and repeat with me: “yes, my app won’t be memory hungry anymore”.
Syntax sugar, no memory management nor performance benefits.
Where are the others?!
Read Part 2 to get some insight about ES6 collections!