Original subtitles

1 1

Modules are a super important part 2

2

of software development. 3

3

And so in this lecture, 4

4

we're gonna talk about modules in more depth 5

5

and learn how they work behind the scenes. 6

6

So essentially, a module 7

7

is a reusable piece of code 8

8

that encapsulates implementation details 9

9

of a certain part of our project. 10

10

Now that sounds a bit like a function 11

11

or even a class, 12

12

but the difference is that a module 13

13

is usually a standalone file. 14

14

Now that's not always the case, 15

15

but normally when we think of a module 16

16

we think of a separate file. 17

17

So of course a module always contains some code 18

18

but it can also have imports and exports. 19

19

So with exports, as the name says, 20

20

we can export values out of a module 21

21

for example, simple values or even entire functions. 22

22

And whatever we export from a module 23

23

is called the public API. 24

24

So this is just like classes 25

25

where we can also expose a public API 26

26

for other codes to consume. 27

27

Now, in the case of modules, 28

28

this public API is actually consumed 29

29

by importing values into a module. 30

30

So just like we can export values 31

31

in modules, we can usually also import values 32

32

from other modules. 33

33

And these other modules from which we import 34

34

are then called dependencies 35

35

of the importing module 36

36

because the code dead is in the module 37

37

dead is importing cannot work without the code, 38

38

that it is importing from the external module, right? 39

39

And this entire logic that I just described 40

40

is true for all modules 41

41

in all programming languages. 42

42

So this is not specific to only JavaScript. 43

43

In fact, modules are a pattern that developers 44

44

have been using in all languages for decades. 45

45

Now, of course we can write code without modules, 46

46

and actually we've been doing that 47

47

up until this point. 48

48

but that's because our applications 49

49

have been very simple. 50

50

However, when a code base grows bigger and bigger, 51

51

there start to be many advantages 52

52

of using modules. 53

53

And the first one is that modules make it 54

54

really easy to compose software. 55

55

So we can think of modules 56

56

as small building blocks 57

57

that we can then put together 58

58

in order to build really complex applications. 59

59

And I think it might be helpful 60

60

to look at a more real world example, 61

61

to understand all the benefits of modules. 62

62

So let's take this digital camera. 63

63

You can see that this specific camera 64

64

is basically made up of all these modules 65

65

that we can see here. 66

66

And this is exactly how we can compose software 67

67

using modules as well. 68

68

Another big advantage of these camera modules 69

69

is that each of them can be 70

70

developed in complete isolation. 71

71

So you can have one engineer working on the lens 72

72

and another one on the screen 73

73

and even another one on the controller module. 74

74

And the best part of this is that each engineer 75

75

can actually work on their own module 76

76

without even understanding 77

77

what the other engineers are doing. 78

78

And also without understanding 79

79

how the entire final camera works itself. 80

80

And so isolating components 81

81

is another huge advantage of using modules. 82

82

And again, isolating components 83

83

essentially means that each module 84

84

can be developed in isolation 85

85

without the developer having to think 86

86

about the entire code base. 87

87

He doesn't even need to understand all of it, 88

88

which makes it really easy 89

89

to collaborate on a larger team. 90

90

Next up modules make it very easy 91

91

to abstract or code. 92

92

And we already talked about 93

93

what abstraction means, 94

94

but basically we can use modules 95

95

to implement low level code 96

96

then other modules, 97

97

which don't really care 98

98

about these low level details 99

99

can import these abstractions and use them. 100

100

And back to our camera, the screen module, 101

101

for example, does not care 102

102

about the low level implementation details 103

103

of the controller module. 104

104

It can simply import the controller, 105

105

but without knowing how it works 106

106

and use it to control other parts of the camera. 107

107

And so that's essentially the power of abstraction. 108

108

Modules also naturally lead 109

109

to a more organized code base. 110

110

Because when we break up our code 111

111

into separate isolated and obstructed modules, 112

112

this will automatically organize our code 113

113

and make it easier to understand. 114

114

And so this alone is a huge benefit of modules. 115

115

Finally modules allow us to easily reuse 116

116

the same code in a project 117

117

and even across multiple projects. 118

118

For example, if we use the module 119

119

to implement a couple of mathematical functions 120

120

in a certain project, 121

121

and if we then need the same functions 122

122

in the next project, 123

123

all we need to do is to copy that module 124

124

to the new project. 125

125

And in our camera example here, 126

126

this company could now use the exact same lens 127

127

or the exact same screen 128

128

in different camera models, 129

129

all because they nicely abstracted these components 130

130

into self-contained reusable modules. 131

131

So this is how modules work 132

132

in software design in general. 133

133

But now let's take a look at modules 134

134

specifically in JavaScript. 135

135

So as of ES6, 136

136

JavaScript has a native built-in module system. 137

137

Now we did have modules before ES6, 138

138

but we had to implement them ourselves 139

139

or use external libraries. 140

140

So ES6 modules are modules 141

141

that are actually stored in files 142

142

and each file is one module. 143

143

So there is exactly one module per file. 144

144

But now you might be thinking, 145

145

well, scripts are usually also files, right? 146

146

And that's of course true. 147

147

And so let's not compare 148

148

these two types of files 149

149

in order to understand 150

150

that there are actually huge differences 151

151

between old school scripts and modern ES6 modules. 152

152

The first difference is that in modules, 153

153

all top level variables 154

154

are scooped to the module. 155

155

So basically variables are private 156

156

to the module by default. 157

157

And the only way an outside module can access 158

158

a value that's inside of a module 159

159

is by exporting that value. 160

160

So just as we learned in the last slide. 161

161

But if we don't export, 162

162

then no one from the outside can see the variable. 163

163

Now in scripts, on the other hand, 164

164

all top level variables 165

165

are always global and I showed you this 166

166

in the map d project, remember? 167

167

And this can lead to problems 168

168

like global namespace pollution, 169

169

where multiple scripts try to declare variables 170

170

with the same name and then 171

171

these variables collide. 172

172

So private variables 173

173

are the solution to this problem. 174

174

And that's why ES6 modules implemented it like this. 175

175

Next ES modules are always executed 176

176

in strict mode while scripts on the other hand 177

177

are executed in sloppy mode by default. 178

178

So with modules, there is no more need 179

179

to manually declare strict mode. 180

180

Also the disc keyword is always undefined 181

181

at the top level 182

182

while in scripts it points at the window object, right? 183

183

Now, as we learned in the last slide, 184

184

what's really special about modules 185

185

is that we can export and import values 186

186

between them using this ES6 import 187

187

and experts syntax. 188

188

In regular scripts, 189

189

importing and exporting values 190

190

is just completely impossible. 191

191

Now, there is something really important 192

192

to note about imports and exports, 193

193

which is the fact that they can only happen 194

194

at the top level. 195

195

So as you know, outside of any function 196

196

or any if block, 197

197

and we will see why that is in a second. 198

198

Also all imports are hoisted. 199

199

So no matter where in a code 200

200

you're importing values, 201

201

it's like the import statement 202

202

will be moved to the top of the file. 203

203

So in practice importing values 204

204

is always the first thing that happens in a module. 205

205

Now, in order to link a module to an HTML file, 206

206

we need to use the script tag with 207

207

the type attribute set to module, 208

208

instead of just a plain script tag. 209

209

And finally about downloading 210

210

the module files themselves. 211

211

This always automatically happens 212

212

in an asynchronous way. 213

213

And this is true for a module loaded 214

214

from HTML as well as for modules 215

215

that are loaded by importing 216

216

one module into another, 217

217

using the import syntax. 218

218

Now regular scripts on the other hand 219

219

are downloaded by default 220

220

in a blocking synchronous way, 221

221

unless we use the async 222

222

or differ attributes on the script tag. 223

223

So that's a great overview of ES6 modules, 224

224

but now let's dig a bit deeper 225

225

and really understand how modules 226

226

actually import other modules behind the scenes. 227

227

And to do that, let's analyze what happens 228

228

in this small code example. 229

229

So here we're importing a value 230

230

called rent from the math.js module 231

231

and show dies from the dumb.jsmodule. 232

232

Now, as always, when a piece of code is executed, 233

233

the first step is to parse that code. 234

234

Remember, so we talked about that way back. 235

235

But remember that parsing basically means 236

236

to just read the code, 237

237

but without executing it. 238

238

And this is the moment 239

239

in which imports are hoisted. 240

240

And in fact, the whole process of importing modules 241

241

happens before the code in the main module 242

242

is actually executed. 243

243

So in this example, 244

244

the index.js module imports, 245

245

the dumb and math modules 246

246

in a synchronous way. 247

247

What that means is that only after 248

248

all imported modules have been downloaded and executed, 249

249

the main index.js module 250

250

will finally be executed as well. 251

251

Now this is only possible 252

252

because of top level imports and exports 253

253

that's because if we only export and import values 254

254

outside of any code that needs to be executed, 255

255

then the engine can know 256

256

all the imports and exports during the parsing phase. 257

257

So while the code is still being read 258

258

before being executed. 259

259

Now, if we were allowed to import a module 260

260

inside of a function, 261

261

then that function would first 262

262

have to be executed before the import code happened. 263

263

And so in that case, 264

264

modules could not be imported in a synchronous way. 265

265

So the importing module 266

266

would have to be executed first. 267

267

But you might ask why do we actually want 268

268

modules to be loaded in a synchronous way? 269

269

Isn't synchronous bad? 270

270

Well, the answer is that this is the easiest way 271

271

in which we can do things 272

272

like bundling and dead code elimination. 273

273

So basically deleting code 274

274

that's actually not even necessary. 275

275

And trust me, 276

276

this is very important in large projects 277

277

with hundreds of modules 278

278

and that includes third party modules 279

279

from which we usually only want a small piece 280

280

and not the entire module. 281

281

So by knowing all dependencies 282

282

between modules before execution, 283

283

bundlers like webpack and Parcel 284

284

can then join multiple modules together 285

285

and eliminate that code. 286

286

And so essentially this is the reason why 287

287

we can only import and export 288

288

outside of any code that needs to be executed. 289

289

So like a function or an if block, 290

290

but now let's move on here. 291

291

So after the parsing process, 292

292

HIAS figured out which modules it needs to import, 293

293

then these modules are actually downloaded 294

294

from the server. 295

295

And remember downloading actually happens 296

296

in an asynchronous way. 297

297

It is only the importing operation itself 298

298

that happens synchronously. 299

299

Then after a module arrives, 300

300

it's also parsed and the modules exports 301

301

are linked to the imports in index.js. 302

302

So for example, 303

303

the math module exports a function called rent. 304

304

And this export is then connected 305

305

to the rent import in the index.js module. 306

306

And this connection is actually a life connection. 307

307

So exported values are not copied to imports. 308

308

Instead, the import is basically just a reference 309

309

to the export at value 310

310

like a pointer. 311

311

So when the value changes 312

312

in the exporting module, 313

313

then the same value also changes 314

314

in the importing module. 315

315

And this is quite important to understand 316

316

because it's unique to ES6 modules. 317

317

Other module systems do not work like this, 318

318

but JavaScript modules do. 319

319

And so you need to keep that in mind. 320

320

But anyway, next up, 321

321

to code in the imported modules is executed. 322

322

And with this the process of importing 323

323

modules is finally finished. 324

324

And so now, as I already said, 325

325

it's time for the importing module 326

326

to be finally executed as well. 327

327

So index.js in this example. 328

328

Alright. And by now you're probably tired 329

329

of listening to me. 330

330

And so let's quickly move on 331

331

and actually try all this with actual code.