DEV Community

Cover image for JavaScript Modules: From IIFEs to CommonJS to ES6 Modules

JavaScript Modules: From IIFEs to CommonJS to ES6 Modules

Tyler McGinnis on January 22, 2019

I’ve taught JavaScript for a long time to a lot of people. Consistently the most commonly under-learned aspect of the language is the module system...
Collapse
 
dance2die profile image
Sung M. Kim

This is the article I wish I had read when I first started diving into the world of JavaScript.

All those require in code snippets really drove me crazy. Most of response I got was, it's for Node. Node what? and started diving into it, etc... It was like going down a rabbit hole.

But this article explains "why" it was created, and how it has evolved in very digestible format. 👍

Collapse
 
somascope profile image
Scott

Thanks for this great explanation of modules! One question that I wondered about was the mixed used case of a module having named exports as well as a default export. Is that common, or are there reasons to avoid both types of exports in a module?

It might be helpful to indicate that default exports can only exist once per module. I know that's confused some people when creating modules while learning to do so.

Collapse
 
jeroka profile image
Esteban Rocha

Great article! thanks!

Collapse
 
emgodev profile image
Michael • Edited

I hate reading this: "You'll notice that there's a lot of magic going on there", even if it's only acknowledging it may be something the reader does not understand, don't give them an excuse to remain ignorant. There is always a reason and explanation for why or how something works. We should stop saying anything is magic.

"There is obviously a lot going on here and the internal workings of module systems is another topic, but we can see webpack has a design that internalizes our code in an IIFE of it's own", this would have been a great replacement, or since you sort of say this later in a similar way, just remove the magic bit. It offers zero credit.