Developing with more ES6 and less Babel

If you are one of those front-end developers who has adopted EcmaScript 6, the latest and greatest variant of JavaScript, and you’ve been using things like Babel to “transpile” it to make sure it is still compatible with older browsers, and you also utilise something like Webpack to bundle your assets together, this short post might be for you.

I’ve just been tinkering with Babel and came to a conclusion I actually almost don’t need it anymore for my development purposes. The reason I’m saying “almost” is because it’s still required for managing ES6 modules and dealing with React and JSX in particular. But the rest of the ES6 syntax I’ve adopted in my projects - so things like class, const, and let keywords, for-of loops, arrow functions, destructuring and rest operators - are now handled perfectly by a growing number of modern browsers, at least in their desktop flavours.

How does it look?

The .babelrc configuration I’ve been using is this:

Let me guess: typically, you’d opt for the es2015 Babel preset here to make sure anything that’s using ES6 syntax gets converted to ES5? By swapping it with the transform-es2015-modules-commonjs plugin, I’m basically saying: hey, Babel, don’t mess around with my ES6 syntax and only target those import and export statements as browsers cannot handle ES6 modules natively.

You obviously won’t need the preset for React, unless you’re actually using this library.

What is the end product?

And here’s a code sample from the bundle created by Webpack:

As you can see, there’s quite a few ES6 goodies here and none of them have been converted to ES5.

What ES6 browsers support it?

I am currently working on a React application that is full of forms and uses Fluxible for state management. I’ve been able to get Webpack to bundle the application’s JavaScript using the Babel configuration above and get it to happily run in:

  • Google Chrome (version 49 and newer)
  • Mozilla Firefox (version 45)
  • Safari Technology Preview (version 9.1.1)
  • Google Chrome Canary (version 52)
  • Opera (version 36)

And yes, both Chrome 49 and Firefox 45 are generally available at the moment and since both browsers are evergreen, it’s safe to assume their user base is already quite solid. I’m on OS X and currently don’t have access to Microsoft Edge but I wouldn’t be surprised if this one was also capable enough to be included in this list.

Why would you bother?

Yes, this is just an experiment, there’s no question about that. There are probably very few developers in the world who have luxury to ignore all the legacy browsers that don’t support ES6 - for the rest of us the 6-to-5 transpilation of production code is going to be an everyday reality for a long time to come.

Still, with a tool like Webpack, you probably have multiple, environment-specific asset bundling configurations anyway so adding another one that can be used for development purposes shouldn’t be very difficult (how about something like npm run start:es6?). The benefits are obvious: Babel compilation should be snappier and the size of the output file should be smaller as there’s simply less processing to be done. And being able to run ES6 code by a native interpreter provided by the browser should give you a slight performance gain as well.

Most of us develop in the latest iterations of Chrome or Firefox anyway so why not take advantage of the cutting edge features these browsers offer today?

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.