3 ms·
I am not sure why the parent compares webpack to gulp/grunt. The latter are generalized task runners (think "make"), but the former is a tool for bundling toget
by spicyj 11y ago
I am not sure why the parent compares webpack to gulp/grunt. The latter are generalized task runners (think "make"), but the former is a tool for bundling together many small JS files into one.
Webpack (and browserify, a competitor that's very similar) bring you a module system so that dependencies are explicit with a require() call and you don't have a global namespace with hundreds of objects. JS doesn't have any such system built in. Packaging it into one file in the end, which they do, is necessary for performance so you don't make hundreds of network requests.
- carbocation 11y agoBundling JS files into one big file is obviated by http2.
- spicyj 11y agoYou still have the round-trip time for each level of dependencies if they're resolved on the client, at the very least. And a real-world performance comparison where the recursive dependencies are listed up front but sent in separate requests shows unbundling losing: http://engineering.khanacademy.org/posts/js-packaging-http2.htm http://engineering.khanacademy.org/posts/js-packaging-http2....
- gedy 11y agoI think it's due to Webpack replacing/eliminating much of what we used to do "manually" in Grunt/Gulp such as transpiling, building, combining, etc. In most of my projects, I no longer needed Grunt for anything aside from deploying to production, etc.