The JavaScript blog.


ES6 transpilers estree

Transpilers: This Time It's Different

Posted on .

JavaScript is changing. It's not just the wealth of great libraries that forces us to constantly learn new techniques, but the development of the language specification itself. If you're excited about ES6 modules, arrow functions, template strings, or ES6 classes, then you're probably already using these technologies. We don't have to wait years for the major browser manufacturers to keep up because we have transpilers.

One reason many of us stuck with JavaScript rather than CoffeeScript and TypeScript is we wanted to keep the stack simple. Adding extra layers can cause issues for debugging, and learning new languages takes time. However, polyfills and projects like 6to5 (now Babel) let us work with emerging standards. Some of these language changes help us deal with the way we now use JavaScript, so I'd argue that ES7's await proposal and generators could help us to be more productive for asynchronous programming, and classes will help design more maintainable projects.

For example: I find Browserify helps me structure client-side code to be more reusable and easier to navigate. And, during development my browsers show the right file and line number for errors, because I use Source Maps. When I read about 6to5 being renamed to Babel the thing that interested me the most was ESTree:

Recently a number of people from Mozilla, Esprima, The jQuery Foundation, Acorn, 6to5, ESLint, and others have come together to create ESTree, a standard upon which all parser and transpiler tooling will be based on.

The ESTree Spec could be what takes the pain away from our constant quest to use the latest and greatest standards without having to wait for legacy browsers to catch up. Now we can take transpilers seriously:

We want for 6to5 to solve the transpiler story. If the community could rally around a tool that provides a solid foundation for dealing with a lot of shared issues then we’ll all be much better off.

Babel will continue to serve as a JavaScript transpiler for using the very latest standards, but will also begin to open up its API for other tools. Anyone who has worked on the project internally knows that Babel is incredibly easy to work with.

This time it's different: it's no longer about browsers and instead about how we choose to write JavaScript. We won't know what works until we start to use the new standards for serious projects, but now there are more reasons than ever to be an early adopter.