I am really excited about the inclusion of Webpack with Sage. I have been using my own modified branch with Browserify for my latest project for a couple months now. I was introduced to Browserify first and have pretty much stuck with it. I have seen a couple articles highlighting the differences of Webpack & Browserify, but I was just wondering if the Roots team had any public discussion in regards to the decision to use one over the other. It may have been discussed in the podcast (haven’t listened to them all) or another venue, or privately, but I greatly respect your guys work and would be interested to know the reasoning.
Webpack is pretty much the defacto module loader for the react ecosystem. Lots of high quality packages on NPM maintain active support for webpack.
Webpack is much more flexible. I have used Browserify quite a bit and while I enjoy the way it’s laser focus on mirroring the node module loader for the browser: Webpack is hella batteries included. It can basically handle our entire asset pipeline while at the same time allowing support for bower packages, manually vendored stuff, and at the same time npm.
Webpack’s out of the box functionality fits a lot of our needs. We would need to add and maintain a bunch of browserify plugins to accomplish our goal. For people who aren’t super familiar with module loaders and such Webpack is much easier to understand.
Not wanting to hijack this topic as I got the point on why webpack was chosen over Browserify by the Sage team, but I was referred to this topic for my question.
Without retyping everything, here’s the basic question I have… what’s the reason for using webpack at all? The only things being run by Sage are a very basic set of tasks that certainly don’t require anything beyond some basic npm scripts.
Should we be looking forward to something coming down the road with Sage that’s going to build off the webpack beginnings?
Trying to orchestrate the third party dependencies without a module loader proved to be downright confusing. With asset builder and bower overrides and wiredep and bower-main-files all trying to get everything in order and built. When something goes wrong it is very unclear as to how to fix it. Is it the bower package author’s fault? Is my manifest malformed? Do I not understand something?
With webpack we are saying forget all that: just code modern JavaScript using es6 modules and be done with it. Use npm, bower, whatever we don’t care. Want to split you JavaScript into multiple packages based on what’s happening on the current page? No problem, webpack handles that out of the box.
Thanks for the answer, Austin. I wasn’t certain if there was something else weighing in the decision that was made. I suppose this might offer advantages to more complex projects over just using npm’s scripts directive on its own (sans bower/gulp and the lot).
I would argue a module loader is appropriate for any project. Imagine trying to write PHP while not being allowed to require or include other files.
If you are fine with a build process: webpack is a nice batteries included solution. If you are building something simple like a static webpage: use something like require.js.
No disagreements here, just a different perspective. And npm is a solid build tool capable of implementing a robust process unto itself, but that’s neither here nor there.
