RequireJS 2.0 draft(github.com)
github.com
RequireJS 2.0 draft
https://github.com/jrburke/requirejs/wiki/Requirejs-2.0-draft
3 comments
That looks cool, will look into it. Does it support the http node core module, like browserify?
Here are the core modules it supports; http://news.ycombinator.com/item?id=3915403
browserify-http can be used by OneJS as well but I don't see any point of emulating http module on client-side. I prefer using libraries supporting both platforms, such as boxcars; http://github.com/azer/boxcars
browserify-http can be used by OneJS as well but I don't see any point of emulating http module on client-side. I prefer using libraries supporting both platforms, such as boxcars; http://github.com/azer/boxcars
Good news.
This will very be useful in my current projets, I like the direction taken with the "legacy config".
I agree. I've had to wrap non-amd libs far too many times.
I wonder how this will work when optimized.
I wonder how this will work when optimized.
So what's the advantage of requireJS versus browserify? I like browserify because I'm used to the node syntax
I haven't used browserify so I may be wrong, but because browserify is not AMD compatible and depends on a build step, the advantage of RequireJS appears to be slightly faster/simpler (or just different) development experience.
It looks like with browserify you only ever reference a single script file in your HTML, regardless of development or production environments. While this unifies HTML rendering across development and production environments, during development every time you change a module you must rebuild that script file. In actuality, this is not much of a problem since browserify appears to have a "watch" mode to do this automatically. If you have a huge codebase, building could take a noticeable amount of time.
With RequireJS, this build step is not needed during development. When you save module changes and reload your browser (with caching disabled), the changed module will be delivered. If you have a huge codebase, no time-consuming build step is required. Of course in production you want to deliver only a single file, and RequireJS can be used to build this. However, depending on your overall build, you may need to conditionally render different script tags for production and development, which is a tiny but not insignificant bit of complexity.
To allow RequireJS to load node (CommonJS-based) modules the module needs to be wrapped in a special function call. RequireJS supplies tooling to help with this. Alternatively, RequireJS can be used in node to load AMD modules, to allow modules to be used client- and server-side.
If you have a small codebase and use the same modules in node and in the browser, browserify seems to be the way to go. For large codebases, browserify is only an option if you have lots of modules being used in node and in the browser and find RequireJS' tooling inadequate. Otherwise, RequireJS' flexibility seems to make it the preference.
It looks like with browserify you only ever reference a single script file in your HTML, regardless of development or production environments. While this unifies HTML rendering across development and production environments, during development every time you change a module you must rebuild that script file. In actuality, this is not much of a problem since browserify appears to have a "watch" mode to do this automatically. If you have a huge codebase, building could take a noticeable amount of time.
With RequireJS, this build step is not needed during development. When you save module changes and reload your browser (with caching disabled), the changed module will be delivered. If you have a huge codebase, no time-consuming build step is required. Of course in production you want to deliver only a single file, and RequireJS can be used to build this. However, depending on your overall build, you may need to conditionally render different script tags for production and development, which is a tiny but not insignificant bit of complexity.
To allow RequireJS to load node (CommonJS-based) modules the module needs to be wrapped in a special function call. RequireJS supplies tooling to help with this. Alternatively, RequireJS can be used in node to load AMD modules, to allow modules to be used client- and server-side.
If you have a small codebase and use the same modules in node and in the browser, browserify seems to be the way to go. For large codebases, browserify is only an option if you have lots of modules being used in node and in the browser and find RequireJS' tooling inadequate. Otherwise, RequireJS' flexibility seems to make it the preference.
I've been using the tiny Include.js[1] combined with the standard module pattern.
My modules just look like this:
[1]http://capmousse.github.com/include.js/
My modules just look like this:
(function(exports) {
...
exports.moduleName = ...;
})(this);
[1]http://capmousse.github.com/include.js/
Consider OneJS here; http://github.com/azer/onejs
see my comment above for details about the differences; http://news.ycombinator.com/item?id=3915403
see my comment above for details about the differences; http://news.ycombinator.com/item?id=3915403
If you use node, I'd stick with browserify. RequireJS is nice if you want to load scripts asynchronously, but in reality your code is usually packed to one or two files so there is no need for the asynchronous part. Plus I dislike the RequireJS syntax, but that's personal taste.
http://requirejs.org/docs/node.html
I appreciate browserify having the exact same syntax, but RequireJS can do serverside.
I appreciate browserify having the exact same syntax, but RequireJS can do serverside.
Yes but as I said I don't need async loading of scripts, since all my code is packed in usually a single file. Therefore I don't need the RequireJS syntax, and I'd rather stick with a simple require syntax.
Help me, I'm still fumbling around in the web world und miss a lot.
Why would you even look at require.js if you don't have modular code/code of your own spread over a couple of files? This is for me the one single reason to look into it in the first place. To organize my own code better.
Why would you even look at require.js if you don't have modular code/code of your own spread over a couple of files? This is for me the one single reason to look into it in the first place. To organize my own code better.
I do keep my code in separate files. But my servers deliver them in a single file using browserify (https://github.com/substack/node-browserify).
It's great thing that you use RequireJS to organize your code, and you should keep doing it. We use RequireJS at work and it works pretty well. However my personal preference is browserify, but use whatever works for you.
It's great thing that you use RequireJS to organize your code, and you should keep doing it. We use RequireJS at work and it works pretty well. However my personal preference is browserify, but use whatever works for you.
Let me introduce you OneJS: http://github.com/azer/onejs
It simply converts any CommonJS package into a single, stand-alone JavaScript file. It means, you can structure your client-side project just like a NodeJS project and you can convert your NodeJS project to a single file just like a client-side project.
Unlike Browserify, OneJS is unobtrusive [1], provides an accurate implementation of CommonJS specs [2] and the output it produces is suitable for splitting and having async dependencies.
[1] A chess website built with OneJS: http://multiplayerchess.com/mpc.js
[2] ExpressJS built with OneJS, with all dependencies: https://gist.github.com/2415048