Webpack 4 Fundamentals

Problems with Script Loading

Sean Larkin

Sean Larkin

Webpack 4 Fundamentals

Check out a free preview of the full Webpack 4 Fundamentals course

The "Problems with Script Loading" Lesson is part of the full, Webpack 4 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

By reviewing the limitations of JavaScript for web applications, Sean explains the problems that Webpack solves


Transcript from the "Problems with Script Loading" Lesson

>> Sean: And so really that, I just wanna talk about why. So, I don't think I really have a great document on our Github yet, on our docs. Why Webpack? What is it solving? And to really understand that you kinda need to know the origins of how we've used JavaScript on the web, right?

>> Sean: So I mean, how do you use JavaScript in the browser? There's really only two ways, that's it. There's only two ways that you can use JavaScript and load it in the browser.
>> Sean: And I mean, JavaScript is just a script. It's just top down bottom execution. And as you can see here, this is JavaScript.

It's just a script format, it always has been up until lately. Like I said, there's only two ways that you can actually get this functionality to work in the browser. The first way is adding a script tag for passing a source attribute and a reference to that JavaScript file.

And this is great, this is how we leverage when were using Webpack today. And the second way is actually this write your job description to HTML, JS and HTML that new thing, have you heard of it? No [LAUGH] It's been around forever but you can do this. But I mean, when you break it down, so those are the only two ways.

What is a problem for these things? It doesn't scale, whatsoever. I mean, you're either gonna have too many scripts that you're trying to load from script tags in the HTML. And each browser actually has bottlenecks. This creates a bottleneck. There's only a certain amount of concurrent requests that can fetch data at a single time.

And so like breaking your application into a 100 JavaScript files and loading them in the browser is a huge performance problem. And some people might say, but Sean, HTTP 2 will help, and not really. Even if you had, let's say, 2,000, the concurrent requests usually they say, 30 to 50, your application is thousands and thousands of modules.

We're talking 3,000. Companies like Airbnb and Microsoft's Outlook web app, they're talking 30,000 modules to build their application. And so it's just wild. There is no way that you can have a performance experience by trying to load individual scripts. I could beat that horse dead for days. But then, you're like, well, Sean, I'll just write one big one, right.

Who's worked on the 10,000 line global back JS file that ships on every page? Yeah, yeah! So, I worked for an eCommerce company called Hayneedle, and that was my first experience with JavaScript. It was a single 10,000 plus line file called global dot JS. And of course, these are all the things I struggle with.

Like endless, I remember spending nights trying to debug, why one function wasn't working to only find out it was because I was knocking out another variable that was at line 10 while I was working in line 9,000. One of the quirks of JavaScript that I think erks people coming from different language ecosystems is that we have this crazy idea for scoping.

Everything is global in its scope, but you can also have things like first class functions and so everything is global. Your functions, your objects, and so there's a lot of issues with just scope and variable conflicts. But this, we solve things in the web ecosystem. So what do we do?

Who knows what an IIFE is, IIFE? Cool, that's a good start. So an IIFE stands for Immediately Invoked Function Expression. Now what does this mean? So take this code example here. Now, essentially what's happening, is that we have this function that's defined, but it's wrapped in parentheses and then, you'll see at the end it's called.

And so, what this does is that when you have an IFFE, it's treated as an expression and instantly executed. But it also allows us to provide data from an outside scope and then, return scoped information. So in this case, if you were to write this code in like your node terminal or whatever in dev tools, you're gonna see that whatever actually returns properties on some, just like if it was a module or some sort of object.

And that was the kinda goal here, right? We want to be able to weigh to encapsulate and that's what IFFES do. So if you took this and you removed the IFFE pieces, you would notice that, if you ran this code, you had a variable declared at the top.

So outer scope is equal to one, and let's just pretend the IFFES not there. Well, then you would define outer scope inside of the function, which gives its own function scope but then, that actually knocks out the value in the outerScope. So if I run console.log(outerScope), I would find out that it returns 1.

So instantly, you can see why if he solve big problems. Now we can have the enterScope of that variable with the same name as the outer scope. And it's all about having encapsulation. So people started to, instead shift their JavaScript, but have individual files that were wrapped in IIFEs, right.

And so that way, they could do things. And this is not the only module pattern. The revealing module pattern is just one of a bajillion if you've ever read the JavaScript design patterns. There's me and Addie hanging out, he's a good friend of mine. And he's the author of this book, but you'll notice that most of them are just surrounded by the idea of using encapsulation primitives of immediately invoked function expressions.

But this let's us concatenate. Now, we can take and write a hundred files and we can squish them together without concerns that we're gonna knock out a bunch of variables and scopes, and I put a star there cuz there's always caveats. However, and this really led to the explosion of these toolings.

So we started seeing tools like Make. Who's used Make on a JavaScript project? I did that for the first time in Microsoft Edge. Edge is part of the operating system, and so our OS code base is a 24 terabyte git repo. And it used end make which is our custom windows version but I had that first experience with trying to use make with JavaScript.

Boy, it was frustrating. Really frustrating but some people love it. And really, all the purpose is is just to concatenate the files together. And that's what Grunt and Gulp and Broccoli, like all these things. That's where these tools started cropping up. It's trying to solve problems. However, there's still problems with this.

What you're gonna notice that, anytime you want to change one file, you have to rebuild the whole thing. We're just concatenating all of these module. They are not modules but these scripts together. And then, more importantly, when you concat, let's say, who uses Lodash here or Moment JS?

All right, that's a huge library. That's like one meg, two megs of JavaScript, maybe even three I can't remember. JD will tell me when I get back to work. But if you're just concatenating files together, how do you remove code that you're actually not using? How do you even know there's code you're not using.

When you are in script there is no way. You essentially fear only using one function from Lodash or one data utility from Moment JS. You're literally adding the entire library and just crushing it together, that turns out that. Immediately both function expressions are kinda slow. So what happened, no one lost the news.

One of my coworkers and author of Couch DB or Couch TV, I can't remember. He did a study and found out that bundlers, this was specific to bundlers early on, we're creating lots of IFFE in using a similar pattern, or people were writing in IIFE's and concatenating together.

But what this does is, it forces JavaScript engines to eager parse the code, and so you incur much more intensive or costly parsing time when your JavaScript's loading, so it leads to slower loading apps. And how do you lazy load with a task runner? You don't, well there is no way, whatever you're building.

Your shipping all that code down the pipeline, even if your app maybe only uses 10% of it to load and get your initial experience. You can just kinda see there's a lot of problems here. We're just showing scripts together.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now