Tag Archives: ES6

Node, MVC Controllers and ECMAScript 2015

Long time readers of my blog will remember that I previously covered Node and MVC applications in a short tutorial series. At that point, I wrote the controllers and loader in ECMAScript 5.1. The code to load the controllers was this: The typical controller looked like this: That’s a lot of boilerplate code and it’s […]


How to write unit tests for ES6 code using NodeJS & Traceur

How to write unit tests for ES6 code using NodeJS & Traceur
ES6 is coming… Some of you may have heard about ES6 (ECMAScript 6), the next version of the ECMAScript language specifications. If you’re a web developer and haven’t heard about this, then it’s time to wake up and get some read on the Internet about it, cause it will revolutionize the way you write JavaScript, whether it’s for […]

Turn ES6 code into readable vanilla ES5 with source maps

benchmark fix lint errors 14 days ago
bin fix canCompile in readdirFilter in bin/6to5 util 2 days ago
lib/6to5 change useless self references to this 9 hours ago
test change test-appveyor to test-spec and add test-clean method to clean … 11 hours ago
.editorconfig first commit a month ago
.gitignore rename browserified polyfill to browser-polyfill – fixes #140 21 hours ago
.jshintignore fix lint errors a month ago
.jshintrc fix linting errors 8 days ago
.npmignore change behaviour of tests and browser testing/build 8 days ago
.travis.yml change gitter travis hook to always 2 days ago
CHANGELOG.md add 1.12.1 changelog 9 hours ago
FEATURES.md add async functions to features 9 hours ago
LICENSE first commit a month ago
MODULES.md add example usage for custom module formatters 9 days ago
Makefile change test-appveyor to test-spec and add test-clean method to clean … 11 hours ago
README.md add async functions to features 9 hours ago
appveyor.yml change test-appveyor to test-spec and add test-clean method to clean … 11 hours ago
package.json v1.12.1 10 hours ago
polyfill.js rename browserified polyfill to browser-polyfill – fixes #140 21 hours ago
register.js implement custom require ignore regex – closes #72 28 days ago


6to5 turns ES6 code into vanilla ES5, so you can use ES6 features today.

  • Readable – formatting is retained if possible so your generated code is as similar as possible.
  • Extensible – with a large range of plugins and browser support.
  • Losslesssource map support so you can debug your compiled code with ease.
  • Compact – maps directly to the equivalent ES5 with no runtime*.


It’s as easy as:

$ npm install -g 6to5

Table of Contents





Compile the file script.js and output it to stdout.

$ 6to5 script.js

Compile the file script.js and output it to script-compiled.js.

$ 6to5 script.js --out-file script-compiled.js

Compile the file script.js and output it to script-compiled.js and save a source map to script-compiled.js.map.

$ 6to5 script.js --source-maps --out-file script-compiled.js

Compile the file script.js and output it to script-compiled.js with a source map embedded in a comment at the bottom.

$ 6to5 script.js --source-maps-inline --out-file script-compiled.js

Compile the entire src directory and output it to the lib directory.

$ 6to5 src --out-dir lib

Compile the entire src directory and output it to the one concatenated file.

$ 6to5 src --out-file script-compiled.js

Pipe a file in via stdin and output it to script-compiled.js

$ 6to5 --out-file script-compiled.js < script.js


Launch a repl.

$ 6to5-node

Evaluate code.

$ 6to5-node -e "class Test { }"

Compile and run test.js.

$ 6to5-node test


var to5 = require("6to5");

var result = to5.transform("code();", options);

to5.transformFileSync("filename.js", options).code;

to5.transformFile("filename.js", options, function (err, result) {

  // Filename for use in errors etc.
  // Default: "unknown"
  filename: "filename",

  // List of transformers to EXCLUDE.
  // Run `6to5 --help` to see a full list of transformers.
  blacklist: [],

  // List of transformers to ONLY use.
  // Run `6to5 --help` to see a full list of transformers.
  whitelist: [],

  // Module formatter to use
  // Run `6to5 --help` to see a full list of module formatters.
  // Default: "common"
  modules: "common",

  // If truthy, adds a `map` property to returned output.
  // If set to "inline", a comment with a sourceMappingURL directive is added to
  // the bottom of the returned code.
  // Default: false
  sourceMap: true,

  // Set `file` on returned source map.
  // Default: `filename` option.
  sourceMapName: "filename",

  // Set `sources[0]` on returned source map.
  // Default: `filename` option.
  sourceFileName: "filename",

  // Optionally replace all 6to5 helper declarations with a referenece to this
  // variable. If set to `true` then the default namespace is used "to5Runtime".
  // Default: false
  runtime: true

Require hook

All subsequent files required by node with the extensions .es6 and .js will be transformed by 6to5. The polyfill specified in Polyfill is also required.


NOTE: By default all requires to node_modules will be ignored. You can override this by passing an ignore regex via:

  // This will override `node_modules` ignoring - you can alternatively pass
  // a regex
  ignore: false
  // Optional ignore regex - if any filenames **do** match this regex then they
  // aren't compiled
  ignore: /regex/,

  // Optional only regex - if any filenames **don't** match this regex then they
  // aren't compiled
  only: /my_es6_folder/,

  // See options above for usage
  whitelist: [],
  blacklist: [],

  // This will remove the currently hooked extensions of .es6 and .js so you'll
  // have to add them back if you want them to be used again.
  extensions: [".js", ".es6"]


A browser version of 6to5 is available from browser.js inside the 6to5 directory in an npm release.


While it’s not recommended for serious use, when the browser version is included all scripts with the typetext/ecmascript-6 and text/6to5 are automatically compiled and ran.

For example:

<script src="node_modules/6to5/browser.js"></script>
<script type="text/6to5">
class Test {
  test() {
    return "test";

var test = new Test;


You can build a browser version of the compiler by running the following in the 6to5 directory:

$ make build

This will output the files dist/6to5.js and dist/6to5.min.js.


to5.transform("class Test {}").code;


To test 6to5 in your browser run:

$ make test-browser

And open test/browser.html in your browser if it doesn’t open automatically.


See Modules – Common for documentation on the default module formatting.

Alternatively see Modules for all other supported module formatting types.



A polyfill is required for for-of functionality that implements Symbol and addsprototype[Symbol.iterator] behaviour to built-ins. Using the polyfills specified in polyfill suffices.


Built-in classes such as Date, Array and DOM cannot be subclassed due to limitations in ES5 implementations.

If you’re inheriting from a class then static properties are inherited from it via __proto__, this is widely supported but you may run into problems with much older browsers.

NOTE: __proto__ is not supported on IE <= 9 so static properties will not be inherited. A possible workaround is to use super();:

class Foo {
  static foo() {


class Bar extends Foo {
  static foo() {


The regenerator runtime and an ES6 polyfill are required in order for generators to work.


6to5 includes a polyfill that includes the regenerator runtime and the es6-shim and es6-symbol polyfills.




Available from the browser-polyfill.js file within the 6to5 directory of an npm release.

Optional runtime

6to5 has a few helper functions that’ll be placed at the top of the generated code if needed so it’s not inlined multiple times throughout that file. This may become an issue if you have multiple files, especially when you’re sending them to the browser. gzip alleviates most of this concern but it’s still not ideal.

You can tell 6to5 to not place any declarations at the top of your files and instead just point them to a reference contained within the runtime.

Simply use the following option if you’re using the Node API:

  runtime: true

or the following flag if you’re using the CLI:

$ 6to5 --runtime

Then just include the runtime before your generated code.

Getting the runtime

You can get the runtime via either:

$ 6to5-runtime



or from an npm release in runtime.js from the 6to5 directory.

Customising namespace

You can also customise the runtime namespace by passing an optional namespace argument:

$ 6to5-runtime myCustomNamespace

See Options – runtime for documentation on changing the reference in generated code.


6to5 has built-in support for React v0.12. Tags are automatically transformed to their equivalentReact.createElement(...) and displayName is automatically inferred and added to allReact.createClass calls.

To disable this behaviour add react to your blacklist.



The fundamental concept behind 6to5 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 6to5 is concerned with making sure it works and is readable at the same time.

For example, given the following array comprehension:

var seattlers = [for (c of customers) if (c.city == "Seattle") { name: c.name, age: c.age }];

is generated to the following with 6to5:

var seattlers = customers.filter(function (c) {
  return c.city == "Seattle";
}).map(function (c) {
  return {
    name: c.name,
    age: c.age

The following is what Traceur generates:

var seattlers = (function() {
  var c;
  var $__20 = 0,
      $__21 = [];
  for (var $__22 = customers[$traceurRuntime.toProperty(Symbol.iterator)](),
      $__23; !($__23 = $__22.next()).done; ) {
    c = $__23.value;
    if (c.city == "Seattle")
      $traceurRuntime.setProperty($__21, $__20++, {
        name: c.name,
        age: c.age
  return $__21;

As you can tell, it’s not very pretty, unreadable even. Instead of mapping directly to a runtime, like other transpilers, 6to5 maps directly to the equivalent ES5.

I’m not saying 6to5 is for everyone or even suited for everything. Traceur is better suited if you’d like a full ES6 environment with polyfills and all.

Comparison to other transpilers

6to5 Traceur esnext es6now es6-transpiler jstransform
No runtime
Source maps
No compiler global pollution
Arrow functions
Computed property names
Default parameters
Let scoping
Property method assignment
Property name shorthand
Rest parameters
Template literals
Unicode regex


Traceur requires quite a bulky runtime (~75KB) and produces quite verbose code. While this can be trimmed down by selectively building the runtime, it’s an unneccesary step when a runtime can be eliminated entirely.


es6now doesn’t output sourcemaps. This is cited as a positive as line-to-line mapping is the goal. This however obviously doesn’t retain column mapping resulting in the output code not being very pleasant.


The es6-transpiler compiler requires shims to operate which pollutes the global scope resulting in possible collisions.

es6-transpiler maps line-by-line, just like es6now, this results in the same issues such as lack of column information and unpleasant code output.

Transit for JavaScript



Transit is a data format and a set of libraries for conveying values between applications written in different languages. This library provides support for marshalling Transit data to/from JavaScript. transit-js will work with any ECMAScript-262 Edition 3 or newer JavaScript implementation provided that a JSON module that supplies parse and stringify methods is present. transit-js does not currently support encoding toMessagePack.

This implementation’s major.minor version number corresponds to the version of the Transit specification it supports.

NOTE: Transit is a work in progress and may evolve based on feedback. As a result, while Transit is a great option for transferring data between applications, it should not yet be used for storing data durably over time. This recommendation will change when the specification is complete.

Releases and Dependency Information


You can include either the release (10K gzipped) or development build of transit-js on your webpage. We also provide Require.js compatible release and dev builds.


transit-js is released to npm. Add transit-js to your package.json dependencies:

  "dependencies": {
    "transit-js": "0.8.746"


You can also include transit-js in your bower.json dependencies:

  "dependencies": {
    "transit-js": "0.8.746"


Maven dependency information:



Comprehensive documentation can be found here.


transit-js supports the conveyance of semantically rich and extensible data between heterogenous software systems whose components include JavaScript servers and clients.

Beyond JSON

The Transit rationale covers many of the reasons to put aside the limitations of JSON. As with the other Transit implementations, transit-js supports conveying a larger range of scalar and non-scalar values than permitted by JSON. Of these types, the transit-js handling of the map representation is the most novel from the perspective of a JavaScript applications developer.

Transit Maps

Transit representations of maps are decoded by transit-js into a high performance data structure that largely mirrors the ECMAScript Edition 6 Map data type. Doing so allows natural indexing of data using common scalars like 64 bit integers and dates without requiring the out of band application logic often encountered in systems that marshal JSON.

The adaptive implementation of transit-js maps delivers performance comparable to plain JavaScript objects and native ES6 Map implementations.


Please see the Getting Started page. For an interactive guide check out the tour.

From the browser transit-js is available at the top level:

var t = transit;

function roundtrip(x) {
  var r = t.reader("json"),
      w = t.writer("json");
  return r.read(w.write(x));

function testRoundtrip() {
  var arr1 = ["red", "green", "blue"],
      arr2 = ["apple", "pear", "grape"],
      data = t.map();
  data.set(t.integer(1), arr1);
  data.set(t.integer(2), arr2);
  return t.equals(data, roundtrip(data));

From Node.js you must require transit-js (assuming you’ve included it in your project dependencies):

var t = require("transit-js");

function roundtrip(x) {
  var r = t.reader("json"),
      w = t.writer("json");
  return r.read(w.write(x));

function testRoundtrip() {
  var arr1 = ["red", "green", "blue"],
      arr2 = ["apple", "pear", "grape"],
      data = t.map();
  data.set(t.integer(1), arr1);
  data.set(t.integer(2), arr2);
  return t.equals(data, roundtrip(data));

Default Type Mapping


  • t = transit
Transit type Write accepts Read returns
null null null
string String String
boolean Boolean Boolean
integer Number, t.integer Number, t.integer
decimal Number Number
keyword t.keyword t.keyword
symbol t.symbol t.symbol
big integer t.bigInt t.bigInt
big decimal t.bigDec t.bigDec
bytes Buffer, Uint8Array, t.tagged Buffer, Uint8Array, t.tagged
time Date Date
uri t.uri t.uri
uuid t.uuid t.uuid
char String String
array Array Array
set t.set t.set
map t.map t.map
link t.link t.link
cmap t.map t.map


This library is open source, developed internally by Cognitect. We welcome discussions of potential problems and enhancement suggestions on the transit-format mailing list. Issues can be filed using GitHubissues for this project. Because transit is incorporated into products and client projects, we prefer to do development internally and are not accepting pull requests or patches.



Building and testing transit-js requires Node.js. Install the project’s additional development dependencies with the following command from the repo directory:


In order to build transit-js for ClojureScript, Maven must be installed.

Running the tests


In order to run the bin/verify tests from transit-clj, you must first build the production Node.js build:




The build version is automatically incremented. To determine the current build version:


Build for Node.js


Build for Browser


Building the documentaiton


Build JAR for ClojureScript

Assuming you have a JDK and Maven installed, the following will install a JAR suitable for use from ClojureScript into your local Maven repository.


Copyright and License

Copyright © 2014 Cognitect

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at


Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

ES6 in Angular 2.0

In this talk, Erik explains what additional features of ES6 will be used in Angular 2.0 and how they’ll work with Traceur.

“Virtual Machines, JavaScript and Assembler” Keynote

How does the pervasiveness of JavaScript on the client change how we architect applications? We can create hundreds virtual machines in the cloud, but we are using the millions of visual machines that visit our sites every day?

Suddenly we are scripting against thousands of Virtual Machines from the command line while creating things today with JavaScript in the browser that were impossible yesterday. LiveScript becomes JavaScript becomes ES6 and now we’re compiling C++ to JavaScript.

Learning ES6 as a Community

The current schedule for the completion of ECMAScript 6, the next version of JavaScript, dictates that the language specification be finished by the end of the second quarter of 2014. Most browser vendors have made informal commitments to have ES6 implemented by the end of the year. Over the last couple years, we’ve heard a lot about the many new features in ES6, along with the debate (and bickering) which has gone into its design. ES6 stands to be the most substantial change to JavaScript since ES4 (which didn’t work out that great, as most users of ES5 are aware).

With this much change comes a lot of complexity. Many of the new features (like generators or proxies) are powerful, basic abstractions, and as such combine in complex (and potentially unexpected) ways. In many ways, a new version of JavaScript offers the possibility of returning us to the wild frontier days that JavaScript only recently left behind, with library and framework vendors each choosing their own combinations of features to build powerful (and complicated) architectures that can really only be understood on their own terms.

However, as a community we’ve learned a lot over the last half decade or so, and I think we’ve learned how to tackle this problem head on. I’ve come up with a strategy that I think would allow us to collaboratively get to a good place with ES6 relatively quickly. I’ll go over this strategy and point to the areas where I think we ought to spend the most time to get the most positive results.

It’s up to us — as a community of designers, developers, and implementors — to get out in front and provide tooling, documentation, and training that will help ourselves use these new features effectively, before folklore and superstition start to take root. And it’s important to remember that finishing ES6 frees the JavaScript standards bodies to concentrate on ES7, where our feedback from using ES6 will help them refine what comes next.