DEV Community

Cover image for JavaScript Modules Versus Components
Joe Honton
Joe Honton

Posted on

JavaScript Modules Versus Components

Excerpted from

In JavaScript we learn that “A module is just a file. One script is one module. As simple as that.”

But of course nothing is simple in JavaScript: there are AMD modules, CommonJS modules, UMD modules, and native ES modules.

And when we finally wrap our heads around the module mess, we’re still left with a variety of definitions for “component”, which is where the confusion begins to get opinionated.

Way back in 2011, the Web Hypertext Application Technology Working Group (WHATWG) defined the Component Model to complement its work on the all-important Document Object Model (DOM).

To quote from the WHATWG wiki: “The Component Model introduces comprehensive support for creating DOM elements.” And it goes on to explain that “the Component Model formalizes the concept of loosely coupled, coherent units of behavior in the Web platform.”

This was at a time in history when you could explain it this way — to the delight of everyone: “Examples include layout managers, combinations of Dojo and jQuery widgets, isolated widgets, such as Like/+1 buttons, and built-in HTML elements themselves.”

Lately, I’ve been hearing the phrase “vanilla JavaScript” used to indicate that no framework or library is involved in a coding solution. So in a similar fashion, it appears that “vanilla component” could be a good way out of this mess. Personally, I like to call them DOM Components, giving credit where credit is due.

Discussion (0)