Compare

Differences

Readable code

The fundamental concept behind babel is that the generated code must be close as possible to the original, retaining all the same formatting and readability.

Many other transpilers are just concerned with making the code work while babel is concerned with making sure it works and is readable at the same time.

For example, the following code:

var node = {
  type: type,

};

is generated to this with babel:

var _defineProperty = ...; // inline helper

var node = _defineProperty({
  type: type
}, "is" + type, true);

However the following is what Traceur generates:

var node = ($__0 = {}, Object.defineProperty($__0, "type", {
  value: type,
  configurable: true,
  enumerable: true,
  writable: true
}), Object.defineProperty($__0, "is" + type, {
  value: true,
  configurable: true,
  enumerable: true,
  writable: true
}), $__0);
return {};

As you can tell, it's not very pretty. Instead of mapping directly to a runtime, like other transpilers, babel maps directly to the equivalent ES5.

Sometimes there are little inline functions that babel needs. These are placed at the top of your file much like coffee-script does. If these bother you then you can use the optional runtime. We promise that these inline functions will never be significant and will always be used as little as possible.

Static analysis

Babel uses a lot of static analysis to simplify code as much as possible. Not many other transpilers do this, and those that do don't do it nearly as much as babel. This process is pretty intensive but it leads to higher quality code.

Spec compliancy

Babel prides itself on spec compliancy. We have excellent support for edgecases, something that many other transpilers suffer from, including Traceur. When you use babel you can be confident that when you turn it off and use your code in a full ES6 environment it'll just work.

Comparison to other transpilers

Features

Language Support