require Vs import In JavaScript

Travis Ramos - Aug 15 - - Dev Community

I remember when I started coding I would see some js files using require() to import modules and other files using import. This always confused me as I didn’t really understand what the difference was or why there was inconsistency across projects. If you’re wondering the same thing, continue reading!

What is CommonJS?

CommonJS is a set of standards used to implement modules in server-side JavaScript, mainly Node.js environments. In this system, modules are loaded synchronously, which means the script execution is blocked until the module is loaded. This makes for a straightforward approach, but the downside is a performance hit if you're trying to load in a bunch of different modules since they’d have to load one after another before anything else can run.

When using CommonJS you’d use module.exports to export functionality and use require() to import it.

Here’s an example of what that would look like in code.

// In file multiple.js

module.exports = function multiply(x, y) {
    return x * y;
};
Enter fullscreen mode Exit fullscreen mode
// In file main.js

const multiply = require(‘./multiply.js’);

console.log(multiply(5, 4)); // Output: 20
Enter fullscreen mode Exit fullscreen mode

What is ECMAScript (ES6)?

ES6, also known as ECMAScript, is a newer version of JavaScript that was released in 2015. With this release came the ability to import modules asynchronously using the import and export statements. This means that the script you’re running can continue to execute while the module is being loaded in so there is no bottlenecking. This also allows for an efficiency called tree-shaking which I will cover in a later post, but basically, this means you only load in JavaScript from a module that you are using and dead-code (code not being used) isn’t loaded into the browser. This is all possible because ES6 supports both static and dynamic imports.

Here’s that same example from before but this time we are using import and export.

// In file multiply.js

export const multiply = (x, y) => x * y;
Enter fullscreen mode Exit fullscreen mode
// In file main.js

import { multiply } from ‘./multiply.js’;

console.log(multiply(5, 4)); // Output: 20
Enter fullscreen mode Exit fullscreen mode

The Main Differences: require Vs import

require() is part of the CommonJS module system while import is part of the ES6 module system. You’ll see require() used in Node.js environments for server-side development, mainly on legacy projects that haven’t adopted ES6 just yet. You’ll see import used in both server-side and frontend development, especially newer projects and with any of the frontend frameworks like React or Vue.

Why is import Better Than require?

As we mentioned earlier, import is asynchronous, which can lead to better performance, especially in large applications. Also, since import can be statically analyzed, tools like linters and bundlers can optimize the code more effectively and implement tree shaking which leads to smaller bundle sizes and faster load times. The syntax is also easier to read then require() which makes for a better developer experience, and we all want that!

When Would You Use require Vs import

You’d use require() when:

  • You are working on a legacy Node.js project that was started before ES6 came out and hasn’t been updated.

  • You need to dynamically load modules at runtime, such as in a configuration file, or if you need to conditionally load modules.

You’d use import when:

  • Any other time as this is the standard now and more efficient.

Summary

In general, it's recommended to use import whenever possible, as it provides more benefits and is the newer, more widely adopted module system. However, there may be cases where require() is still the better choice, depending on your specific requirements and the environment you're working in.

If you found this article helpful, subscribe to my newsletter where I'll be sending more content like this directly to your inbox on a weekly basis!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .