

Browserify vs. Webpack - mattdesl
http://mattdesl.svbtle.com/browserify-vs-webpack

======
e1g
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.

~~~
mattdesl
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.

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

~~~
mattdesl
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.

------
notduncansmith
I've been using wreq
([https://github.com/substack/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.

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

~~~
mattdesl
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.

~~~
thibauts
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.

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

[https://github.com/wvl/loadstar](https://github.com/wvl/loadstar)

