Begrijp de verschillende javascript module formaten

 // utils.js // we create a function function add(r){ return r + r; } // export (expose) add to other modules exports.add = add; // index.js var utils = require('./utils.js'); utils.add(4); // = 8

Het team van CommonJS heeft deze API als een synchrone API gemaakt, wat niet zo goed is voor browsers… Bovendien wordt Commonjs niet van nature begrepen door browsers; er is ofwel een loader-bibliotheek voor nodig, ofwel wat transpiling.

#Asynchronous Module Definition (AMD)

AMD is een soort afsplitsing van CommonJS. Het is gemaakt door leden van het CJS-team die het niet eens waren met de richting die de rest van het team was ingeslagen.

Ze hebben besloten AMD te maken om het asynchroon laden van modules te ondersteunen. Dit is het modulesysteem dat wordt gebruikt door RequireJS en dat client-side werkt (in browsers).

 // add.js define(function() { return add = function(r) { return r + r; } }); // index.js define(function(require) { require('./add'); add(4); // = 8 }

Dit voorbeeld werkt alleen als je requirejs op je website hebt staan. Je kunt een aantal andere AMD voorbeelden vinden.

#Universal Module Definition (UMD)

Zoals je misschien al begrepen hebt zijn deze 2 formaten helaas onderling onbegrijpelijk voor elkaar. Daarom is de UMD in het leven geroepen. Het is gebaseerd op AMD, maar met een aantal speciale gevallen opgenomen om CommonJS compatibility.

Ongelukkigerwijs, deze compatibiliteit voegt een aantal complexiteit die maakt het ingewikkeld om te lezen / schrijven. Als u wilt, kunt u meerdere sjablonen van UMD-code vinden op deze github-repository.

#ES2015 Modules (ESM)

Omdat deze 3 formaten niet zo makkelijk te lezen zijn, moeilijk te analyseren voor statische code analyzer en niet overal ondersteund, heeft het ECMA team (het team achter de standaardisatie van Javascript) besloten om de ECMAScript 2015 (ook bekend als ES6) standaard te maken.Dit formaat is heel eenvoudig te lezen en te schrijven en ondersteunt zowel synchrone als asynchrone werkwijzen.

 // add.js export function add(r) { return r + r; } // index.js import add from "./add"; add(4); // = 8

Meer nog, es-modules kunnen statisch worden geanalyseerd waardoor build tools (zoals Webpack of Rollup) tree-shaking kunnen uitvoeren op de code. Tree-shaking is een proces dat ongebruikte code verwijdert uit bundels.

Helaas, dit formaat heeft nog steeds 2 nadelen (maar ze zijn aan het verbeteren):

• ESM ondersteunt geen dynamisch geïmporteerde modules, maar er is een voorstel voor maanden nu dat is begonnen te worden geïmplementeerd op sommige browsers.
• Het wordt niet door alle browsers ondersteund, maar gelukkig kan dit worden “opgelost” dankzij… transpiling !

#Transpiling

Transpiling is het proces van het vertalen van een taal of versie van een taal naar een andere. Het idee is dus om ES6 te transponeren naar ES5 om een betere browserondersteuning te krijgen.Helaas heeft deze transponering een prijs, omdat het wat extra code toevoegt om de ontbrekende functies van ES6 te patchen die niet bestaan in ES5.

De bekendste transpiler die in dit geval meestal wordt gebruikt, is Babel.

#Verder lezen

Als je verder wilt gaan (door middel van voorbeelden, uitleg, enz.) om te begrijpen hoe die verschillende formaten werken, zijn hier enkele lezingen die ik heb gevonden en die me hebben geïnspireerd:

• JavaScript Module Systems Showdown: CommonJS vs AMD vs ES2015
• Je zou esm moeten gebruiken
• Writing Modular JavaScript With AMD, CommonJS & ES Harmony
• Wat is AMD, CommonJS, en UMD?
• Modularisatie technieken (er zijn meerdere pagina’s hier)
• De toestand van JavaScript modules