Status?

[asilvas]

You mentioned mid-2011 on your curl github page, was curious what status "cram" was in? Eager to evaluate it for a big project! Thanks much.

[unscriptable]

Hello @asilvas!

cram is still a bit rough at the moment. Well... we're using it successfully in a suite of enterprise-grade projects currently, but it's seriously lacking in documentation, unit tests, and features. That said, progress is being made on the next version that will make it easier to add features (in other words: faster progress) and will perform much faster.

What's your timeframe? Also, what's your project look like? Any idea what features you'll be needing? Are you using curl.js, plugins, packages, third-party libs? We've got a ton of features planned, but will gladly prioritize to suit your needs.

If your need is immediate, I can provide assistance getting your evaluation project running.

-- John

[asilvas]

Our primary evaluation is for curl.js, which will be over the next couple weeks (at most), at which time may be used (directly or indirectly) by hundreds of developers. My biggest reservation at this time is the need to combine certain modules into optimized bundles. Our organization utilizes hundreds of script files across many products -- we intend to wrap many of these to comply with the AMD pattern, but this is not sufficient without a good mechanism to build "bundles" to avoid large number of round trips. We're primarily an ASP.NET shop, however, we also have a number of teams that run php or java.

Thanks for the prompt rely!

[unscriptable]

I think as soon as you start using modules, you'll find want to break them down into smaller and smaller chunks of functionality, making the need for the build process even more important. :)

Here are some of cram's current limitations:

1. cram does not run Google Closure Compiler or Uglify for you. You must do that yourself (in a shell script, for example).
2. cram does not run on windows, yet. The next version could easily, though. It currently requires Rhino 1.7R2 (not R3). The next version will run on JavaScriptCore as well as Rhino1.7R3. Getting it to run on node.js or even windows cscript.exe will be fairly simple after those, too.
3. cram does not concatenate non-modules. For instance it will not concatenate jQuery.js into a built file (unless you add a define($); to the jQuery.js file and list it as a dependency of another module).
4. cram inlines css files that are encountered using the css! plugin. If you are not using the css! plugin, this is not a concern. A future version will allow you to build a separate, concatenated css file, rather than inlining the css into the built javascript file. If you want to use curl.js to load your own (non-modularized) css, I can show you have to do that without inlining it. It's easy, actually.

5. cram does not allow you to include or exclude files explicitly in the configuration. I.e. you can't tell cram to "combine files X, Y, and Z together". Instead, you must declare a "root module" (RequireJS calls these "main" files) and that root module has a define call that declares X, Y, and Z as dependencies.

   // my-boot-file.js is a root module define(['X', 'Y', 'Z'], function (X, Y, Z) { // do something with X, Y, and Z here });

This is the preferred way to do it, imho, anyways.

So, if you don't mind having to create root modules, don't want to build non-modules into your built files (or don't mind adding define() calls to them, aren't planning to modularize your css, and can run on Linux/OS X using Rhino, then the current cram (0.1) will work for you.

If any of the above limitations are a concern for you, let me know asap. People have asked for #2 and #4 and we'll be needing #5 before the end of September. Those are already "in the works".

-- John

[unscriptable]

I'm guessing that since you're in an ASP.net shop, that windows is a requirement. :D Just a wild guess.

[asilvas]

I appreciate the detailed info. This probably wont work for us just yet. But I might be able to swing doing the builds manually til it matures.

Thanks again!

[unscriptable]

The one catch to doing manual builds is the module ids. The define() calls must include the id:

define("my/module", function () { /* blah */ });

rather than using the "preferred" anonymous definition:

// my/module define(function () { /* blah */ });

It sounds like your use of modules is simple enough to use the module ids all of the time, anyways. Until/unless you start moving modules around, the ids can't hurt.

Check in again before you start doing the builds if you don't mind. I'll try to have something working on windows soon.

[tmaslen]

Hi unscriptable,

I'm in the middle of trying to concatenate all of my project's JS modules (optimization sprint before launch) into a single file using cram. I initially tried using Require but it didn't like curl's syntax of including non JS files (js!notamodule), so am now trying to use cram but have found the same issue.

Above you stated...

"cram does not concatenate non-modules. For instance it will not concatenate jQuery.js into a built file (unless you add a define($); to the jQuery.js file and list it as a dependency of another module)."

Could you explain this in more detail? I'm not sure how to do this.

Would you also recommend that I continue using cram, or is there a way that I can use require instead?

Thanks as usual, /t

[unscriptable]

Hey Tom,

The js! plugin needs to be updated to be able to inline non-modules into the built files. Currently, it only supports the load API, not the build API. This can be added, but will take a few days. We're also not quite done updating cram to work with curl.js 0.6.x.

My comment about jQuery is now out of date. jQuery 1.7.1 calls define correctly and doesn't need the js! plugin. However, if you're using the js! plugin for other non-modules, then there's still an issue.

Here are your options:

1. Work with us to get cram and the js! plugin working. We won't ask you to code anything, just let us know if you find bugs.
2. Convert to requirejs's syntax for js files and use r.js for optimization. You will also have to use requirejs's plugins, not curl.js's) since the build-time AMD API specifications are incomplete. Therefore, curl.js's build API is different from requirejs's. (Note: the css! plugin is a special beast, so let me know if you're using that and what you're expectations are regarding build-time behavior. Fwiw, the link! plugin is way simpler and will work with requirejs, too.)
3. Use a third-party requirejs plugin such as wrap! (https://github.com/geddesign/wrapjs) or depend! (https://github.com/millermedeiros/requirejs-plugins/blob/master/src/depend.js) rather than js! and use path mapping to map all uses of the js! plugin to one of those others (paths: { 'js': 'plugins/wrap' }). This should just work if you're not using the !order or !exports options of the js! plugin. You will have to use r.js to do the build.

I can't recommend what you should do, especially since I don't know how long your sprint is. If you say it's a week, then I would might take option #2. If you say 3 weeks, then it may be worth it to take option #1.

If you're leaning towards option #1, let me know. We're already getting tons of pressure to get cram.js into shape and have prioritized it for completion within the next three weeks. If you have some time and are willing to work with us to find bugs, we can probably get it working fine within the week.

Let me know.

-- John

[tmaslen]

Hey John,

We're going for option 2 at the moment as we don't have a lot of time to spare.

Thanks for your reply, we really like curl.js. Looking forward to see how you get on in the future with cram.

/t