Cover image for πŸš€ Dynamic Imports (Code Splitting) | ES2020

πŸš€ Dynamic Imports (Code Splitting) | ES2020

nialljoemaher profile image Niall Maher ・2 min read

The ES2020 features were just approved by the TC39 committee, and in the proposal, you can import a file dynamically. What does that mean? Instead of having all your imports at the top of your file, you can import files as you need them and actually just load the data needed as it’s needed.

We have been doing this for a while with the help of Webpack or other build tools. Having it as a native feature will mean you won’t have to worry about the build tools and you can just focus on creating great applications.

In this video, we will refactor code so you can start using it today.

For more details scroll down. πŸ‘‡

The static form is preferable for loading initial dependencies and can benefit more readily from static analysis tools and tree shaking.

Why dynamically import?

Static imports will slow down your application, by dynamically importing you can drastically speed up your load times. By not having one single large bundle you can archive crazy fast applications. This is known as "code splitting" as the code is delivered in smaller bundles as required.

Another reason you may want to dynamically import is if the module you are importing does not exist at load time.


To dynamically import a module, the import keyword may be called as a function. When used this way, it returns a promise.

  .then((module) => {
    // Now you can use the module here.

But for a much cleaner await keyword.

let module = await import('/modules/some-module.js');

There are often times where you may never need to import a module (think of an unvisited page in a single page application). We can dynamically import based on user actions too which make dynamic importing super flexible.

Here's a sample of how you would dynamically load a module when the user clicks an element.

.addEventListener("click", async () => {
    const { app } = await import("./app.js");

So it's that easy! This can drastically improve your user experience if you can build it into your workflow.

If you are looking for more information check out the MDN docs for Dynamic Importing.
πŸ”— https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Dynamic_Imports

Follow me on Twitter

Subscribe on CodΓΊ Community

Posted on by:

nialljoemaher profile

Niall Maher


Owner @ CodΓΊ, JavaScript Developer, mentor and a lifelong learner. Tweet @nialljoemaher


Editor guide

excelente, mi amigo!


Gracias! πŸ’œ


Hello Niall, thank you for that interesting article.

The example you posted would only be valid if you use the await in an async function context-
.addEventListener("click", async() => {
const { app } = await import("./app.js");


I am wondering if a user clicks a button ten times which means we are going to import app.js each time. So, it will affect app performance or not? πŸ˜…πŸ€”


Good question, it will be available in the browser memory. By clicking it again you don't reload it. It's smart enough to know it has the bundle loaded so it will no longer need to be fetched from the web after the initial load. So it won't negatively affect your performance. πŸš€

are you sure? don't we need to check first for undefined and then load the module

app = await import("./app.js");

You could wrap the whole thing in a try catch if you wanted some error checking. This is just a super simplified sample.

no this is not about error checking.. if we check beforehand that the module is already loaded then we need not load it again

Nope, run the code with the network tab open and you'll see it's only fetched once no matter how many times you click the button.

got it, if that's the case then it's okay.


Good catch! A typo on my behalf. Thank you πŸ’œ


Can we already use this natively?


There is some pretty good support already yes:


Wow, pretty cool! Nice article Niall, congrats :)


Cheers Rafael!