Hacker News Reader

Comment by vlunkr | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

The save system is next on my list of write-ups.

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.

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

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.

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.

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.

Reply on news.ycombinator.com