Recently, I had a friend approach me about using ES6 in production code and if I had had any trouble with it. Basically, he and his colleagues had run into issues debugging Coffeescript code so they were extremely leery about transpiling code and running in production. Here is my response:

When I first started writing ES6 code and transpiling it, I was a bit wary of debugging it but having written ES6 production code for over a year now, I’ve never had any serious problems. I totally don’t blame your coworker for being cautious though. To assure them, here’s a quick list:

  1. Source Maps - Chrome, FF, Safari, etc all support the concept of source maps; If you’re using webpack as a bundler, it can throw the source maps into the bundle and the browser will actually show the ​actual​ code that you wrote in the VM. So when I’m debugging a problem, I can see the code as I wrote it and not the transpiled code actually running.

  2. Babel - Babel prides itself on transpiling to actual, readable code. To test it out, checkout the Babel REPL where you can write ES6/7 code and see what it transpiles to. 90% of the time, it’s pretty readable JavaScript.

  3. The Future - ES6/ESNext is the future so writing it today will help you get a better grasp on it in the future when we no longer need transpilers. Many of the React libraries today are already being written in ES6/7 which really tells you that this is way things are heading. Facebook itself is using Babel to transpile its code and their code is downloaded millions of times a day.

  4. You can start off slow - You don’t have to go full blast ES6-all-the-things on all your code. It’s extremely easy to add a transpiler as build step so you can start off with just using ES6 modules (which I recommend) or something really easy such as just using let/const instead of var. That way you can test the code and if you run into any major problems, you can easily roll back to ES5.

Happy hacking.