Commentary
JavaScript Modules Versus Components
The JavaScript community has a semantics problem
by Joe Honton
Here's an intriguing job interview question — Can you describe the difference between a component and a module?
If you're the prospective candidate you may begin squirming in your seat when you hear this asked. And if you're the hiring manager, you may begin wondering why such an entry-level question has sparked so much consternation.
Yes, we can agree that it's just semantics. But if you search for "modules versus components" you'll discover that none of the top answers can quite agree on what's what. Here's how the confusion begins:
"A module is larger than a component. A component is relatively small in scope." [1]
"Modules deal with static code and compile-time dependencies, whereas components deal with instances and execution-time dependencies." [2]
And then there's this less-than-helpful definition that sounds suspiciously recursive: "Modules are added so that each of the functionalities can be easily identified. This is known as component-based software. In this, there are different components of software and each of the components represents a modular . . . part of a system." [3] WTF !?
Maybe the confusion stems from the fact that each computer language has its own particular terminology.
- The popular PHP framework, Joomla, says: "A component always displays its results in the main body area of a template. On the other hand, modules are normally the other bits around the main content." [4]
- For the Java community a module is code that is distributed in a JAR, while a component is "the fundamental user interface object in Java; everything you see on the display in a Java application is a component." [5]
- For the Python community modules are a layer of abstraction for "separating code into parts holding related data and functionality". [6]
And then there's JavaScript.
In JavaScript we learn that "A module is just a file. One script is one module. As simple as that." [7]
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.
- A React developer will rely on the understanding that "components are like JavaScript functions — they accept arbitrary inputs (called “props”) and return React elements describing what should appear on the screen." [8]
- A Vue developer will read the docs and find that "components are reusable instances with a name — they accept the same options as a root instance, such as data and life-cycle hooks." [9]
- A Svelt developer will discover that "components are the building blocks of applications; they are written using a superset of HTML with script, style, and markup all in one file." [10]
- Finally, an Angular developer will encounter a similar definition for "component", but will be dismayed to learn that the word "module" has a divergent meaning: "modules are containers for a cohesive block of code dedicated to an application domain. They can contain components, which are a set of directives, associated with a template." [11]
Anyone who says that they all amount to the same thing might be right. Or would they?
The Component Model
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." [12]
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."
It took a full decade to bring this comprehensiveness to fruition, but today all of the major browsers have native support for the model's four pillars:
- HTML Custom Elements
- W3C Shadow DOM
- HTML <template> and <slot> elements
- ES Modules using export/ import
It seems that all of this semantic confusion points to a failure in marketing. Who's ever heard of the Component Model? Yes, we've all heard of "web component", but we fail to recognize that as something distinct from the unadorned word "component".
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.
In the end, considering all the confusion, perhaps we can forgive our hapless interviewee who was put on the spot when asked about modules and components.
Quotation references
[1] https://softwareengineering.stackexchange.com/questions/178927/is-there-a-difference-between-a-component-and-a-module
[2] https://stackoverflow.com/questions/2702816/module-vs-component-design
[3] https://www.includehelp.com/basics/module-and-software-components-in-software-engineering.aspx
[4] http://www.differencebetween.info/difference-between-joomla-component-and-module
[5] https://www.oreilly.com/library/view/learning-java-4th/9781449372477/ch16s01.html
[6] https://python-docs.readthedocs.io/en/latest/writing/structure.html#modules
[7] https://javascript.info/modules-intro#what-is-a-module
[8] https://reactjs.org/docs/components-and-props.html
[9] https://v3.vuejs.org/guide/component-basics.html#components-basics
[10] https://svelte.dev/docs#Component_format
[11] https://angular.io/guide/architecture-modules
[12] https://wiki.whatwg.org/wiki/Component_Model
