5 ms·

Reusing require.js modules in Node.js with AMDrequire

13 points by marquex 12y ago

AMDrequire is a npm package that makes Node.js able to load require.js modules like if they were native Node ones, as well as continue to load its own modules as usual, allowing to reuse browser code in the server.

couchand 12y ago
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.
alistairjcbrown 12y ago
How does this differ from the requirejs module for Node? https://www.npmjs.org/package/requirejs https://www.npmjs.org/package/requirejs
- spencera 12y ago
  Looks like it offers a subset of the features by allowing you to use the same require() function for both amd and commonjs modules. https://gist.github.com/spenceralger/946ddc6c55d997d4a028 https://gist.github.com/spenceralger/946ddc6c55d997d4a028
  - alistairjcbrown 12y ago
    Ah, thank you - I misunderstood the crucial piece "load AMD modules like ... they were native Node modules". I guess I can see the value in this, if you're retrofitting a new module in the AMD style to an existing node application which does not use that style.
- wildpeaks 12y ago
  The requirejs module has both the server-side loading modules and the optimizer that compiles to a single file whereas this new one only does the server-side loading of modules as far as I can tell.
superduper33 12y ago
Careface.
wildpeaks 12y ago
Interesting, it might solve my dilemna regarding RequireJS vs Browserify given the npm requirejs has one troublesome issue with the paths aliases config getting erased (& can't be restored either) once .optimize has been called to make an Almond build. That's why I switched to Browserify in most recent projects, however I have one issue with it and it feels I'm missing something obvious: What is the right way to use Browserify transforms server-side? ------------------ Because Browerify assumes you use Node's own require() server-side while RequireJS (and now also AMDRequire) have their own module to provide an enhanced require function. The closest I could come up with (besides giving up and precompiling to a single file before calling Node) is using the deprecated "require.extensions" to preprocess the file, similar to requirejs loaders, e.g. for handlebars you could add in your Node start: var fs = require('fs'); var Handlebars = require('handlebars'); require.extensions['.handlebars'] = function (module, filename){ var code = fs.readFileSync(filename, 'utf8'); module.exports = Handlebars.compile(code); }; Then require('./something.handlebars') in modules you share client and server-side gives you the already-compiled template regardless if you're running in Node or in the browser (if you also use the handlebar transforms for Browserify). I'm sure I'm missing something very obvious here.

13 points by marquex 12y ago

couchand 12y ago

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.

alistairjcbrown 12y ago

How does this differ from the requirejs module for Node? https://www.npmjs.org/package/requirejs https://www.npmjs.org/package/requirejs

spencera 12y ago
Looks like it offers a subset of the features by allowing you to use the same require() function for both amd and commonjs modules. https://gist.github.com/spenceralger/946ddc6c55d997d4a028 https://gist.github.com/spenceralger/946ddc6c55d997d4a028
- alistairjcbrown 12y ago
  Ah, thank you - I misunderstood the crucial piece "load AMD modules like ... they were native Node modules". I guess I can see the value in this, if you're retrofitting a new module in the AMD style to an existing node application which does not use that style.
wildpeaks 12y ago
The requirejs module has both the server-side loading modules and the optimizer that compiles to a single file whereas this new one only does the server-side loading of modules as far as I can tell.

superduper33 12y ago

Careface.

wildpeaks 12y ago

Interesting, it might solve my dilemna regarding RequireJS vs Browserify given the npm requirejs has one troublesome issue with the paths aliases config getting erased (& can't be restored either) once .optimize has been called to make an Almond build. That's why I switched to Browserify in most recent projects, however I have one issue with it and it feels I'm missing something obvious: What is the right way to use Browserify transforms server-side? ------------------ Because Browerify assumes you use Node's own require() server-side while RequireJS (and now also AMDRequire) have their own module to provide an enhanced require function. The closest I could come up with (besides giving up and precompiling to a single file before calling Node) is using the deprecated "require.extensions" to preprocess the file, similar to requirejs loaders, e.g. for handlebars you could add in your Node start: var fs = require('fs'); var Handlebars = require('handlebars'); require.extensions['.handlebars'] = function (module, filename){ var code = fs.readFileSync(filename, 'utf8'); module.exports = Handlebars.compile(code); }; Then require('./something.handlebars') in modules you share client and server-side gives you the already-compiled template regardless if you're running in Node or in the browser (if you also use the handlebar transforms for Browserify). I'm sure I'm missing something very obvious here.