You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Modules.md
+66Lines changed: 66 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -47,3 +47,69 @@ var something = (function(globalSecret) {
47
47
```
48
48
49
49
So here, `globalSecret` still equals `'1234'` but `something.globalSecret` equals `'0'`.
50
+
51
+
# CommonJS
52
+
53
+
CommonJS and AMD (asynchronous module definition) solved the problem of designing a module in a way that doesn't have interference of global
54
+
scope where variables can be overwritten.
55
+
56
+
CommonJS used the require syntax which allowed you to import certain files or modules.
57
+
58
+
```javascript
59
+
let module1 =require('module1'); // import a module
60
+
let fight =require('module1').fight; // import a specific function
61
+
```
62
+
CommonJS was created mainly for the server, with Node.js in mind and it contributed to Node's rise in popularity over time. NPM (Node Package Manager) used CommonJS to make it easy for developers to share their modules with eachother.
63
+
64
+
In CommonJS, modules are loaded synchronously, and considering JavaScript only has one call stack, each module needs to load one after the other before your script can even run. This is obviously not ideal for the dynamic environment of a web browser, which was why it was mainly used on the server side only.
65
+
66
+
If only CommonJS could work on the client side without compromising performance..
67
+
68
+
## Asset bundling to the rescue
69
+
70
+
Asset bundling services like Browserify and Webpack allow you to require modules in the browser by bundling up all of your dependencies into one JavaScript file. This traverses the dependeny tree of your code so only one reference needs to be made, preventing you from having to worry about handling the loading sequence of multiple dependencies.
71
+
72
+
# ES6 Modules
73
+
74
+
```javascript
75
+
importmodule1from'module1'
76
+
```
77
+
78
+
JavaScript needed a way to natively support modules in all environments not just the browser, e.g. server, mobile, desktop, iOT devices.
79
+
80
+
### Named export
81
+
82
+
```javascript
83
+
exportconstjump= () => {}
84
+
exportconstattack= () => {}
85
+
86
+
import { jump, attack } from'module2'
87
+
```
88
+
89
+
### Default export
90
+
91
+
```javascript
92
+
exportdefaultconstkick= () => {}
93
+
94
+
importkickfrom'module2'
95
+
```
96
+
97
+
# Conclusion
98
+
99
+
Initially, JavaScript started with simple script tags, but as our programs and web pages got more complex over time, we started to see problems.
100
+
101
+
We needed a way to have modules, so we used Immediately Invoked Function Expressions to create the module pattern. But over time, this system still needed to be improved.
102
+
103
+
So libraries like CommonJS and AMD came into play to make our code more reusable and modular, and also allowed us to share our code with other programmers.
104
+
105
+
Then finally we got native ES6 modules, where JavaScript as a language now has modules built in.
106
+
107
+
This gives us the ability to separate concerns and divide up our programs into small chunks that work independently.
108
+
109
+
We avoid global namespace pollution by only exporting specific code, not necessarily the whole file.
110
+
111
+
We can now compose different modules together to add different functionality to our programs.
112
+
113
+
We can use third party code from places like NPM.
114
+
115
+
We now have a way to organize our codebase better, allowing us to build large applications with JavaScript.
0 commit comments