Update

Since Node.js v12 (April 2019), support for ES modules is enabled by default, and since Node.js v15 (October 2020) it's stable (seehere). Files, including Node.js modules, must either end in.mjs or the nearestpackage.json file must contain"type": "module". TheNode.js documentation has a ton more information, also about interoperability betweenCommonJS and ES modules.

Performance-wise there is always the chance that newer features are not as well optimized as existing features. However, since module files are only evaluated once, the performance aspect can probably be ignored. In the end, you have to run benchmarks to get a definite answer anyway.

ES modules can be loaded dynamically via theimport() function. Unlikerequire, this returns a promise.

Previous answer

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 usingBabel. Babel convertsimport andexport 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.js.

There are technical differences 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.

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

Require:

• You can have dynamic loading where the loaded module name isn'tpredefined /static, or where you conditionally load a module only ifit's "truly required" (depending on certain code flow).
• Loading issynchronous. That means if you have multiplerequires, they areloaded and processed one by one.

ES6 Imports:

• You can usenamed imports to selectively load only the pieces you need. That cansave 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.

As of right now ES6 import, export isalways compiled to CommonJS, so there isno benefit using one or other. Although usage of ES6 is recommended since it should be advantageous when native support from browsers released. The reason being, you can import partials from one file while with CommonJS you have to require all of the file.

ES6 →import, export default, export

CommonJS →require, module.exports, exports.foo

Below is common usage of those.

ES6 export default

// hello.jsfunction hello() {  return 'hello'}export default hello// app.jsimport hello from './hello'hello() // returns hello

ES6 export multiple and import multiple

// hello.jsfunction hello1() {  return 'hello1'}function hello2() {  return 'hello2'}export { hello1, hello2 }// app.jsimport { hello1, hello2 } from './hello'hello1()  // returns hello1hello2()  // returns hello2

CommonJS module.exports

// hello.jsfunction hello() {  return 'hello'}module.exports = hello// app.jsconst hello = require('./hello')hello()   // returns hello

CommonJS module.exports multiple

// hello.jsfunction hello1() {  return 'hello1'}function hello2() {  return 'hello2'}module.exports = {  hello1,  hello2}// app.jsconst hello = require('./hello')hello.hello1()   // returns hello1hello.hello2()   // returns hello2

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.

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

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

Some comparison chartshttp://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 importnew JavaScript file from themain JavaScript file via any JavaScript directive.

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

Thisdocument is what we need, and thisdocument 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 somespecial 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 untilimport/export native support goes live, and therequire keyword will not go anywhere for a long time.

What isrequire?

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

Node uses system-level methods to read files. You basically rely on that when usingrequire.require will end in some system call likeuv_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 theimport keyword will be converted intorequire.

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 thatpackage.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 thees2015 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.

When it comes to async or maybe lazy loading, thenimport () is much more powerful. See when we require the component in asynchronous way, then we useimport it in some async manner as inconst variable usingawait.

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

Or if you want to userequire() then,

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

Thing isimport() is actually async in nature. As mentioned by neehar venugopal inReactConf, 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 a necessary part when user connects to specific website to its specific component. E.g., login page before dashboard wouldn't download all components of dashboard. Because what is needed currently, i.e., the login component, only that will be downloaded.

The same goes forexport: ES6export are exactly same as for CommonJSmodule.exports.

Note: If you are developing a Node.js project, then you have to strictly userequire() as Node.js will throw exception error asinvalid token 'import' if you will useimport. So Node.js does not support import statements.

Update - As suggested byDan Dascalescu: Since v8.5.0 (released Sep 2017),node --experimental-modules index.mjs lets you useimport without Babel. You can (and should) alsopublish your npm packages as a native ES Module, with backwards compatibility for the oldrequire way.

See this for more clearance where to use async imports:Neehar Venugopal - A Beginner's Guide to Code Splitting Your React App - React Conf 2017

The most important thing to know is that ES6 modules are, indeed, an official standard, while CommonJS (Node.js) modules are not.

In 2019, ES6 modules are supported by84% of browsers. While Node.js puts them behind an--experimental-modules flag, there is also a convenient node package calledesm, which makes the integration smooth.

Another issue you're likely to run into between these module systems is code location. Node.js assumes source is kept in anode_modules directory, while most ES6 modules are deployed in a flat directory structure. These are not easy to reconcile, but it can be done by hacking yourpackage.json file with pre and post installation scripts. Here is an exampleisomorphic module and anarticle explaining how it works.

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.

• ES modules are static, which means that imports are described at the top level of every module and outside any control flow statement. This will not work:

  if (condition) {   import module1 from 'module1'}

But it in commonjs, it is allowed:

if (condition) {    module = require('module1')}

• ES modules run implicitly instrict mode. This means that we don't have to explicitly add the "use strict" statements at the beginning of every file. Strict mode cannot be disabled; therefore, we cannot use undeclared variables or the with statement or have other features that are only available in non-strict mode.strict mode is a safer execution mode.

• In ESM, some important CommonJS references are not defined. These includerequire , exports , module.exports , __filename, and__dirname.

• We can import CommonJS modules from ESM by using the standard import syntax. But onlydefault exports work:

     import packageName from 'commonjs-package' // Works  import { moduleName } from 'commonjs-package' // Errors

But, it is not possible to import ES modules from CommonJS modules.

• ESM cannot import JSON files directly as modules, a feature that is used quite frequently with CommonJS. That is why in reactjsfetch api is used.

  import data from './data.json' //fails

Not sure why (probably optimization - lazy loading?) is it working like that, but I have noticed thatimport may not parse code if imported modules are not used.
Which may not be expected behaviour in some cases.

Take hated Foo class as our sample dependency.

foo.ts

export default class Foo {}console.log('Foo loaded');

For example:

index.ts

import Foo from './foo'// prints nothing

index.ts

const Foo = require('./foo').default;// prints "Foo loaded"

index.ts

(async () => {    const FooPack = await import('./foo');    // prints "Foo loaded"})();

On the other hand:

index.ts

import Foo from './foo'typeof Foo; // any use case// prints "Foo loaded"

• javascript
• node.js
• ecmascript-6
• babeljs