Search jQuery

jQuery Forum

james.bur..

RequireJS as a require() for jQuery

in Developing jQuery Core • 2 years ago

I would like to offer a require() function as provided in RequireJS as a script loader for jQuery.

While RequireJS can be used today without integration into jQuery core, there are benefits with integrating RequireJS, similar to how Sizzle is integrated, with jQuery core:

export jQuery as a module to be used by the module system supported by RequireJS
The "baseUrl" to find all scripts would be relative to jquery.js
more robust handling of async scripts that should be loaded before jQuery.ready() fires its callbacks.
Longer term, the encapsulated scopes of RequireJS-supported modules could be used to build jQuery core from a set of discrete modules (this is not strictly needed, just another integration option).

RequireJS aims to work with CommonJS modules as best as possible, given the constraints of browser loading, but still allows "simple" use by just loading some stand-alone JS files, or in jQuery's case, allowing any easy way to load existing plugins.

I am participating in the CommonJS group to try to get a module "transport format" that works best in the browser, and RequireJS implements the latest transport proposal:
http://wiki.commonjs.org/wiki/Modules/Transport/C

I have a simple conversion script that converts normal CommonJS modules to the browser-friendly require() format used by RequireJS and as specified in Transport/C.

RequireJS has an optimization tool that allows you to builld all your JS files into bundles and will soon have the ability to optimize CSS (inline @import calls, remove comments).

If you think RequireJS might be a close fit for jQuery, but need some tweaks or want to discuss more of its internals, I am happy to oblige.

The code:
http://github.com/jrburke/requirejs

Doc with example on how to use it today with jQuery as standalone library:
http://github.com/jrburke/requirejs/blob/master/docs/jquery.md

My fork of jQuery that does an initial integration of RequireJS (uses the 2.4KB minified/gzipped bare bones version of RequireJS):
http://github.com/jrburke/jquery

Replies(6)

aubourg.j..

Re: RequireJS as a require() for jQuery

2 years ago

That's quite a nice loader you have there :)

Not sure I'm sold on three points though:

- In the spec you linked to, the whole pause/resume system seems a bit unnecessary to me. I got around the problem of grouping requests in dominoes by delaying the request which allows you to just write dependencies and never care about the internal plumbery (see http://code.google.com/p/javascript-dominoes/wiki/AdvancedTechniques#Cumulators ).

- I really dislike the notion of a manual building system as a pre-process:

1) it's limited to domains you have control over and you also don't take advantage of shared cache (provided you do include external js too -- ie google hosted jQuery for instance). I think a better approach would be to provide a server-side script that does the concatenation/caching/minification on-demand in different languages so that different script providers (google, yahoo, your own site, etc) can handle requests like http://youdomain/yourLib/name1+name2+name3 (it is important the url is browser cache savy).

2) Then, it lacks flexibility in that you'll need to preprocess your files everytime you change something. Sure you'll have some marginal gain but...

- The dependency system is not flexible enough. Since you have to modify jQuery anyway, why not add some padding to each module execution in order to enable more parallelism? (see http://code.google.com/p/javascript-dominoes/wiki/AdvancedTechniques#Cascading_script_dependencies )

All in all, you have a solid implementation here but it suffers from a lot of flaws I've seen in other loaders:

- mainly same-domain oriented with cross-domain as a bonus (not that they cannot load from other domains, rather that their design aims to optimize/group same-domain requests only).

- constraining dependency system where users are limited into what they can express and have to specify request grouping manually while it is absolutely unnecessary.

I may have missed something, of course, so feel free to correct me where I'm wrong.

(PS: has anyone managed to have the bullets to work in Zoho's editor? This is getting quite frustrating)

james.bur..

Re: RequireJS as a require() for jQuery

2 years ago

Julian,

require.pause() and require.resume() are only needed for optimized build layers. For RequireJS, they are automatically added by the optimization tool. Normally a developer would never hand-write those calls.

RequireJS was built from the ground up to support modules on different domains, in particular to support CDN usage of modules. In the top-level require call for the page, you can specify a config object that allows mapping module names/prefixes to paths. Since RequireJS uses dynamically appended script tags exclusively for script loading, it will work with xdomain paths.

The module format supported by RequireJS could be backed by a loader that uses a server side process for concatenating dependencies together -- the dependencies are specified as an array, and a patch to the base RequireJS loader could be made to forward that array directly to a server.

However, I do not think a server side transformer should not be required to use a loader. The loader should work well without one, and I believe RequireJS is a good baseline loader.

I believe a runtime rules approach as used in Dominoes optimizes for something that normally does not need optimization. During development, a developer just wants to worry about a file/module's direct dependencies, then get to coding. Then, when considering deployment, a wider dependency analysis needs to be done. However, for deployment there are normally other packaging tasks that are done, so it seems reasonable to specify the rules for module optimizations during a build process that can be done during that packaging step.

Some other background: I maintain Dojo's module loaders, and its module system is pretty much the same: developer focuses on immediate dependencies, then a build tool is used for deployment. That system has been able to support very large projects, including AOL's WebMail.

In all the years we have had that setup, we have never needed a more complex runtime rules engine. You can do some runtime rules with RequireJS: parallel loading via listing dependencies together in the dependency array, serial loading via nested require calls. That has normally been enough for the projects I have seen in Dojo. But I appreciate you might have different experiences.

In the larger scope, RequireJS allows, but does not force, the use of CommonJS module idioms, as much as reasonably possible given browser constraints. I believe this allows better reuse of code between CommonJS server side modules and browser side code. While it is not a slam-dunk 100% of the time, it is close enough that I believe it allows a very good amount of code reuse.

I do not want to trade that sort of CommonJS compatibility for some other loading scheme, as I believe working with the CommonJS effort will be important in the long run. But of course I want whatever loading scheme to work well in the browser, with existing code.

dbjdbj

Re: RequireJS as a require() for jQuery

2 years ago

@aubourg.julian

(PS: has anyone managed to have the bullets to work in Zoho's editor? This is getting quite frustrating)

Sorry for the thread detour, but yes this Zoho editor is getting by now, more than "frustrating" it is on the edge of being unusable, for this kind of forums at least ...

I have suggested a least a "clear formatting" button, but after few weeks we still have none of it, or any other similar, editor related measure, needed and asked by a *lot* of people here ...

--DBJ

aubourg.j..

Re: RequireJS as a require() for jQuery

2 years ago

@dbjdbj:

I wouldn't be as clear cut as you are, but it's true Zoho's post editor is a pain.

@james:

Nice reply with lots of sensible arguments :)

I would have answered earlier, but my isp failed me this week-end... :(

In particular, I'd like to answer regarding this, though:

I believe a runtime rules approach as used in Dominoes optimizes for something that normally does not need optimization. During development, a developer just wants to worry about a file/module's direct dependencies, then get to coding. Then, when considering deployment, a wider dependency analysis needs to be done. However, for deployment there are normally other packaging tasks that are done, so it seems reasonable to specify the rules for module optimizations during a build process that can be done during that packaging step.

The dependency analysis you refer to is limited to a single domain. I think we have a misunderstanding regarding what I call "same-domain orientation" for current loaders in use. And the developper you refer to is a website developper not a plugin developper.

Let's take the following () situation:

- Julian writes a nice twitter plugin that will reside into a div. All you have to do is remote linking to the script at google-code and then call $("#aDiv").juliansNiceTwitterApp( options );

- James writes an awesome feed syndicator plugin using yql. All you have to do is remote linking to the script at google-code and then call $("#anotherDiv").jamesAwesomeFeedSyndicator( options );

- and John made a cool templating engine plugin back in the days. You can get it by remote linking to the script on john's site then call $("#target").applyJohnsNeatTemplateEngine( templateCode, jsonData);

Both Julian's & James' plugins make use of John's templating plugin but, rather than integrating the source of John's plugin into their own, they decided to remote link to the script using a javascript loader. They also make use of the latest jQuery 1.5 modularized system hosted by google to have good performances even on mobile phones.

Now, that's dynamic loading, but since the twitter status app and the feed syndication are not essential to the site, it's a good demonstration of lazy loading, right?

But here is the deal. There are 3 jQuery 1.5 hosted on google (1.5.1, 1.5.2 and 1.5.3 -- John Resig being on a release frenzy). Julian's plugin was written when 1.5.1 was out and hasn't been updated since, James' just got released (and uses 1.5.3 specific features) and John's code is not maintained anymore and happens to be be a good old plugin with a ( function($) { ... } )( jQuery ); type of closure (and is actually compatible with jQuery 1.3 though it only needs jQuery:core and jQuery:manipulation when looking at it from a modularized perspective).

To add to the difficulty, the site owner is already using a nightly build of jQuery (1.5.4pre) because it fixes a nasty issue he had with 1.5.3 and would much prefer that all three plugins use this version of the lib (actually "remote linking" to his site) while waiting for 1.5.4 to be released and hosted on google.

The solution with current loaders are as follows:

- make a local copy of each plugin and edit their code appropriately, eventually using a preprocess server-side to concatenate files, completely derailing the very notion of remote-linking,

- Use iframes to separate everyone having jQuery 1.5.1, 1.5.3 and 1.5.4pre modules + *twice* John's templating plugin loaded for the very same page. I won't even comment here, but let's observe this is what most pluggable sites do nowadays.

Here is how I'd solve the problem with "unnecessary" runtime rules... :P :

First, let's make Julian's and James' plugins jQuery and John's templating engine version (and even location for jQuery) agnostic:

( function( dominoes ) {
// Define a default URL if no jQuery rule already exists
dominoes.rule.ifNot( "jQuery" ,
"http://ajax.googleapis.com/ajax/libs/jquery/1.5.X/jquery.core.min.js" );
// Then load & execute stuff
dominoes( {
chain: "jQuery > ( jQuery:manipulation > templateLib ) jQuery:json
templateLib:
jQuery.fn.applyJohnsNeatTemplateEngine
? dominoes.noo
: "http://ejohn.org/template-1.X.min.js",
createPlugin: function() {
// Plugin code
}
} );
} )( dominoes );

Then, here is how the page would actually declare stuff:

// ON TOP: Declare jQuery rule
dominoes.property( "jQuery:DIR" , "js/1.5.4pre" )
.rule( "jQuery" , "$(jQuery:DIR)/jQuery.core.min.js" );
// Do some stuff using jQuery on the page
dominoes( "jQuery >|" , function() {
// Some DOM manipulation
} );
// Load James' plugin
dominoes( "http://jamesFeed.googlecode.com/files/jamesFeed-0.9.js >|" , function() {
$("#divFeed").jamesAwesomeFeedSyndicator( options );
} );
// Load Julian's plugin
dominoes( "http://julianTweeter.googlecode.com/files/julianTweeter-1.1.3.js >|" , function() {
$("#divTweeter").juliansNiceTwitterApp( options );
} );

The code above will only load *1* version of jQuery (the one on the dev's site), *1* version of each jQuery module (again from the website of the dev), John's, James' and Julian's plugin once each and remotely.

Plugin code takes some plumbery but it should since it has some controlling to do before feeding Dominoes a default URL. Please note there are a lot of ways to do what the plugin code does and the one here is just an example.

Site code is VERY straight-forward (the developper only has to think of which files he needs and code right away). Also all it takes the maintainer when 1.5.4 is out and hosted on google is to replace "js/1.5.4pre" with "http://ajax.googleapis.com/ajax/libs/jquery/1.5.4". I don't see that as something cryptic or difficult.

If the jQuery module rules are implemented using a Cumulator, the code above will result in 5 requests to 3 different domains:

1) jQuery.core.js, James' and Julian's plugins in parallel,

2) then manipulation + ajax + jsonp from the dev's site for the modules ( provided the rule jQuery:jsonp establishes the dependency to jQuery:ajax which makes sense and I'd recommend it ) in parallel with John's templating plugin (as defined by the first of James' or Julian's plugin to be loaded)

If the website dev wants to ensure a specific version of John's templating engine to be used, he can simply add a dependency to the two last statements: jQuery.fn.applyJohnsNeatTemplateEngine will be defined when the two other plugins are loaded so this specific version would be used.

What I'm talking about here is cross-domain dependency, complete control over what is loaded and when and that without sacrificing js file concatenation if a provider supports it. You can use the code above even on a website with no server control where you can only edit HTML if you keep it to remote linking (think blogger.com).

Of course, if you are AOL, you don't need this since you have the bandwidth and frequentation to handle js file delivery yourself and go the server-side building way.

Anyway, that's what I meant by "cross-domain": true cross-site dependency handling. Sorry for the lengthy post, just wanted to make that clear.

And again, thanks for the very argumented answer, these are always a pleasure to read :)

james.bur..

Re: RequireJS as a require() for jQuery

2 years ago

Julian,

Thanks for a more concrete example.

It highlights maybe the main difference between dominoes and RequireJS. dominoes encodes loading rules/paths inside each module, referencing specific paths to modules, where RequireJS assumes that configuration happens outside specific modules but in a top-level configuration.

I believe that sort of configuration should be outside each module, it allows the modules to be more portable, and that configuration only needs to be done once, at the top level. URL-paths-to-modules is a developer-time decision, not something that needs to be resolved at runtime by the modules themselves. At least that is my claim, and I believe Dojo's experience, and how CommonJS modules are defined also bear this out.

Here is how I would code up your example. To summarize your example:

1) the three plugins were developed against different versions of jQuery, but they all work with the 1.5.4pre.
2) the three plugins were authored with knowledge of the loader -- these are not regular plugins as specified today, but can make loader calls, in your case dominoes calls, in my case, require() calls.

In the RequireJS, the example would look like the following. First, the plugins look like this:

require("jamesAwesomeFeedSyndicator", ["jquery", "johnsTemplate"],
function ($, templ) {
$.fn.jamesAwesomeFeedSyndicator = function() {
//uses templ for the template engine, if used directly,
//otherwise, just call $().templ
}
}
require("juliansNiceTwitterApp", ["jquery", "johnsTemplate"],
function ($, templ) {
$.fn.juliansNiceTwitterAp
//uses templ for the template engine, if used directly,
//otherwise, just call $().templ
}
}
require("johnsTemplate", ["jquery"],
function ($) {
$.fn.johnsTemplate = function() {
}
}

The top level HTML page would load them all like so:

require({
paths: {
"jquery": "js/1.5.4pre",
"juliansNiceTwitterApp": "http://julianTweeter.googlecode.com/files/julianTweeter-1.1.3",
"jamesAwesomeFeedSyndicator": "http://jamesFeed.googlecode.com/files/jamesFeed-0.9",
"johnsTemplate": "http://ejohn.org/template-1.X.min",
}
},
["juliansNiceTwitterApp", "jamesAwesomeFeedSyndicator"],
function() {
//query the dom and use plugins to do their thing.
}
);

If jQuery also followed the require() syntax, and if RequireJS is used with multiversion support, then two versions of jQuery can be loaded in the page (no iframes needed). So if juliansNiceTwitterApp and jamesAwesomeFeedSyndicator need two different versions of jQuery:

require({
context: "julian",
paths: {
"jquery": "http://ajax.googleapis.com/ajax/libs/jquery/1.5.3/jquery.core.min",
"juliansNiceTwitterApp": "http://julianTweeter.googlecode.com/files/julianTweeter-1.1.3",
"johnsTemplate": "http://ejohn.org/template-1.X.min"
}
},
["juliansNiceTwitterApp"],
function() {
//query the dom and use juliansNiceTwitterApp.
}
);
require({
context: "james",
paths: {
"jquery": "http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.core.min",
"jamesAwesomeFeedSyndicator": "http://jamesFeed.googlecode.com/files/jamesFeed-0.9",
"johnsTemplate": "http://ejohn.org/template-1.X.min"
}
},
["jamesAwesomeFeedSyndicator"],
function() {
//query the dom and use plugins to do their thing.
}
);

Note the use of "context" in the config objects -- this allows the modules to be loaded in separate context objects. Currently with RequireJS, johnsTemplate will be added twice as a script tag. This could be optimized out if seen as necessary, but if that file is served from the CDN with proper cache headers, then I do not believe the cost is that high. But again, if need be, that can be fixed.

Similar with a server-side optimization tool -- there could be a version of the RequireJS loader that takes the top level require arguments and just passes them all to a server side tool to do the concatenation. But the important thing is the API for modules and loading is the same -- the developer will not have to change their code, just swap in a different implementation for require().

james.bur..

Re: RequireJS as a require() for jQuery

2 years ago

As a follow-up on this, I have a new release of RequireJS , and it includes builds of jQuery 1.4.2 with integrated support .

My fork of jQuery also has the latest changes, including test cases. It takes the same integration path as Sizzle, cloning the requirejs repo and adding it to the jQuery project that way. The fork also includes changes that integrates with jQuery's page loading functionality -- jQuery's ready callbacks will not be fired if scripts are still being loaded.

Feel free to let me know if I can do anything else to make it easier to integrate with jQuery.

Top Reply

Response title

Attachments

jQuery Forum

RequireJS as a require() for jQuery

Replies(6)

Re: RequireJS as a require() for jQuery

Re: RequireJS as a require() for jQuery

Re: RequireJS as a require() for jQuery

Re: RequireJS as a require() for jQuery

Re: RequireJS as a require() for jQuery

Re: RequireJS as a require() for jQuery

Statistics

Tags

Actions

Related Posts