4 ms·

I disagree with the assertion that the browserify transformation implies it's "not the same code". If you're (following best practice and) concatenating and mi

I disagree with the assertion that the browserify transformation implies it's "not the same code". If you're (following best practice and) concatenating and minifying your assets, is that not the same thing? The compilation step that browserify uses is little more than concatenate + a little bit of sugar. Practically speaking why does this matter? I'd much prefer to deliver less code to the client if possible, so I don't see the rationale for adding a dependency on a dependency manager.

greggman 12y ago
I don't know browserify well but I'd assume having a compile step is the part that sucks. If you can use require.js style until shipping time you can debug the actual code directly instead of the compiled code. You see each module in the debugger as its original file.
- jgillich 12y ago
  Source maps solve that issue, even though browser support isn't perfect yet.
- alistairjcbrown 12y ago
  +1 - this is why I love requirejs - lazy load modules in development, compile for QA and deployment. Update: My other love for requirejs is that you don't need to use relative paths when requiring a module. Once you have a relative path, you can't change the location of either dependant or dependency. The require config lets you separate what you call the module from the location of the file.
  - danabramov 12y ago
    I tried porting a project from Require to Browserify and I gave up because of relative paths issue.
jgillich 12y ago
Exactly. RequireJS promotes having lots of files, but for production, everyone runs their code through r.js anyway. I used RequireJS for a while and it isn't bad, but Browserify has a lot of advantages like compatibility with Node.js and npm (while the only disadvantage I see is that the compile step is non-optional).
chr1 12y ago
Browserify compile step on a large project is painfully slow. Using https://www.npmjs.org/package/amd-loader https://www.npmjs.org/package/amd-loader with commonjs style modules http://requirejs.org/docs/commonjs.html http://requirejs.org/docs/commonjs.html was much easier to use. > I'd much prefer to deliver less code to the client if possible requirejs shim isn't signifcantly larger than what browserify adds, it's only 200 lines.
- couchand 12y ago
  Browserify compile step on a large project is painfully slow. I'd be very interested in seeing a set of benchmarks comparing browserify to r.js. I'd be very surprised if the difference was meaningful, since they do basically the same thing. In fact, doesn't r.js support CommonJS-style requires?
  - chr1 12y ago
    The speed of r.js and browserify compile is about the same, indeed. The difference is that with browserify i had to wait for it on every reload, and r.js runs only for release, on buildbot.

greggman 12y ago

I don't know browserify well but I'd assume having a compile step is the part that sucks. If you can use require.js style until shipping time you can debug the actual code directly instead of the compiled code. You see each module in the debugger as its original file.

jgillich 12y ago
Source maps solve that issue, even though browser support isn't perfect yet.
alistairjcbrown 12y ago
+1 - this is why I love requirejs - lazy load modules in development, compile for QA and deployment. Update: My other love for requirejs is that you don't need to use relative paths when requiring a module. Once you have a relative path, you can't change the location of either dependant or dependency. The require config lets you separate what you call the module from the location of the file.
- danabramov 12y ago
  I tried porting a project from Require to Browserify and I gave up because of relative paths issue.

jgillich 12y ago

Exactly. RequireJS promotes having lots of files, but for production, everyone runs their code through r.js anyway. I used RequireJS for a while and it isn't bad, but Browserify has a lot of advantages like compatibility with Node.js and npm (while the only disadvantage I see is that the compile step is non-optional).

chr1 12y ago

Browserify compile step on a large project is painfully slow. Using https://www.npmjs.org/package/amd-loader https://www.npmjs.org/package/amd-loader with commonjs style modules http://requirejs.org/docs/commonjs.html http://requirejs.org/docs/commonjs.html was much easier to use. > I'd much prefer to deliver less code to the client if possible requirejs shim isn't signifcantly larger than what browserify adds, it's only 200 lines.

couchand 12y ago
Browserify compile step on a large project is painfully slow. I'd be very interested in seeing a set of benchmarks comparing browserify to r.js. I'd be very surprised if the difference was meaningful, since they do basically the same thing. In fact, doesn't r.js support CommonJS-style requires?
- chr1 12y ago
  The speed of r.js and browserify compile is about the same, indeed. The difference is that with browserify i had to wait for it on every reload, and r.js runs only for release, on buildbot.