Studying for ES6

Been busy this week, mostly because I had to catch up with lost time at work (demmet internet). My first rewrite has been deployed to the test server and is subject to scrutiny (yey!). Now chilling (screw thesis) and downloading a few anime. And when I mean chilling, I read up on the latest in programming, JavaScript of course, and that means screwing around with ES6.

What's ES6?

So for those of you who don't know what ES6 is, it's the 6th revision of the ECMAScript Standard, the standard that governs ES-compatible scripts. To tell where you are in the ES world, the JS we all know and hate is from ES3. ES4 was dropped due to being an incompatible overhaul. ES5 was more of native object extension, with forEach, map, reduce and Object.keys in the spotlight.

ES6 is more of a syntax and functionality extension. Foreigners like array comprehension, Python-like module system (import from as), and even lambdas are now in the works (and yes, they are multi-line lambdas, thank you!). And being exposed to a bit of Python at work on a regular basis, ES6 seems to bridge me between worlds, minus the braces of course.

So what of it?

ES6 sports a lot of conveniences that versions up to ES5 didn't provide. For instance, block-scoped variables would mean meaningful blocks, especially for for and for-in loops. Lambdas will make callback and Promises a bit less ceremonious by dumping out the function keyword. And there's many more.

But what I am interested in particular is the module system of ES6. At the moment, we use RequireJS which I have to admit is crazy, especially in the configuration. Browserify requires a lot of dev-time tooling, which can be hard to setup for other devs (yes, it's so hard to remember npm install; bower install but they remember pip install -r requirements.txt).

The Challenge

I want to write in ES6 to check the feel. I have a workmate that already commented in our product that stuff would have been easier if there's ES6. This makes it all the more interesting. Checking up on our tooling, a library we use is already written in ES6, just compiled to ES5 for compatibility. So I thought to myself, it's entirely possible to write in ES6 now.

So what I did today was checking our tooling, if it's possible to use them in an ES6 environment, or if not, formulate a plan where I will buid the tools needed in order to have ES6 in our code. So far... it's been one hell of a read.

The Catch

The details are still fuzzy. Still have to read the specification. Before that, here's my questions:

• How does native modules work? Does it download a script, parse it's dependencies, download these dependencies, parse dependencies, and so on until the entire dependency tree is traversed, then execute leaf to root?

• Does this mean it's a hit to the server? Modules are individually written pieces of JS placed in files.

• I assume they are scoped rather than injected into the global space, but are they really?

• What advantage does it provide when scripts are just concatenated before deploy? Does this mean the whole module syntax will just end up as a configuration for build-time compile and never see the daylight in deployed code?

• Today we have transpilers that convert ES6 syntax to compatible ES5. However, what if a certain library uses eval or new Function as part of its operations? Does that mean the code to be executed should not be ES6?

• What happens to libraries that use the AMD/UMD/CommonJS module definition? Will they still work? Or will they break? For all I know, native modules export like CommonJS, but use import from as instead of require, which essentially makes libraries useless.

Conclusion

Still very interested in the concept of ES6. AFAIK, the final standard will be released mid-2015. By then, browsers should have 80% coverage, especially in Chrome and Firefox. I wouldn't want to be behind in the language I specialize, so yeah, knowledge is power and learning will get me that power. :D