The gist of the argument is that Browserify can access more file extensions out of the box, whereas Webpack uses an external config file to define how special f

The gist of the argument is that Browserify can access more file extensions out of the box, whereas Webpack uses an external config file to define how special file extensions are to be processed. The given scenario of loading a regular ".js" looks like it is in favour of Browserify, but that advantage quickly goes to Webpack as soon you change the extension to be jsx/sass/yml/myown. How those files will be loaded and processed is not up to the bundling tool - that should be delegated to single-purpose loader that convert whatever the content is into an app-compatible format. This is exactly what Webpack does by keeping the core minimal and outsourcing all content loading to mini-loader, including the loading of simple JS files. The Webpack approach is much closer to the linux goal of do-one-thing-really-well-and-play-well-with-others. Edit: The suggested "fragmentation" seems unlikely as Webpack does not enforce the change in the require() syntax. In practice, very few people would use that in the source files because using the overall config file is so much easier and more powerful - it is akin to having a makefile for the JS app.