Hacker News Reader

Comment by bshimmin | Hacker News Reader

What's the current thinking as of 2016 about Browserify versus Webpack? We've been happy Browserify users for a couple of years now, but I'm drawn to both the code splitting and dynamic expressions parts of Webpack.

On the other hand, I'm not keen on introducing more complexity or changing things just to be "fashionable", and Browserify, Babel, and Gulp do work together reasonably well for us (though I didn't much enjoy getting it all working in the first place, and I'm always nervous about updating any of them).

View on HN

I think Browserify is an excellent tool. It does the one job I generally need it to, importing dependencies so I can write modular JS code. Running it is a one-liner, and running it with Babel is one extra option. Its behaviour is reasonably transparent, so you can look at the actual output and see what is really going on even if source maps aren’t helping for whatever reason.

Personally, I’m not such a fan of Webpack. It trips my “too complicated” alarm, like RequireJS before it. I’ve never worked on a project that needed the kind of dynamic behaviour these tools support, and you pay a price for that flexibility in the complexity of the tool and the output it produces. Likewise, while you can include almost anything as part of your bundled JS output with Webpack, I’ve seen few real world cases where this is a significant advantage, and again you get locked into Webpack and its complexity as the downside. Perhaps on some types of project the features Webpack offers represent more compelling benefits.

For perspective, I’m also not a fan of tools like Gulp, also on the grounds that their ecosystems tend to be fragile and they add unnecessary complexity to what is usually a pretty simply operation in the first place.

I selfishly want more people like you in the javascript ecosystem. I had a debate with a freind if mine about gulp. My argument is that all of these tools are useless since they can be done without them. If only certian tasks should be run, create a commander script that takes in amount of args and runs each of those tasks.

His argument is that these gulp and grunt files standardize build and test scripts. Now its something you can definitively check off a list and when looking at others code have a form of familiarity.

I personallt agree, complexity and extra wrappers around what is already working makes little sense. But there are reasons these types of frameworks exist

I guess I just don’t see what benefit is gained by writing a dozen lines of fragile boilerplate to run Browserify via Gulp. If you want to put the build automation in a well-known location, a typical Browserify+Babel build is one line in the scripts section in package.json that says something like

    "js": "browserify src/index.js -o dist/index.js -t [ babelify --presets [ es2015 ] ]"

If you need more complicated configuration, you can use separate sections of package.json to set useful defaults, which is also the common convention for build tools in the Node/NPM ecosystem.

Again, I agree. Picture this: mocha gives testing globals, browser offers the window and dom, node offers process arguments. Coming from a partial teachers perspective (well, I wasnt hired to teach but I did talk to the students alot) gulp seemed to offer comfort and order in a world where "you can do anything" seems to cause imobilization. That problem I believe can be solved through introducing students to a philosophy of "you are in control, machines are dumb, only google can save you" but I can see where seperation makes people much more comfortable

> My argument is that all of these tools are useless since they can be done without them.

My gulpfile.js minifies several application modules and 3rd party libraries into a small set of modular, organized files. A polyfill is included. ES7 is converted to ES5. Bootstrap 2 libraries are upconverted to BS3. BS2 icons and BS3 glyphicons are converted to font awesome. Image URIs are transformed/replaced on disk dynamically and in CSS/JS references to my modular preferences. Public access keys (rollbar, stripe, etc.) are injected into my builds from .env variables. Tiny changes can be injected into libraries until the maintainence cost of a fork becomes less than the cost of a replace. This script can be called with one command, this script's submodules can be called individually. The full command is mulithreaded. Perhaps the issue is not that these actions can technically be done without a build tool, but that you don't use any of the advanced functionality these tools were built to automate?

I think when comparing grunt and gulp to webpack, that they solve different issues.

grunt gets complicated easily, by including a bunch of plugins and defining their configuration in a declarative manner. Gulp solves those issues by letting the user determine how to configure it himself, so the user can load in the package.json to load constants.

While webpack also does that, It imo has a more sensible definition. Instead of the grunt/gulp approach, where you would say, do these actions with this folder, and this with that folder; webpack allows you to say, "if it's a jsx file: do this, and it's extension becomes: .js" There's a lot less configuration needed for projects involving webpack, because it just lets you define transforms. Usually everything is turned into js (including images/css). But it also allows you to expose some files in the output to be loaded externally.

So there's no more 'gulp task' to run, now I'm just using npm scripts (npm start, npm run build, enz)

I was in the same boat in 2015, happily using a hacked-together solution of gulp-babel-browserify that took a few days to set up correctly. Than, after hearing about it enough, I decided to give webpack a try.

After a few hours of learning, I've succesfully set up webpack with hot module reloading and some other niceties. It was certainly much more cleaner than my old solution.

I'm a webpack user since than. It's easier to understand and easier to upgrade for me.

I didn't really took time to understand browserify, just enough to get me working, and I was an inexperienced JS developer at that time, which may explain why my first solution was hacky. But I still believe Webpack's architecture allows a cleaner and more understandable solution.

I prefer browserify because of its emphasis on node compatibility, first and foremost. I think this narrower scope is a strength because as a result, browserify is super simple to use, works without config, and has a surprisingly small, readable implementation. Seriously, read the browserify source.

Browserify also has code splitting

https://github.com/substack/factor-bundle

and hot module reloading

https://github.com/AgentME/browserify-hmr

Browserify is so much easier to understand and interact with, I'm sticking with it as well.

I've been a huge fan but the fact that it's very less opinionated enabled me to ruin my build workflow too often. Now a happy webpack user.

Reply on news.ycombinator.com