Frontend development can be extremely complex and frustrating if you come from a python backend background (and probably even if you've been a frontend coder all your life :)

This is partially caused by the different staps that are taken when building / transpiling local, structured ES6 code into distributable assets. This results in totally different code running in the browser than what you originally wrote.

With EmberJS some of these steps are

  • combining the routes/controllers/templates/components (pod) structure for the app and all dependencies
  • managing modules and imports
  • combining all individual files into two large js files (vendor.js, app.js)
  • compression and minification
  • transpiling javascript features that aren't universally supported across browsers. This includes most of the ES6 features

ES6 (also called ES2015) provides fixes and alternatives for many of javascripts historical quirks such as strange object/hash behaviour (hasOwnProperty?!), strange counter-intuitive for-loops, missing classes, 'this' madness and much more. For me it makes javascript almost usable.

However, it still has to be transpiled to ES5 compatible code since not all browsers yet support ES6. This means that a simple piece of code like

        for(let l of something) {
            // something
        }

gets translated into something bizar like

            var _iteratorNormalCompletion = true;
            var _didIteratorError = false;
            var _iteratorError = undefined;

            try {
                for (var _iterator = something[Symbol.iterator](), _step; !(_iteratorNormalCompletion = (_step = _iterator.next()).done); _iteratorNormalCompletion = true) {
                    var l = _step.value;

                    // something
                }
            } catch (err) {
                _didIteratorError = true;
                _iteratorError = err;
            } finally {
                try {
                    if (!_iteratorNormalCompletion && _iterator['return']) {
                        _iterator['return']();
                    }
                } finally {
                    if (_didIteratorError) {
                        throw _iteratorError;
                    }
                }
            }

Generator functions with yield are even worse - one big incomprehensible and undebuggable switch statement.

Wouldn't it be great to, during development, just view and step through your almost-original code? With recent Chrome and Firefox releases this should be possible since they support most of ES6 already. But it would mean disabling certain parts of ES6 transpilation. Disabling everything is not an option, you will still need module transpilation, for example.

With EmberJS this can be achieved by, in a certain environment setting, blacklisting certain babel transforms in ember-cli-build.js. Your ember-cli-build.js should look something like this:

var EmberApp = require('ember-cli/lib/broccoli/ember-app');

module.exports = function(defaults) {
  var config = {
    "ember-cli-qunit": {
        useLintTree: true
    },
/* etc */ babel: { includePolyfill: true }, sourcemaps: { enabled: true, extensions: ['js'] } };
// blacklist certain transforms if in es6dev environment if(EmberApp.env() === "es6dev") { config.babel.blacklist = [ 'es6.forOf', 'regenerator', 'es6.arrowFunctions', 'es6.constants', 'es6.blockScoping', 'es6.templateLiterals']; } var app = new EmberApp(defaults, config); // do stuff return app.toTree();

Also update your config/environment.js to support an "es6dev" environment.

Now start ember with --environment=es6dev and ES6 constructs like generator functions, for-of, arrow functions and more won't be transpiled!

 

 

Last updated April 20, 2016, 7:33 p.m. | es2015 ember ember-cli es6 babel emberjs
comments powered by Disqus