Using Node.js require vs. ES6 import/export

问题:

In a project I\'m collaborating on, we have two choices on which module system we can use:

1. Importing modules using require, and exporting using module.exports and exports.foo.
2. Importing modules using ES6 import, and exporting using ES6 export

Are there any performance benefits to using one over the other? Is there anything else that we should know if we were to use ES6 modules over Node ones?

回答1:

Are there any performance benefits to using one over the other?

Keep in mind that there is no JavaScript engine yet that natively supports ES6 modules. You said yourself that you are using Babel. Babel converts import and export declaration to CommonJS (require/module.exports) by default anyway. So even if you use ES6 module syntax, you will be using CommonJS under the hood if you run the code in Node.

There are technical difference between CommonJS and ES6 modules, e.g. CommonJS allows you to load modules dynamically. ES6 doesn\'t allow this, but there is an API in development for that.

Since ES6 modules are part of the standard, I would use them.

回答2:

There are several usage / capabilities you might want to consider:

Require:

• You can have dynamic loading where the loaded module name isn\'t predefined /static, or where you conditionally load a module only if it\'s \"truly required\" (depending on certain code flow).
• Loading is synchronous. That means if you have multiple requires, they are loaded and processed one by one.

ES6 Imports:

• You can use named imports to selectively load only the pieces you need. That can save memory.
• Import can be asynchronous (and in current ES6 Module Loader, it in fact is) and can perform a little better.

Also, the Require module system isn\'t standard based. It\'s is highly unlikely to become standard now that ES6 modules exist. In the future there will be native support for ES6 Modules in various implementations which will be advantageous in terms of performance.

回答3:

The main advantages are syntactic:

• More declarative/compact syntax
• ES6 modules will basically make UMD (Universal Module Definition) obsolete - essentially removes the schism between CommonJS and AMD (server vs browser).

You are unlikely to see any performance benefits with ES6 modules. You will still need an extra library to bundle the modules, even when there is full support for ES6 features in the browser.

回答4:

Are there any performance benefits to using one over the other?

The current answer is no, because none of the current browser engines implements import/export from the ES6 standard.

Some comparison charts http://kangax.github.io/compat-table/es6/ don\'t take this into account, so when you see almost all greens for Chrome, just be careful. import keyword from ES6 hasn\'t been taken into account.

In other words, current browser engines including V8 cannot import new JavaScript file from the main JavaScript file via any JavaScript directive.

( We may be still just a few bugs away or years away until V8 implements that according to the ES6 specification. )

This document is what we need, and this document is what we must obey.

And the ES6 standard said that the module dependencies should be there before we read the module like in the programming language C, where we had (headers) .h files.

This is a good and well-tested structure, and I am sure the experts that created the ES6 standard had that in mind.

This is what enables Webpack or other package bundlers to optimize the bundle in some special cases, and reduce some dependencies from the bundle that are not needed. But in cases we have perfect dependencies this will never happen.

It will need some time until import/export native support goes live, and the require keyword will not go anywhere for a long time.

What is require?

This is node.js way to load modules. ( https://github.com/nodejs/node )

Node uses system-level methods to read files. You basically rely on that when using require. require will end in some system call like uv_fs_open (depends on the end system, Linux, Mac, Windows) to load JavaScript file/module.

To check that this is true, try to use Babel.js, and you will see that the import keyword will be converted into require.

回答5:

Using ES6 modules can be useful for \'tree shaking\'; i.e. enabling Webpack 2, Rollup (or other bundlers) to identify code paths that are not used/imported, and therefore don\'t make it into the resulting bundle. This can significantly reduce its file size by eliminating code you\'ll never need, but with CommonJS is bundled by default because Webpack et al have no way of knowing whether it\'s needed.

This is done using static analysis of the code path.

For example, using:

import { somePart } \'of/a/package\';

... gives the bundler a hint that package.anotherPart isn\'t required (if it\'s not imported, it can\'t be used- right?), so it won\'t bother bundling it.

To enable this for Webpack 2, you need to ensure that your transpiler isn\'t spitting out CommonJS modules. If you\'re using the es2015 plug-in with babel, you can disable it in your .babelrc like so:

{
  \"presets\": [
    [\"es2015\", { modules: false }],
  ]
}

Rollup and others may work differently - view the docs if you\'re interested.

回答6:

When it comes to async or maybe lazy loading, then import () is much more powerful. See when we require the component in asynchronous way, then we use import it in some async manner as in const variable using await.

const module = await import(\'./module.js\');

Or if you want to use require() then,

const converter = require(\'./converter\');

Thing is import() is actually async in nature. As mentioned by neehar venugopal in ReactConf, you can use it to dynamically load react components for client side architecture.

Also it is way better when it comes to Routing. That is the one special thing that makes network log to download necessary part when user connects to specific website to its specific component. eg. login page before dashboard would\'nt download all components of dashboard. Because what is needed current i.e. login component, that only will be downloaded.

Same goes for export : ES6 export are exactly same as for CommonJS module.exports.

NOTE - If you are developing a node.js project, then you have to strictly use require() as node will throw exception error as invalid token \'import\' if you will use import . So node does not support import statements

UPDATE - As suggested by Dan Dascalescu: Since v8.5.0 (released Sep 2017), node --experimemntal-modules index.mjs lets you use import without Babel. You can (and should) also publish your npm packages as native ESModule, with backwards compatibility for the old require way.

See this for more clearance where to use async imports - https://www.youtube.com/watch?v=bb6RCrDaxhw

回答7:

I personally use import because, we can import the required methods, members by using import.

import {foo, bar} from \"dep\";

FileName: dep.js

export foo function(){};
export const bar = 22

Credit goes to Paul Shan. More info.