4 ms·

For the life of me I can't understand why webpack has become the de facto build tool. It's so much more complex than anything else I've tried. I understand it's

by vlunkr 10y ago

For the life of me I can't understand why webpack has become the de facto build tool. It's so much more complex than anything else I've tried. I understand it's supposed to be faster, but still, I wouldn't bother with it until your build times actually start to become a nuisance.

deleted 10y ago
[deleted]
fenomas 10y ago
I don't think webpack is best considered as a build tool. It's primarily a dependency wrangler - it lets you define entry points, which can declare arbitrary dependencies on assets, which can then declare their own dependencies, forever and ever, and webpack will wrangle all that into a single JS file, a single CSS file, or whatever it is you need. As it happens one can also do build-tool stuff (transpiling, prefixing, etc) on the resulting files, but that's not where the magic is.
djokkataja 10y ago
I switched from browserify to webpack when I started writing ES6 on the client because the browserify build times with ES6 were slow enough that they felt disruptive to my workflow (somewhere between 10-30 seconds, I don't remember the exact amount). I'm not sure if that's improved now for Browserify, but it's the kind of thing that you're not likely to switch back from once you have a working setup.
- dwaltrip 10y ago
  I use watchify [1] for incremental builds. The initial build is still long (10 - 30 seconds, as you said), but with each change after that the build updates in < 1 second. [1] https://github.com/substack/watchify https://github.com/substack/watchify
tboyd47 10y ago
Webpack got swept along in the React zeitgeist. Few people who use it really take the time to understand it. It's a pretty slow way to build a project, but that's actually not the main sell. The main sell is in smart asset chunking, and it's pretty darn good at it. That alone earned it a place in my skillset.
- ng12 10y ago
  Absolutely. Finding out about code splitting was incredible -- I was able to get on-demand loading of resource files working in about ten minutes. One of the most amazing "it just works" experiences I've ever had.
drhayes9 10y ago
webpack allows some pretty sophisticated resource pipelines that go beyond what you can do with browserify, especially around binary resources. One of my use cases is working on a HTML5 game. I pre-process all the tilemap levels to add unique IDs to the entities within the file, but only for those JSON files that look like tilemaps. Each of those files' names get mangled as a hash of their contents as well, so I get some cache-busting for free. Similarly, I can pngcrush the image assets that pass a certain rule, etc.
- tboyd47 10y ago
  Awesome. Guessing you wrote your own Webpack loader for tilemaps? I'd love to hear more about what went into that. I had the same reaction as GP when I first saw it (meh, just another overly complex tool, who cares) but you can really do some ridiculously cool stuff with it. I also love how stable it is, compared to the ecosystem it's associated with.
  - drhayes9 10y ago
    Sure! Here's a short write-up I've been meaning to do that you spurred me into: https://drhayes.io/secret-game/map-entity-loader.html https://drhayes.io/secret-game/map-entity-loader.html The save system is next on my list of write-ups.
Illniyar 10y ago
Webpack replaces Browserify. Browserify, while groundsbreaking, turned out not to be so good and much harder to extend. Since webpack is not straightforward to use with other build tools, and since it can do most build actions easily enough, people use it for whatever they can get away with, and that usually means most of what you'll use grunt or gulp for.
badthingfactory 10y ago
What else have you tried? All of the alternatives have left me compromising on the way I build my front ends. The docs for Webpack aren't great, and configuring it might be a bit painful, but if there's a better option I would love to know what it is so I can start using it. Things I want: * es2015 transpiling * jsx support * css/less/sass support * module loading * uglification for production builds * hot module replacement * source maps * multiple bundles/entry points * hashed file names Brunch fulfills a lot of these requirements, and I use it when I need to spin up an application really quick. But it misses on just enough items to make me reach for Webpack when I build anything serious.
- mikewhy 10y ago
  parched-tasks-webapp has all but one of those things (hashed file names), and it's just built on browserify. And you don't have to do weird things to get your CSS out of your JS on the server.
  - davidjnelson 10y ago
    Why not just use css modules with the extract text plugin to put everything in a single stylesheet to solve that problem? For Dev it supports hot reload, and other environments get an extracted stylesheet that works with sever rendering and avoids fouc's. Plus you can autoprefix the output, and because of the css modules design you get encapsulated component css for free. The annoyance is working with a css framework or its js library, i.e.: bootstrap or material as each one seems to have a different approach to css dependencies. But I think those frameworks are becoming less relevant or can have their limitations worked around usually depending on which one you choose.
    - mikewhy 10y ago
      When using browser-sync, which parched-tasks-webapps does, CSS is already hot-reloaded, and there's no worry of configuring different "loaders" for the case of a javascript file on the server trying to require a CSS file. In both cases, the page is loading an external stylesheet, so both are as susceptible to FOUCs as the other. This is only my opinion, but using CSS loaders backs you into a corner where your javascript file is suddenly less portable, since the environment it will be running on needs to be aware of it.
shados 10y ago
because real webapps, that actually do stuff that can make money and keep users happy, are complicated. Even now, Webpack is kind of feature anemic compared to what the real world needs. We just do with what we have. Or in the case of companies with $$$ to hire devs to work with it, we just build a shitload of plugins and loaders.
davidjnelson 10y ago
It's complex but it's worth learning. You can do a lot with it; transpiling, bundling, source maps, css modules, autoprefixing, concatenation, minification, etc. Along with npm scripts and a little shell scripting you can pretty much do whatever your project needs, including auto Dev deploy, ci, one touch versioned stage/prod deploys with rollback etc. And it seems to be the common base people are building the best plugins for these days. It's far less verbose than grunt or gulp, and plugins are not needed for every little thing as a wrapper. But when you need plugins, there is a great system for them, and a ton of community plugins available.

by vlunkr 10y ago

deleted 10y ago

[deleted]

fenomas 10y ago

I don't think webpack is best considered as a build tool. It's primarily a dependency wrangler - it lets you define entry points, which can declare arbitrary dependencies on assets, which can then declare their own dependencies, forever and ever, and webpack will wrangle all that into a single JS file, a single CSS file, or whatever it is you need. As it happens one can also do build-tool stuff (transpiling, prefixing, etc) on the resulting files, but that's not where the magic is.

djokkataja 10y ago

I switched from browserify to webpack when I started writing ES6 on the client because the browserify build times with ES6 were slow enough that they felt disruptive to my workflow (somewhere between 10-30 seconds, I don't remember the exact amount). I'm not sure if that's improved now for Browserify, but it's the kind of thing that you're not likely to switch back from once you have a working setup.

dwaltrip 10y ago
I use watchify [1] for incremental builds. The initial build is still long (10 - 30 seconds, as you said), but with each change after that the build updates in < 1 second. [1] https://github.com/substack/watchify https://github.com/substack/watchify

tboyd47 10y ago

Webpack got swept along in the React zeitgeist. Few people who use it really take the time to understand it. It's a pretty slow way to build a project, but that's actually not the main sell. The main sell is in smart asset chunking, and it's pretty darn good at it. That alone earned it a place in my skillset.

ng12 10y ago
Absolutely. Finding out about code splitting was incredible -- I was able to get on-demand loading of resource files working in about ten minutes. One of the most amazing "it just works" experiences I've ever had.

drhayes9 10y ago

webpack allows some pretty sophisticated resource pipelines that go beyond what you can do with browserify, especially around binary resources. One of my use cases is working on a HTML5 game. I pre-process all the tilemap levels to add unique IDs to the entities within the file, but only for those JSON files that look like tilemaps. Each of those files' names get mangled as a hash of their contents as well, so I get some cache-busting for free. Similarly, I can pngcrush the image assets that pass a certain rule, etc.

tboyd47 10y ago
Awesome. Guessing you wrote your own Webpack loader for tilemaps? I'd love to hear more about what went into that. I had the same reaction as GP when I first saw it (meh, just another overly complex tool, who cares) but you can really do some ridiculously cool stuff with it. I also love how stable it is, compared to the ecosystem it's associated with.
- drhayes9 10y ago
  Sure! Here's a short write-up I've been meaning to do that you spurred me into: https://drhayes.io/secret-game/map-entity-loader.html https://drhayes.io/secret-game/map-entity-loader.html The save system is next on my list of write-ups.

Illniyar 10y ago

Webpack replaces Browserify. Browserify, while groundsbreaking, turned out not to be so good and much harder to extend. Since webpack is not straightforward to use with other build tools, and since it can do most build actions easily enough, people use it for whatever they can get away with, and that usually means most of what you'll use grunt or gulp for.

badthingfactory 10y ago

What else have you tried? All of the alternatives have left me compromising on the way I build my front ends. The docs for Webpack aren't great, and configuring it might be a bit painful, but if there's a better option I would love to know what it is so I can start using it. Things I want: * es2015 transpiling * jsx support * css/less/sass support * module loading * uglification for production builds * hot module replacement * source maps * multiple bundles/entry points * hashed file names Brunch fulfills a lot of these requirements, and I use it when I need to spin up an application really quick. But it misses on just enough items to make me reach for Webpack when I build anything serious.

mikewhy 10y ago
parched-tasks-webapp has all but one of those things (hashed file names), and it's just built on browserify. And you don't have to do weird things to get your CSS out of your JS on the server.
- davidjnelson 10y ago
  Why not just use css modules with the extract text plugin to put everything in a single stylesheet to solve that problem? For Dev it supports hot reload, and other environments get an extracted stylesheet that works with sever rendering and avoids fouc's. Plus you can autoprefix the output, and because of the css modules design you get encapsulated component css for free. The annoyance is working with a css framework or its js library, i.e.: bootstrap or material as each one seems to have a different approach to css dependencies. But I think those frameworks are becoming less relevant or can have their limitations worked around usually depending on which one you choose.
  - mikewhy 10y ago
    When using browser-sync, which parched-tasks-webapps does, CSS is already hot-reloaded, and there's no worry of configuring different "loaders" for the case of a javascript file on the server trying to require a CSS file. In both cases, the page is loading an external stylesheet, so both are as susceptible to FOUCs as the other. This is only my opinion, but using CSS loaders backs you into a corner where your javascript file is suddenly less portable, since the environment it will be running on needs to be aware of it.

shados 10y ago

because real webapps, that actually do stuff that can make money and keep users happy, are complicated. Even now, Webpack is kind of feature anemic compared to what the real world needs. We just do with what we have. Or in the case of companies with $$$ to hire devs to work with it, we just build a shitload of plugins and loaders.

davidjnelson 10y ago

It's complex but it's worth learning. You can do a lot with it; transpiling, bundling, source maps, css modules, autoprefixing, concatenation, minification, etc. Along with npm scripts and a little shell scripting you can pretty much do whatever your project needs, including auto Dev deploy, ci, one touch versioned stage/prod deploys with rollback etc. And it seems to be the common base people are building the best plugins for these days. It's far less verbose than grunt or gulp, and plugins are not needed for every little thing as a wrapper. But when you need plugins, there is a great system for them, and a ton of community plugins available.