4 ms·

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

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).

hakanderyal 11y ago
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.
maxthegeek1 11y ago
Browserify also has code splitting https://github.com/substack/factor-bundle https://github.com/substack/factor-bundle and hot module reloading https://github.com/AgentME/browserify-hmr https://github.com/AgentME/browserify-hmr
- alessioalex 11y ago
  Browserify is so much easier to understand and interact with, I'm sticking with it as well.
  - egeozcan 11y ago
    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.
fuzionmonkey 11y ago
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.
Chris_Newton 11y ago
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.
- s986s 11y ago
  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
  - Chris_Newton 11y ago
    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.

hakanderyal 11y ago

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.

maxthegeek1 11y ago

Browserify also has code splitting https://github.com/substack/factor-bundle https://github.com/substack/factor-bundle and hot module reloading https://github.com/AgentME/browserify-hmr https://github.com/AgentME/browserify-hmr

alessioalex 11y ago
Browserify is so much easier to understand and interact with, I'm sticking with it as well.
- egeozcan 11y ago
  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.

fuzionmonkey 11y ago

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.

Chris_Newton 11y ago

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.

s986s 11y ago
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
- Chris_Newton 11y ago
  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.