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.

The gist is that Webpack is diverging from Node, has difficulty consuming node/browserify modules, and encourages non-compatible syntax through its require() overloads (which are encouraged all over the docs).

Browserify also decouples its transforms from its core. The difference is that browserify can correctly identify which transforms your various dependencies are using, since they are listed in the package.json of each module, and it can resolve them automatically during the bundle step. This is not yet in Webpack, which makes code re-use more tedious.

Browserify transforms can do exactly the same, they transform whatever your file contains to valid JavaScript can can be require'd.

In your `webpack.config.js`:

    module: {
      loaders: [
        { test: /\.json$/, loader: 'json' },
      ]
    }

Elsewhere:

    var version = require('./package.json').version;

Loaders are common.js packages that export a single function and expect `this` to have the loader API. You can put them as dependencies in your `package.json`. You can wire them up in your config. It's not any less flexible than browserify.

The issue is twofold:

- It shows Node compatibility is not a primary concern of Webpack.

- It is not a default feature of Webpack. Pretty much every Webpack project will need to include this loader config if you want to (safely) start consuming Node/browserify modules

I added the config to the article to detail the additional steps.

I've been using wreq (https://github.com/substack/wreq) recently and it's worked a treat. Yes, it hasn't been committed to in 3 years - but I've had 0 problems with it. It just works like you'd expect it to work.

In my opinion a bundler should bundle and nothing else. Transforms should be implemented as externals tools that package assets and whatnot as CommonJS modules. One benefit among others would be the ability to implement the build process as a Makefile. These tools try to do to much at once.

I would say it depends. brfs is perfect since you don't change any node source to support the browser.

glslify is another useful one if you're authoring WebGL modules. Not only does it statically analyze the uniforms/attributes for use at runtime, but it also allows for modularization, minification, optimization, etc.

On the other hand, transforms like cssify and hbsfy might be better suited only for the application level.

In an ideal world; these transforms would be completely decoupled from the bundler so that Webpack, Browserify, or anything else can use them in the same way.

Though brfs can be nice to make a module instantly usable in the browser I think it is highly misleading because it skews fs semantics a lot. It shouldn't be encouraged in cases where other solutions are available. I can't talk about glsify because I don't know it, though trying so hard to make the browser behave like node has a lot of benefits at first, I think it is a very brittle solution in the long run.

I prefer Loadstar, it is newly released but it is pretty useful and simple:

https://github.com/wvl/loadstar