The Importance of `import` and `export`

Ben Newman (Meteor)
EmpireNode 2015

{ github,
  twitter,
  instagram,
  facebook
}.com/benjamn


export * from
  "http://benjamn.github.io/empirenode-2015"

Let's talk about `eval`

The mere presence of eval in a function thwarts almost any kind of optimization or static analysis.

Most JavaScript programmers I know consider eval more harmful than goto.

Heaven forbid a snippet of user input should end up in one of those strings!

There's no good way for transpilers to support eval, so they basically don't even try.

As a community we have decided it is never acceptable to use `eval` when there is any other way to solve the problem.

And yet we use `eval` all the time.

Of course it hides behind many different abstractions:

<script src="http://..."></script>
<script>...</script>
new Function("...")()
require("vm").runInThisContext("...")
<a href="javascript:...">Click me!</a>
<input type="button" value="No, me!" onclick="..." />
setTimeout("...", 1000)

Nothing happens

unless first an `eval`.

Carl Sandburg

There is an `eval` in everything.

That's how the code gets in.

Leonard Cohen

There's no escaping `eval`

But it can be tamed, and Node does this better than any other JavaScript platform, thanks to CommonJS.

CommonJS is great

All your code runs in a specific module scope.
Any given module runs at most once, the first time you require it.
Module source code is loaded from static files, according to simple rules.
Module load order emerges naturally.
Module exports remain distinct.
Global scope stays clean.

Once your code starts running, you get to make all the decisions about what additional code is allowed to run, and when.

Has CommonJS won?

From the perspective of Node and NPM,
it certainly seems so.

But what about code running in browsers?

Is "winning" really all we care about?

Can we do better?

What's wrong with CommonJS?

Problem 1: How code is loaded

Node has it easy. Just ask the file system!

Not so simple or efficient to do hundreds of synchronous HTTP requests over the network.

Instead, there has to be a way to deliver bundles of code to the client.*

* Bundling woes deserve a talk of their own.
Listen to Trek Glowacki.

Problem 2: Dependency cycles

// wrap.js
var log = require("./log").log;

exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);

Problem 2: Dependency cycles

// wrap.js
var log = require("./log").log;

exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

What's wrong here?

Problem 2: Dependency cycles

// wrap.js
var log = require("./log").log;

exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Can we fix it?

Problem 2: Dependency cycles

// wrap.js


exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Can we fix it?

Problem 2: Dependency cycles

// wrap.js

exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};


exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Can we fix it?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};



exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Can we fix it?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Can we fix it?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Why does this work?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);




// main.js
var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Will it always work?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);



// main.js

var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Will it always work?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);


// main.js


var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Will it always work?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);

// main.js



var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Will it always work?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);

// main.js
var log = require("./log");


var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Will it always work?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);

// main.js
var log = require("./log");
log("STARTING SERVER");

var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

Will it always work?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);

// main.js
var log = require("./log");
log("STARTING SERVER");

var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

What about now?

Problem 2: Dependency cycles

// wrap.js
exports.deferred = function (fn) {
  return function wrapper() {
    setTimeout(fn, 0);
  };
};

var log = require("./log").log;

exports.logged = function (fn) {
  return function wrapper(...args) {
    log("calling the function");
    return fn.apply(this, args);
  };
};

// log.js
var wrap = require("./wrap");

exports.log = wrap.deferred(
  function (...messages) {...}
);

// main.js
var log = require("./log");
log("STARTING SERVER");

var wrap = require("./wrap");
require("http").createServer(
  wrap.logged((req, res) => {...})
).listen(8080);

What happens when the first request comes in?

Problem 2: Dependency cycles

Not forbidden!
Relatively simple, deterministic resolution policy.
Highly sensitive to load order, which is beyond the control of the modules participating in the cycle.
Example from the React codebase where we gave up on modularity in the name of preventing cycles.
Cycles can be useful.
Cycles should work.

Problem 3: `exports` vs. `module.exports`

Immediately returning a partially populated exports object in case of circular dependencies would work so much better if that exports object was guaranteed to become complete eventually.

But modules can change the very identity of exports by reassigning the module.exports property, rendering that partial exports object totally irrelevant.

Different modules that require the same module can end up with totally unrelated results!

Problem 4: Multiple exports

It's definitely nice that exports objects can have multiple properties.

But it's nearly impossible to determine whether a certain property is actually used.

Not a huge problem on the server, but client bundlers like Browserify and Webpack end up including tons of dead code.

Self-discipline?

Never assign to module.exports, unless you are certain your module has no (circular) dependencies.
Store references to imported exports objects: var a = require("a"); // Mostly safe. var foo = require("a").foo; // Dangerous! exports.good = function (arg) { return a.foo("good", arg); // Uses the latest value of a.foo. }; exports.bad = function (arg) { return foo("bad", arg); // Uses a stale value. };

There's nothing about CommonJS that helps you (or your teammates) keep this discipline.

CommonJS may be the most popular module system we have

But it's a shame that we're even talking about one module system winning a popularity contest.

Almost every other language avoids this contest entirely, by providing a built-in module system, and most of them do it with a special syntax.

A native module system...

eases cooperation between authors and consumers of libraries,
eliminates the need for each library to provide its own module-loading system,
regularizes the structure of applications, and
allows the developer community to stop debating the merits of different code sharing mechanisms.
<blink>
We have more interesting problems to solve!
</blink>

A language without a native module system is a language in which no one is ever quite sure how to share their code with the widest possible audience.

Betting on the wrong best practice (CommonJS? AMD? UMD?) is a recipe for obscurity, while reverting to the simplest common denominator (global variables) feels like giving up.

And that's why the new ECMAScript 2015 `import` and `export` statements are so vitally important.

A native module system would be a huge relief even if it was more restrictive than CommonJS!

The Go module system simply forbids circular dependencies.

That's one solution.

If you don't like it, don't use Go.

But in fact the ES2015 module system was designed with all the strengths and weaknesses of CommonJS in mind

Thanks to the hard work and cleverness of people like Dave Herman, ES2015 modules solve or at least mitigate all four of the problems I mentioned earlier.