Hacker News Reader

Comment by tptacek | Hacker News Reader

Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it.

What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?

Thanks!

View on HN

You can run "webpack-dev-server", which uses your Webpack configuration to serve your scripts with its own web server.

That means (1) it can do incremental recompilation, which I can't live without since my build takes 20 seconds; and (2) it can block requests while compiling, which is way better than having a background thing (e.g. watchify) recompile your code, since it means you're never interacting with a stale (or god forbid partial) compile.

The dev server also does automatic page reloading on recompile via some injected script magic. In my case that means I often don't even need to alt-tab to see my updates, like if I'm messing around with styling.

Webpack also has a whole paradigm that expands the use cases of require() in a pretty interesting and useful way. For example, you can tell it that require("../../icons/lolcat.png") should resolve to "static/lolcat.[8 chars of base64 SHA-256].png" and also do the appropriate file copying. Or you might want require("./stuff.csv") to resolve to a parsed JSON table, or any such transformation. There are a bunch of plugins for common uses. It's common to use require() even to load your CSS, because then Webpack can handle running it through your auto-prefixer or whatever.

It might seem kind of bloated, and I love Browserify for its simplicity, but I've come around to really like Webpack now that I've spent the proverbial 4 hours.

FYI, browserify has support for all the cool tricks you list too now; it's just a question of finding and wiring up all the right plugins.

Eg, lessify, css-modulesify, or csvify will handle the cool require tricks, browserify-hmr does the fancy hot module replacement, watchify has incremental recompiliation support if you manage to configure it just right, etc.

Mind you, I find webpack easier to configure (all the fancy browserify plugins destroy it's simplicity), but the two toolchains have had feature parity for a while.

Oh, I didn't know that, thanks.

Befor ditching browserify for webpack, do check out https://github.com/ForbesLindesay/browserify-middleware gets the job done just fine

I think Webpack has the monolith advantage here. It allows you to add things that would otherwise be immensely complex with ease because it can do a lot. You can have it handle bundle splitting and async loading of modules, image optimising and hashing, CSS/SASS/... processing, ...

Since we started using Webpack where I work we've stopped using all other build tools. There's very little Webpack can't do, and the main advantage is that there's no need to hook things up to eachother since it's all part of the same system.

So a big reason to use Webpack is that I can replace both Gulp and Browserify with it, and have one fewer component?

Yes. Also, it will build faster and the configuration will probably be simpler. That's been my experience having used Browserify with Gulp and Grunt for 2 years and then switching.

Webpack does everything Browserify does, but arguably if you're used to both the configuration is marginally more transparent (although still terrible). Also, arguably, new features tend to land in webpack a LITTLE earlier than browserify, which might be important to you in rare cases.

In short, I've used both, and I'm currently happy with webpack, and I have a decent configuration on my current project with a dev server, good production builds, support for CSS modules, and hot module replacement, all of which I could have in browserify.

Oh, webpack makes it a lot easier to dispense with gulp; my last browserify config was driven by gulp, but my current webpack config is just driven by a few lines of vanilla node.js code, which is kind of nice.

> What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?

Probably none of them. But if I had two boilerplate configs, one using gulp+browserify and the other webpack, I'd choose webpack because I think it's VERY SLIGHTLY clearer and more maintainable.

Thanks (to everyone who responded!)

I feel like I get it now.

I'd probably look into switching to Webpack on future projects, but I'd rather french-kiss an angry squirrel than spend a half a day wrestling with my app bundling code again, so I'll stick with Browserify for this one. :)

Here's their comparison with browserify and others: https://webpack.github.io/docs/comparison.html. Personally, I use browserify because it is ultra simple to get set up. No config file, gulpfile or anything and I'm using es6 and watchify to auto recompile. We use webpack at work, it's more performant and has some nice features, like using it manage your css and images as well, but getting it set up can be a headache.

I found code splitting feature useful. It's insanely easy to lazy load partial script.

https://webpack.github.io/docs/code-splitting.html

If it works for you stick with it. I started with webpack for the same reason-- I wanted to use ES6 syntax, and a coworker had some boilerplate that did most of the work for me.

Reply on news.ycombinator.com