 Stand right over it like this. Yeah, hi. That intro's sort of covered it. My name is Zach Green. There's my Twitter handle, zgreen underscore. You can find me on GitHub at zgreen. And I am a senior ex-dev at Ali Interactive. We work with, we're a digital media, or digital agency, and we work with large publishers, large media companies, that sort of thing, and we're a remote team. And we use Webpack for all kinds of things. And Webpack is a really powerful tool. You can do a lot with it. And today I'm gonna try and hone in as best I can on how we use CSS in Webpack together. So we're gonna talk about a few things. One thing we're gonna talk about is obviously the build process. If you don't know, Webpack is sort of a build tool. You can use it to compile and transpile and do all kinds of crazy stuff to your files. We're also gonna talk a little bit about community and ecosystem. When I say community, I'm sort of talking about like, I feel like there are some technologies that reach kind of a critical mass of adoption and also have a really good, you know, sort of, they're kind of lucky timing and they become really useful because of those things. And Webpack is one of those tools. It sort of rose as React was rising and now it's like developed into this, there's a really, really large ecosystem of plugins and loaders and docs and tutorials for kind of covering all manner of use cases, which is very cool. We're also gonna talk about Webpack kind of as a gateway to other front-end technologies. This isn't really a talk just about Webpack. It's sort of about the modern front-end stack in the context of Webpack. And I was trying to think of an apt metaphor and I couldn't, but I sort of thought of like if front-end web development is like one of those kind of shitty carnival funhouse rides that you go on. Webpack is like the car that you're stuck in that takes you through it. It sort of works because front-end development sort of feels like it was built up by carnies and gets shut down every six weeks and moved to another place, right? So, whatever. We're gonna talk a little bit about performance too and some ways that Webpack might be able to help you solve some common performance problems. And we're gonna talk about workflow. I'm actually sort of glad the timing of this presentation worked out well because a few folks have touched on this and a few other aspects of my presentation but they didn't go too far in the direction that I'm gonna go. So, I'm hoping this will be a good compliment. Sarah Drasner touched on this yesterday, this idea of flow, right? Where flow is kind of that feeling that you're just in the zone, you're enjoying what you're doing and you're having fun while you're coding, right? There's a really good talk by Bruce Howman who is a very talented closure script developer called Literate Interactive Coding with Dev Cards. I stole a lot of the ideas for this presentation from this talk, everyone should check it out. You don't need to know closure script at all to dig what he's doing but I highly recommend that talk in his work in general. One big takeaway that I got from it is that he argues that the primary mode of UI development is endless tweaking and that's the idea that most of the time if you're building and maintaining UI you're just tweaking tiny little values and checking your work and tweaking another value and checking your work and you do this forever, right? That's it, that's your job. Like you just tweak things forever and ever and ever and I feel like this maybe is no more true than in CSS, right? Where you're kind of constantly updating and changing values and checking how they look. So we're gonna talk a little bit about how Webpack can kind of grease the gears of this workflow a little bit and maybe make it better for you. This is from the Webpack docs. What is Webpack? Webpack takes modules with dependencies and generates static assets representing those modules. That's like one of the first things you see when you go on the website. I don't know about everyone else here. I find this description to be kind of opaque and hard to understand. I still, I've been preparing for this presentation for a few days, I'm still not 100% sure what it's really saying. And this is a criticism that a lot of people level at Webpack which is that it's kind of hard to grok the docs are kind of dense and hard to understand. There's some truth to that. Documentation is super hard, obviously, just like everything else. And I know the Webpack team is always looking for help with updating their docs, so definitely check that out. But I thought maybe instead of trying to parse this statement we could do a little walkthrough of Webpack and see if we can understand it a little bit better. So basically, Webpack can be used as a CLI and it looks for this file, this webpack.config.js. You run it from the command line. The config.js might be really long, it might be kind of short, there's a lot of stuff that goes on in there. We're not gonna look at all of it because it would take all day. But we're gonna look at a couple things specifically. Mostly we're gonna be down here in the object that's getting exported, right? The entry point here is what's getting bundled, in this case just a single file, app.js. And then more specifically, we're gonna look at the plugins array that gets passed and also this loaders array that gets passed to the module object in the Webpack.config. Don't worry if this doesn't make sense yet, we're gonna kind of walk through it. So a quick crash course in plugins, in loaders, in Webpack. Loaders basically pre-process files. That's kind of the idea. They use the require or import statement to work. They're very similar to tasks in other build tools. So if you're coming from grunt or gulp or who knows, there's all kinds of cool stuff out there. Loaders are kind of like tasks, right? And I sort of always think about them as, it's code that ingests files that you give it and just applies a series of transformations. So here we are, that's kind of stretched. Can you see this? Yeah? Cool, I don't wanna stand in the way. This is the, just an example of a require and import statement, right? There's nothing going on here. There's a native JavaScript. Webpack isn't doing anything in this case. But what Webpack does is it kind of hijacks or rides along on top of the import. So if I wanted to apply, for example, a Babbel loader to a JS file, I would do it with this kind of syntax here. Or just Babbel, bang, and then the file. Babbel might do all kinds of crazy stuff to my JavaScript if I wanted it to. So that's how that would work. The cool thing about this approach is that now you can import file types other than JavaScript. You can ingest in JavaScript syntax file types like CSS or HTML or Markdown. Really, there are loaders for almost anything and then Webpack can be made to understand them. So in this case, everyone can totally see this. I can't see it at all. Is that, yeah. Yeah, is that better? Cool, right on. Yeah, so we're doing a couple of things here on these CSS files. We're just applying two loaders. The CSS loader and the style loader. You see them chained here and they're separated by bang. You can also pass query parameters to your loaders using this syntax here. So in this case, we're just, we're passing the minimize parameter to the CSS loader to make it minimize some CSS that I'm feeding it. This gets a little hairy if we do this everywhere all over our code base. You can kind of imagine if you had to keep tracking your head of all the loaders that you're using on all the files that you're importing and maybe some of them use different loaders, that's kind of no fun. So most of the time, you're gonna set this up in, doing that, let me do a reload here. See if that works. Most of, anyway, most of the time, you're gonna set this up in your webpack.config.js. And this is a slow load, but I'll get to that in a second. And just to wait, we're reloading the bundle, it's doing something. I'm probably not on the right thing. I'm not, cool. Yeah, internet woes, sorry. Doot, doot, doot, doot. So I will, there we go. Well, okay, that kind of stinks that it's doing that. I don't know why it's so cut off. Can you see? Cool. So here we are in webpack.config.js. And in this case, we're doing a regex test for a file type, CSS, down here. And we're running a pair of loaders on that file type, CSS loader and style loader. That way we don't have to pass that to every import that we run. You can also tweak these and apply loaders on demand so you can disable the default from the config by using a double bang at the start of your import and then applying the ones that you want, like this. So if like I just wanted to use CSS and style here, I could do that. If I wanted to enable some other features here, I could do that. I'm not gonna talk a ton about plugins. Plugins basically inject custom build script, custom build steps into your build. And we're gonna look at one plugin specifically that makes that work. And that is the extract text webpack plugin. If you've ever used webpack and you've used it to compile CSS to a style sheet, you've probably used this plugin before. You use it basically like this, where you're just requiring it here at the top and now we're gonna pass it into the plugins array that we discussed earlier. And then down here in our loader, we're gonna call extract on extract text plugin and run the loaders that we want. And what this is gonna do is it's going to extract the CSS that's getting compiled into a style sheet, main.css that we can then use. Just a quick difference here. This is webpack one syntax and webpack two. Webpack two is either full release or beta, but very, very close. It's been a little bit since I checked, but keep an eye out for that. And here's how that works. So here we are in app.css. This is the gradient that's being applied, burlywood and corn silk. We import it here in app.js. We import the CSS file and it compiles and then we load it here. We link to it in the head, right? And we can change that if we want. So if I wanna go in here and maybe update that to like a value that's a little bit brighter, I can save it. We can go back over here. It will update for us and then we're gonna reload and then we're gonna wait and wait and wait. We just made a CSS change. Okay, there it's back, cool. So that's how that works. It's pretty easy to switch on SCSS too. You can use the sassloader to do that. You see down here we're passing sassloader into our loader chain and here we are in app.scss, the other change here is that we're updating our regex config so that it looks for both CSS files and SCSS files. And if we go into that file, which is extract.scss and we save a new gradient, I'll get updated and then we'll reload and we'll wait and wait. Made a CSS change, just waiting for it to load. Cool, a little brighter, nice. It's pretty easy to do, you just need sassloader and node sass, those are the two requirements for this. Let's look at the next thing in the loader chain, which is CSS loader. CSS loader does some things that you would expect a transformation tool on CSS to do, like minification and source maps and it does some things that you wouldn't expect it to do like enabling CSS modules, which I'll touch on a little bit later. The minification piece is powered by CSS Nano, which is a really powerful tool for minifying CSS. Definitely check that out, it's got a great CLI, it's post-CSS plugin, all kinds of cool stuff. So let's look at an example. Here we have a CSS file, it's got six, five selectors, there's some zindexes getting set, we're setting up a counter, pretty simple. And when we run CSS loader with minification, it's gonna come out like this. This is what webpack deems like a safe transformation, which means it basically just minifies everything. You'll see it's changed the counter to just a single character because that doesn't matter. So it shortens fewer bytes that way. But this is a safe transformation because we're not gonna break anything doing this. You can enable unsafe transformations in CSS Nano by passing additional query parameters here to CSS loader. So in this case we're passing minimize and the zindex reducer to the CSS loader, and that's going to actually run a reduce on our zindexes, so 1,000 becomes one, 2,000 becomes two and 1,500, no, 2,000 becomes three and 1,500 becomes, I'm doing that wrong, but you get the idea. Sub, sub, sub, sub, sub, middle, middle. That makes sense? Sort of? Cool. So that might be all that you need if you wanna start using webpack to compile some CSS. This is how I started using it. If you just wanna try it out and get it to write some CSS files for you and see how it feels, that's that you can do that just with extract text plugin. There's a but here though, and the but is that what we're doing is sort of moving against the grain of what webpack is meant to do and how it's supposed to work. Extract text plugin is kind of a bummer. It's a useful bummer, it's writing CSS files for us, but webpack really understands styles as data and wants to manipulate them and handle them that way. You might have noticed that there's one real problem here which is that every time we make a CSS change, we have to reload our page and it's really slow. It takes forever. It's taking a particularly long time because I'm actually throttling the request for demo purposes, but this is an interruption to your flow to change one line of CSS and then wait for a reload. It's kind of a drag. You can automate this a little bit using the live reload plugin. I'm showing you an example here so that when you save a CSS change, it will automatically reload your browser. But even then, you gotta download everything again. You might have a bunch of app code that runs. You might be on a local server that's got a bunch of other stuff coming into it and to iterate on a user interface with this kind of a flow is pretty bad. It's not fun and it really breaks up your flow as you're trying to work. There's another problem too which is that we're render blocking. We've got this style sheet in the head and we have to wait for it to download before we can see the page. So that's not cool. Webpacking fix this. And we fix it actually by just taking things away. We just stop using extract text plugin altogether and we just use style loader. So let's take a look at how that works. If I go into my file and I update a value and I save it, you'll see it just update, right? Now, this bundle is a little large so that update will take some time depending on how big or small your bundle is but we've like eliminated the reload just by no longer using extract text, right? And this is a small example but once you start using it to write all of your CSS, you'll find it like so much nicer and all of these kind of roadblocks go away. You stay in the zone a lot better and it's actually just more fun to write it this way I think. This is what the webpack config looks like in this case. Pretty simple, right? And this is how it works. It's a two-step process basically. We are loading a JavaScript bundle asynchronously at the bottom of the page. When it loads, it injects in style tags the styles that you've authored just like that which is pretty cool. This is a quote from Jed Schmidt who is a talented JavaScript developer. He said the worst things about CSS are cascading and sheets. I'm not arguing in favor or against that statement. I just wanted to put it up here to kind of give context to what we're looking at. But what we've done here obviously is we've removed the sheet, right? There's no sheet anymore. Putting in style tags. So we've solved a couple problems. We're not render blocking anymore which is really nice. You probably want to pair this with like a critical CSS solution, something like that so you could get some styling at the top of your page. We're hot reloading which is really nice and I want to emphasize like, you don't just use this for CSS, use it for everything, use it for JavaScript, use it for HTML. You can hot reload all your code if you want to. And the other thing that's really cool about this is there isn't, you don't need a framework to make this work. You don't need to be writing React or Angular. You don't need to be in a single page application. You can just use this on a plain HTML page or like Ali where I work, we work in WordPress a lot and this is a solution we often use for loading styles. So I think when a lot of people think about webpack they think about it in the context of React and single page applications. It's powerful enough and flexible enough to kind of let you work outside of those environments. We're also kind of keeping it simple now which is cool. We've removed the extract text plugin from our config. We removed our style sheet. Everything is still working and our flow has improved. So anytime you're kind of like deleting things and everything still works and you're actually working faster those are like kind of good code smells, right? This feels good. In that vein, we should talk a little bit about Post-CSS which I think can kind of help you move in the same kind of direction. Post-CSS you enable with a loader just like other things in webpack. Turn it on here, see? We're just chaining it in the loader here. Post-CSS then CSS then style loader. And now in addition, we're gonna pass a method into the exported object here, Post-CSS. Which returns an array of the plugins that we wanna use to transform our styles. And what I've pasted here is kind of like a boilerplate set of plugins that I often find myself using when I'm writing Post-CSS. When I'm writing CSS and using Post-CSS to transform it. So let's take a quick look at how that might work. If we're here in app.css This isn't an SCSS file, we're just in a CSS file but we can import other CSS like you might in SAS. We can set custom properties. These are not real custom properties. These are actually just variables in the context of Post-CSS so they don't function like a real CSS custom property will. I'll show you how the transform looks in a second. We can set custom media queries. We can nest styles if we want to and we can actually do some basic math too down here. And here's what the transformation looked like. Again, this is gonna get inlined in the document head, a style tag. Here's the styles or the CSS file that we imported. You'll see everything got nested properly. Our custom property got transformed into a static value. Our math was performed, that's kind of a cool thing. It's like a calc reduction here. It's just dividing 10 by 16 to get an M value. And we're also getting some auto-prefixer action going on there. It's kind of cool. This is kind of like a little aha moment for me when I hit it, I was like, oh, this is like, kind of like SAS but I'm not using SAS anymore. That's neat. You can use them together if you want to and a lot of people do. If anyone uses SAS and uses auto-prefixer, you're already doing that because auto-prefixer is a post-CSS plugin. So you can chain the loaders in Webpack if you want to. You might not need to though, which is cool. There's a few reasons. Post-CSS can be faster than SAS. Your mileage will totally vary. It depends on the size of the string that you're transforming and the nature of the transformations that you're making. But you may find it to be significantly faster when you build. I certainly have. Another thing that's cool about post-CSS is that the same transformations as SAS are possible along with many, many more because post-CSS has a plugin-based architecture. You can write any transformation that you want. It raises the question, if you're already using post-CSS for something like auto-prefixer, why not go the extra mile and simplify your build by removing SAS altogether? And then the last point is something I've thought more about recently in the last year is that this idea that maybe a tool like SAS was giving me more than I need. I don't like to use, for example, Mixins or Extends in my code. Miriam talked a little bit about how opinions come from Mixins, and I think that's totally true. And so we were writing SAS and we were ending up with a lot of custom shorthands for things with all this Mixin logic that was really a bummer. And I wrote a lot of that code, so I learned from my own mistakes. But with post-CSS, you can explicitly define the transformations that are possible on your code through Webpack, right? So if I only want to use a certain amount of transformations, I can explicitly define those. And then any other dev that jumps into my project bumps into those same directions. And this is sort of the idea that some restrictions, especially when you're working with a large team, have a project that a restriction can actually be a helpful opinion and can help kind of keep your code base behaving in an expected way. So let's take a look at some fun stuff, too. CSS modules. A few people touched on this. I wanted to just take a quick look at it. CSS modules comes along with CSS loader. You enable it as a query param right here. And it kind of works like this. In our app.css, we have a selector. You can import that in your JS file. And this is a ES2015 template literal where I'm just adding the class here. And then when you compile it, it's going to turn your class name, my class, into this crazy hashed class, which is just this gobbledygook of characters. And you would then get the same thing in your template literal. That might look super weird, but it's actually kind of awesome because what's happened here is we've locally scoped our selector. This is guaranteed to be unique. And we are not going to have any naming collisions. We don't have to rely on a naming convention to guarantee that our selectors are unique. We're moving our CSS out of the global scope entirely. That example wasn't super readable, which is kind of a bummer. But you can enable that with a separate query param like this. I'm not going to go into what all of those key keywords are, but this comes from the web pack docs. And then instead of that long hash string that's really, really hard to read, you're going to get a selector that still is readable and has the context that you gave it, but is also still guaranteed to be unique and localized. So now when you kind of inspect your styles, you'll still be able to see where they're coming from. I'm fairly certain there's a way to enable source maps with this too. I find often that source maps are more trouble than they're worth just because they slow down the build. But that's sort of a personal preference. That's really cool. Local scoping in CSS is so nice. Yeah, it sort of changes the way that I've started to think about CSS. I'm going to bring us back to that Judge Schmitt quote, where he talked about really not liking the cascade and style sheets. The CSS modules kind of eliminates the cascade because if you don't use any descendant selectors and all of your class names are unique, the cascade doesn't matter anymore. I know people have different opinions on whether that's a good thing or not. I sort of think on large projects, the cascade behaves like a bug. So far, I've only showed you examples in JavaScript, which is cool, but maybe it doesn't have a ton of real-world application. So we should look at post-CSS modules too, enabled in Webpack. And this is going to let us use CSS modules on the server, which is also really cool. So instead of passing the modules query param to the CSS loader here in our Webpack config, we're instead going to enable this post-CSS modules plug-in and pass the scoped name down here. And that's going to do all of the same things that CSS modules did in the last example. But in addition, it's going to output a JSON file, where the keys and values are the class names that you defined and the hashed class names that come from CSS modules. And you'll see here in a super contrived example that I just threw together, imagine if you were in a PHP template or something, and you wanted to read that JSON and then output the hashed class in the template file, you could do that. That's just PHP, but really if you're writing in a language other than JavaScript that can understand JSON, you can use CSS modules server side. I haven't used this in a production environment. I just think it's kind of a cool technology, the server side piece, specifically, I mean. And so we're sort of experimenting a little bit here. I want to look at one more thing, which is post-HTML. Post-HTML is a pretty new technology. It's principally similar to post-CSS, but the idea is that you take an HTML or an HTML-like file and you apply a set of transformations onto that file through plugins. So in this case, we're using the post-CSS loader here in Webpack, along with some other loaders. And down here, we're using this post-HTML CSS modules plugin and passing in that JSON file that you saw here. And that means that we can do cool stuff like this, where in our input HTML, we can define a CSS module here and we can perform a transformation on it and get the hash class name on the output HTML. Kind of cool. Yeah, so that's sort of the spiel of Webpack and CSS and like dev-ing on the front end with Webpack. If anyone has any questions, please come and get me. Afterward or up here. And thank you. Appreciate it. Come to Inside the Dev Studio. Thank you. Yeah, it's cool. Cool, we'll just keep this thing up. Sweet, so a couple of questions for you. How are you using Webpack with HV2 and bundling? I tried to do it on a project recently and actually got bit by another problem all together which is that the project that we were building it for wasn't going to be running HTTPS. And you can't use HTTPS without HTTPS, so it was a non-issue. I've still yet to actually hit a large client project that I can use HTTPS on. I'm waiting for it to happen. I'm sure it will, but I still feel like the technology hasn't caught up with it, especially if you're working with clients that serve ads. A lot of ad code is not secure and doesn't even let you run HTTPS, so it won't even be possible. There's been some really cool things written by Khan Academy about HTTP2 and Webpack, so check out what they've written. Are you doing any type of bundling in your JS where you're splitting it out and making use of Webpack's features that allow you to create smaller bundles? Yeah, for sure. That's one of the best parts about it. I wanted to talk about it here, but it was going to take me too long, so I left it out. But code splitting is huge. You can essentially break up your JavaScript bundle so that you have one common bundle that's getting loaded everywhere, and then based on routing or other sort of conditionals, you can load asynchronous bundles on the fly, which will really help improve performance and cut down on the build time, too. It's a really neat technique for performance, getting over that. How are you deciding how to split your bundles? That was a question that I had. Yeah, it depends. You can kind of manually do it if you want to just play around with, OK, here's a condition where I bundle once and here's a condition where I bundle again. More often than not, the simplest way to do it is just split out your vendor files. So if you're loading libraries or something, split those into a commons chunk or something like that and then load that. That's what we're doing more often than not. If you're really building a large SPA, you're going to want to do something more involved. Are you using this type of bundling in conjunction with any other techniques, like preload, where you might load one of your bundles on your home page, and then start preloading and pre-fetching for the other ones? Yeah, that's a good question. I'm not. No. I think it's a cool idea. I haven't really had a chance to play with that, but I'm super excited about it. I am too. I haven't had a chance to play with it. I'm just going to see if you knew. Oh, yeah. Another, I've actually been chatting a lot with folks about Webpack. We're using JSPM, and I want to move us over potentially. But are you using Webpack in conjunction with any other build tools? So when we use it, we run the tasks in NPM. So you just set up the commands that you want to run in NPM and run it that way. Because you can do a lot of your steps in Webpack, a lot of it ends up getting contained there. So we're linting. We're doing that in the Webpack build. And obviously, like any transpilation is going to happen in there, too. So for the most part, no. Webpack is going to handle it all. You might have some custom node scripts that we might write for specific things. But mostly, yeah, it's happening in Webpack and just running the tasks with NPM. Cool. So you've gotten rid of Gulp or Grunt. Were you using those before? Yeah, totally. And those are great tools. Yeah, no, I remember the first time I used Grunt. I was like, oh my god, this is so fun and great. And Webpack feels kind of like an evolution of that for me. Yeah, I think the thing that I've let slightly reticent about is Webpack is all the configuration, which I think if you're coming from Grunt, you're just like, OK, I get it, configuration. But when Gulp for me was like, great, Stream's so nice. Yeah, it's like the one part. No, I agree. Yeah, the config is the most hated thing about Webpack. And there's some justification for that. But I also want to emphasize it doesn't have to be super complex. There are some good boiler plates up there. I've got one on my repo, on my GitHub that I use for personal projects. So it doesn't need to be this big thing that everyone has to know about and manage. It can be a pretty lightweight thing. And the docs, while they are sometimes difficult to parse, are super, super thorough. So do check that out. Yeah, I've definitely found the docs a little like, whoa, what's going on here? So you had a slide up about community and Webpack. And community is something that I think is so valuable around open source tools. I'm a big ensass. And to me, it's like a badge of a community and a sign of what we believe in even more than a technology. I mean, it is a technology. Can you talk a little bit about the Webpack community? Yeah, I mean, I don't want to speak specifically for the repo maintainers and stuff. I'll just say like, I'll talk about it in the context that I kind of have encountered it, which is like, as someone who wanted to try out these tools and then started using them and then started using them on client projects, I found that there was just such a wealth of information out there. And that information comes from official sites, like the doc site. But it also comes from people just posting tutorials and writing a blog post about how they started using Webpack to do X or Y. And I feel like those technologies that can kind of reach people that way and get them to offer those things up online, open source, that makes a really big difference to someone like me who is just trying to kind of find my way through something in the dark, because mostly that's how I learned how to do things, right? It's just like, change this. What works? What breaks? Help me, sort of like that. That's the best part about coding, right? Always have to break it. I mean, it's not really broken. It's just like, in the moment in time, it's a little broken. So do you have any thoughts on how Webpack will revise itself as some more of these tools come into the browser? And I know Systemloader is one for ES6. Yeah. Some. There's been some written recently about how Webpack's bundling logic may be kind of making the bundle size larger than it needs to be. So specifically, if you imagine you're importing the same module multiple times throughout your code, Webpack may not be optimizing that in the way that it should. Webpack 2, I think, adds tree shaking, which is this idea that if a bundle gets imported twice, it shakes the tree and then drops the reference to one of the modules, because it doesn't need to be there, which should dramatically cut that size. There's a sort of alternative out there right now called rollup that people are using, which looks really, really awesome. And I actually know there's been some discussion in the Webpack repo about trying to merge aspects of rollup into Webpack 2. They definitely seem to take the performance implications of that seriously. Yeah, we use rollup. It's great. Definitely a tool to check out for folks for reducing the size of your bundles. It was kind of crazy talking about weight, like the size of our repos and our bundles and our NPM node modules folder, like all of these things that make our lives easier. And then in some ways, you're just like, whoa, look at all this stuff now. Yeah, it's true. Yeah, I mean, if you open your node modules folder, you're going to be terrified. And that's kind of a problem, I think. I feel like people are sort of starting to think about that a little bit more. But yeah, I don't know. Like I was sort of saying, the carnival funhouse ride, I feel like Webpack contains the madness a little bit for me and kind of lets me take advantage of the parts that I like and that seem helpful and not have to fight with my tools, which I don't like to do. On that, is the only way to get hot reloading with style loader? And if that's the case, does that mean that one has to go this route of basically injecting your styles on the page? I think that it's impossible to get hot reloading with extract text plugin. I tried for a while and failed. There's a different loader called extract loader, which is slightly simpler. So maybe it's possible with that. But I don't think that's as good at compiling as the extract text plugin is. So my answer in my experience is no. There's no way to write a sheet and hot reload that. But there are smarter people out there than I am, so maybe they've solved that problem too. So how does that affect performance at all of the pages? Is it because JavaScript is loading async? So by then, you've got your complete DOM document, so it's just inserting it and it's not really going to affect it? Yeah, that's exactly right. As long as you're loading it asynchronously and you're letting the DOM download, you really should pair it with a critical CSS solution for sure, because otherwise you just kind of get totally unstyled content for a while. But at least your content's there, right? At least it's loaded and you haven't blocked the render with your CSS, which is silly. And then how does this work? Because I think one of the good things about having the sheet is the sheet is cacheable. So are you also caching your HTML pages or not because of dynamic content? No, no, that's a really valid criticism. I've found on the projects that I've worked on, the benefit that I get from going the style loader route kind of outweighs that potential problem, but I think it depends, yeah. It always depends, right? The flow chart of making decisions in web, which is like, well, there's some option and then there's the it depends option. Yeah, and I sort of feel like, to a certain extent, like if you're making, you have to be allowed to make bad decisions with this stuff, so that's the only way that I can learn, so. So what bad decisions have you made with webpack and this stuff that you're like, oh my gosh, I'm never gonna do that again? Because it's like, you can set up the config to do all kinds of crazy things and it can have all these separate entry points and you can import your node scripts and it can be just a disaster for someone who's coming in to look at it and try and use it. And that's a problem that I've bumped into in the last year or so, where it's just too complex, right? So I'm constantly trying to make that better for people and make sure it's simple and easy to reason about when you jump into it. Great, all right, well thank you so much. Really enjoyed your talk.