Yeah, sorry I wasn't clear why. The first is that React is pretty large so it slows down the watch/build cycle enough that there is a lag and second is that in production React can be loaded via a cdn. Since everything is bundled into one file with Browserify its better for the end user download speed if you pull 3rd party libs out.
I also didn't give the main reason for using the NODE_PATH method. Browserify doesn't resolve duplicate relative paths so if you have a structure like this:
then c.js is included twice in your bundled code since Browserify uses the pure string path as the key. If instead you put /src in your NODE_PATH you can do this in a.js:
require('components/foo/c.js')
and this in b.js
require('components/foo/c.js')
and c.js will only be bundled once since it has the same path.
I'm not sure that's accurate.. I've been using Browserify for some time, and write code like that pretty much all over (require('../lib/api'), require('./api'), etc.) without having file duplication issues in the bundled output. Do you have an example that exhibits the problem?
Also, if you're requiring large files that you know won't need processing by browserify (like react), you can use the 'noparse' option to prevent the performance hit during bundling. (Of course a cdn is potentially a better option.)
I've just started with browserify and react this week. Can you point to some example or documentation that describes the "double include" issue you talk about? I wasn't aware of this possible problem!
I also didn't give the main reason for using the NODE_PATH method. Browserify doesn't resolve duplicate relative paths so if you have a structure like this:
and a.js requires c.js via relative paths: and b.js also requires c.js via then c.js is included twice in your bundled code since Browserify uses the pure string path as the key. If instead you put /src in your NODE_PATH you can do this in a.js: and this in b.js and c.js will only be bundled once since it has the same path.