Modules, introduction

As our application grows bigger, we want to split it into multiple files, so called “modules”. A module may contain a class or a library of functions for a specific purpose. For a long time, JavaScript existed without a language-level module syntax. That wasn’t a problem, because initially scripts were small and simple, so there was no need. But eventually scripts became more and more complex, so the community invented a variety of ways to organize code into modules, special libraries to load modules on demand. To name some (for historical reasons): - AMD – one of the most ancient module systems, initially implemented by the library require.js. - CommonJS – the module system created for Node.js server. - UMD – one more module system, suggested as a universal one, compatible with AMD and CommonJS. Now these all slowly became a part of history, but we still can find them in old scripts. The language-level module system appeared in the standard in 2015, gradually evolved since then, and is now supported by all major browsers and in Node.js. So we’ll study the modern JavaScript modules from now on.

What is a module?

A module is just a file. One script is one module. As simple as that. Modules can load each other and use special directives export and import to interchange functionality, call functions of one module from another one: - export keyword labels variables and functions that should be accessible from outside the current module. - import allows the import of functionality from other modules. For instance, if we have a file sayHi.js exporting a function: …Then another file may import and use it: The import directive loads the module by path ./sayHi.js relative to the current file, and assigns exported function sayHi to the corresponding variable. Let’s run the example in-browser. As modules support special keywords and features, we must tell the browser that a script should be treated as a module, by using the attribute