Webpack 4 Fundamentals

EcmaScript Modules (ESM)

Sean Larkin

Sean Larkin

Webpack 4 Fundamentals

Check out a free preview of the full Webpack 4 Fundamentals course

The "EcmaScript Modules (ESM)" Lesson is part of the full, Webpack 4 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Sean discusses EcmaScript Modules (ESM), a standard pattern for importing JavaScript modules.


Transcript from the "EcmaScript Modules (ESM)" Lesson

>> Sean Larkin: And so like what's, was there a solution? There was, [LAUGH] ESM, so, then came along, after 10 year of being developed. I even saw references to this syntax in a document from like 1998. When they were originally working on it. So this was like 10 to 20 years in the making in design.

[COUGH]. And so, this is the equiscript module format or ESM. You might even all call it ES modules ESM. What you shouldn't call it is 2015 modules or anything like that. It's the, the ES 2015 specification is completely separate from the module spec. The original spec was called the harmony modules specification and so, I think even that little detail right there is something that trips people up, ES modules, completely separate from ES2015.

You could write ES3 syntax and still use modules and there's no problem with that. It's just specifically ESM defines the import, the syntax here, the export, the static behavior, the module loading, how the browsers are supposed to load it. And so, there's two ways that you can load modules for ESM.

You have named it. So, there were many things that were taken in inspiration for common JS. So, for example, you have the named exports and then you also have a default export. Or you can use a namespace specifier, which is like the import * as, it takes a collection of named exports and just groups it into one object.

And then if you wanted to provide something another file or module, you'd do so using the export default syntax or export and then any expression. Or export conts, whatever and then whatever the value is. And there's a lot of like, there's lots of incredible things now that we have.

We have reusability, we now have true encapsulation. And this is for most modules in general. It's why we started writing this, coming from the pure loosey goosey spaghetti JavaScript ecosystem where it started, what? There's problems with the ESM. So there are kinda some issues. Whats the status for ESM for Node, do you guys know?

>> Speaker 2: MJS.
>> Sean Larkin: I mean that's not even fully in stone either. They had to create an entire task force of over 20 open source teams. Just to try to settle on semantics and it's still in process as we speak right now. And so, yes, ESM for node is kind of up in the air.

How they work in the browser? Have you guys tried using modules natively in the browser? They're incredibly slow. I would say slow to a point that they're basically broken. It's completely unusable past 10 modules. Or even that takes forever. When you think about it, when you're using that syntax, the browser has to basically read top down.

It needs to start at import statement. It needs to look at that specifier, where that package is. It needs to go resolve it. It needs to then figure out all those exports actually there invalid? Then it needs to read that file and do the exact same thing until it finds every other module that it's referencing at run time, when you load your page.

ESM for the browser is not an option I would ever recommend to anyone, under any scenario. I don't care if it's, you're just using one module, it's still incredibly slow. It's a huge bottleneck for performance.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now