Q&A and Closing Remarks

[00:00:02]
>> Sean Larkin: Yeah, go ahead, this is the perfect time. Cuz really I think this kinda rounds out, now, you should, by default at least, have everything, understanding how to use a loader. Understanding how to apply it, understanding where it is composed to isolate behaviors in your configurations. How really to use ESM and even common JS if you have to.

[00:00:29]
But I mean hopefully you feel a lot more confident about what Webpack is that it's doing and how it works. Tomorrow, before we learn about plugins, I have a special deep dive section which actually talks about, what is Webpack doing under the hood, specifically? But yeah, I think, rounded out wise, this is a good place to stop in terms of content, what were the other questions?

[00:00:59]
>> Speaker 2: If you split your JavaScript files into main, vendor and manifest, as per the docs on caching. And your vendor files getting too big, what are some of the step you'd take to reduce the file size?
>> Sean Larkin: That guide that we talk about there, I don't think it's been upgraded to Webpack 4 yet.

[00:01:23]
And we'll talk about caching tomorrow as well. But If you're still on Webpack 3, I'll just say remove the comments chunks plugin. Basically caching is way less important than being able to minimize the amount of JavaScript you have on your initial download. So you can still split out the manifest, that's valuable.

[00:01:50]
When they say manifest it's really the run time, the bootstrap code. But I would say focus more on actually splitting your code with like the dynamic import statement
>> Sean Larkin: Instead of trying to force or synthetically create this spender bundle. Because at the end of the day, caching really only solves the time it takes for the network to retrieve an asset.

[00:02:18]
But the number one cost of a page loading slowly is the amount of JavaScript you have to parse evaluate and execute. So you don't get any winds there by creating these vendor bundles. So I would say like long answer short, turn the caching off, turn the caching features off.

[00:02:36]
And then just focus on trying to asynchronously load code that you don't need upfront.
>> Sean Larkin: Any other questions?
>> Speaker 3: Is there a lazy load plugin you'd recommend?
>> Sean Larkin: So lazy loading is code splitting in Webpack, and we have a plan to clear up these. So I'll give you a preview of what it looks like.

[00:03:04]
So let's say for example, we don't need this footer code. We'll make it as a scenario, and so it's kind of contrived here, but I'm just in our dev server. But let's just say, I would only want to load the footer when somebody clicks on that button, right?

[00:03:28]
So the first question you would ask is, well, if I'm going to load the footer only when the button's clicked, why would I load it up front, right? So this was the main reason Webpack was created, was to be able to support this case of lazy loading or code splitting.

[00:03:48]
So what we can do is we can just remove that footer and instead we just need to basically say, button.addEventListener, click, and now we have the event. So this call back is only gonna trigger when this event happens. And instead of having this footer statement, we can actually say something like const loadFooter.

[00:04:16]
So there's two ways to do it. I'd like to obstruct it out because it's easier to understand.
>> Sean Larkin: So this is called the Dynamic Important Statement. Webpack supports it out of the box, if you're using Babble you have to add another plugin to support the syntax. But typescript can handle it, so you don't need to do anything extra.

[00:04:38]
But stand alone without Babble or Typescript Webpack can read this and it handles the statement. So I would just pass the exact same, the footer. And I think what I'll do, let's see. Was that a default export?
>> Sean Larkin: No, it's not. Okay, so I'm just gonna say m, no, this is fine.

[00:05:04]
So all I've done is I've changed what was import footer from footer, right? So that's where we started, and I changed it to actually be this. Now, what we can do here is we will probably move this code, this document.appendChild-
>> Sean Larkin: Up inside of, is that the right way to do it?

[00:05:30]
Yeah, it is. Okay, I would add it inside this event listener, right? We'll need that eventually. But all we're doing is we're taking, we're actually gonna call this inside the event. So loadFooter and it returns a promise. So Webpack converts this statement into a promise itself that lazy loads a separate file.

[00:05:54]
So what I'm doing here is just saying I get the module and then I think it's probably end.footer.
>> Sean Larkin: We'll pull it up inside of the dev server here in a second.
>> Sean Larkin: So let's take a look and see if it worked. I usually console log or set a break point to make sure I know what it looks like.

[00:06:24]
>> Sean Larkin: All right, so we don't have a footer, and we do have a footer. So you can see, if we look at our bundles now, we've actually created a separate file, right? It's a completely separate bundle. And let's see.
>> Sean Larkin: We'll just load it again. So only when, so now, we're not incurring any of that code that's only needed until that user actually does something, right?

[00:06:54]
Or until some sort of asynchronous process happens. And so in this case it's a call back. So only when that happen does this code actually load. This is what's called, when we say code splitting or any Webpack maintenance to this code splitting, this is the process that we're referring to.

[00:07:11]
And so you don't need a plug in, it's actually just imperative as part of the code you write. That's what makes it so, I guess, I think it's so expressive and really powerful. Because literally all we've changed is just, we took the static import out, which would force you to have that code upfront, into a function that returns a dynamic import.

[00:07:33]
And so we just call that, and then we grab the export we need which is .footer, and we can just use it the exact same way.
>> Sean Larkin: Yep?
>> Speaker 4: Any tree shaking benefit over exporting individual functions instead of the class?
>> Sean Larkin: So this I'll definitely talk about tomorrow.

[00:08:02]
We have the first part of the day is all about web performance and the constraints and the limitations. So I'll give you the-
>> Speaker 4: Let's just defer it to tomorrow?
>> Sean Larkin: Yeah, I'll cover it tomorrow but I'll give the short answer now and we'll dive into it more tomorrow.

[00:08:19]
The short answer is, yes, methods on classes cannot be tree shaken even if they are not used. So I typically tend, when I'm writing for a web scenario, you can kinda see everything I write is a function, right? I'm either writing functions or just individual exports of values.

[00:08:37]
The reason why is because those can actually be statically tree shaken. So I usually tell people, I know the object-oriented folks are like, why? But, I usually say, either have classes with very small amount of methods where you can incur a little overhead of something that doesn't get used.

[00:08:56]
Or just switch to using a function. When you think about scope and object oriented, like modules are your scope. People used to create classes to scope things, but now you have this beautiful primitive that's literally a module. And so you can get dependency injection just using ESM. You could export, you don't even need a custom dependency injection system because you could have singletons or new instances any time using importing.

[00:09:27]
So the short answer is yes. You would be better off exporting individual functions and values and primitives, versus exporting a whole class.
>> Speaker 5: I just have one quick question if that's okay.
>> Sean Larkin: Yeah.
>> Speaker 5: So it's the same problem as npm in general, but, how do you go about finding good plugins versus bad plugins?

[00:09:50]
I mean is there a curated list or is there like-
>> Sean Larkin: Yeah.
>> Speaker 5: How would you go about it?
>> Sean Larkin: So that's a great question. So really we have a couple resources. Well, one, Webpack-Contrib hosts, we go out of our way to ensure we at some time eventually own a really popular third party plugin.

[00:10:12]
There are very few that I know of besides what the Chrome team manages. And that's for like their service worker stuff or like fire base or whatever or like Angular and theres. So we essentially house, Webpack-contrib is 90 repositories of loaders, and plugins, and some utility stuff. But we own most of them, almost all of them.

[00:10:38]
And so I would just say the best.
>> Sean Larkin: I would say the best way is just to look and see, kind of like, how maintained is it? What version of Webpack is in their tests? Is it 4 or is it like 1? A good example is I was looking up a loader, I was trying to find a loader.

[00:11:01]
So I was GLSL is for using 3js and I was like GLS loader. And I stumbled across this webpack-glsl-loader of course, you're like, there's 40 over them. So I think with the one I stumbled across that I really liked was the Webpack 1. But it definitely wasn't maintained, so much that like a PR that I've been trying to submit has not been, like, even resolved.

[00:11:32]
This one is pretty old too, right? If you look at it.
>> Sean Larkin: Yeah, and it's using like the old she-bang in here, too. To go grab raw-loader. So I think the best way is like glslfy, this is probably an old browserify plugin that got converted to a loader too.

[00:11:59]
So really the best way is kinda just like the same way you would approach anything else, how much is it contributed? How active are its commits? And it may just be, it's a finished module. There's some out there that are like that, but you can always tweet us and be like, Sean, is this legit or not?

[00:12:16]
And if you have issues, like we actively try to reach out the maintainers themselves, we're like hey, can we take this over, do you mind? Like we would love to get this off your back, and then it's like, we can curate it, standardize it, and make it consistent like the rest of them.

[00:12:37]
>> Sean Larkin: That would be probably the best way to find out.
>> Sean Larkin: Otherwise thank you guys for joining Day 1 and I will see you tomorrow.
>> Speaker 2: [APPLAUSE]
>> Sean Larkin: That's a wrap. [LAUGH]