Sprockets: Beautiful and angular
Over at SvN, Sam announced the 1.0 release of Sprockets, the new dependency management and concatenation tool that makes it easy to modularize your JavaScript. Sprockets is Prototype’s new build system, but it’s also been extracted into a Ruby library so you can use it anywhere you write JavaScript.
There are many great ways to use Sprockets in your own projects. You can use it the way Prototype does — split up your JavaScript into small, maintainable files, then create “meta-files” that include the smaller files in a logical order. Prototype had previously been doing this with plain ERB; now we integrate Sprockets as a Git submodule and use it to build our distributable file.
Sprockets can also be used to write JavaScript “plugins”: bundles of files that can easily be integrated into existing code. With Sprockets, you can formally declare that foo.js depends on thud.js; when your files are concatenated into one output file, thud.js will be included first.
In addition, Sprockets lets JavaScript files provide other assets — HTML, CSS, images, and the like. At build time, those assets will be copied into the document root of your server (in a way that preserves the sub-structure of directories within). This allows the plugin to refer to those assets via absolute URLs, instead of having to ask you where they’re located.
A few facts are worth special mention.
- Sprockets does not require Prototype. Sprockets directives can be inserted into any arbitrary JavaScript file. You can use Sprockets in your build system no matter which JavaScript framework you prefer.
- Sprockets does not require Rails. Sam has also written an excellent
sprockets-railsplugin, one which deftly applies the conventions of Rails plugins to JavaScript. But he has also written a generic CGI wrapper around Sprockets that is framework-agnostic. Or, instead, you can integrate Sprockets into your build cycle without bothering your server stack with the details. If you use Rake, you can do this with Ruby, as Prototype does; otherwise you can use thesprocketizebinary from the command line. - Sprockets-enabled JavaScript files can work just fine without Sprockets. If your plugin has its own “build stage,” then the distributable JavaScript will include no Sprockets directives. On the other hand, if your plugin is small enough not to require this overhead, your distributable can be a short JS file that declares its external dependencies at the top. Because
requiredirectives are an extension of comment syntax, they won’t confuse a JS interpreter.
In short, we’re excited about what Sprockets means for the Prototype ecosystem. If you maintain a Prototype add-on library, the prototype-core mailing list would love to help you make it Sprockets-aware.
Now is the time on Sprockets when we dance.
Sorry, comments are closed for this article.
Comments
Yes,it’s the best framework i have ever seen!
This is pretty interesting, I will give it a try today, I have been looking for something like this for some time, and finally you delivered it, few days back I was going through the Prototype source code in Github, I saw those ‘require’ directives in the code but thought it might be just comments but now I’ve realized what they are, thanks for the great job, keep the good work up!
cheers!
What are your thoughts on building a web front-end for this and allowing people to customize their Prototype download? Not everybody wants to install ruby just to do custom builds.
High five! I just finished some rake tasks to help me with this exact problem.. guess I’ll have to go check out Sprockets now and enjoy removing some old code!
@Snook: Custom builds would require that we make the code base more internally modular. The individual JS files in our tree are still dependent on one another, and we don’t see that changing any time soon.
If Prototype grows much bigger, we might divide it into modules, but until then we don’t think it’s worth the effort.
I have integrated sprockets with my CD3 Widgets ( http://github.com/RStankov/controldepo-3-widgets/tree/master ) but I was wondering the other day if Prototype license, gives me the writes to include //= require <prototype> directive in my mini-framework ?
I’ve read about the Sprockets release, but still can’t get my head around it exactly. It seems nice, but what’s the difference from manually aggregating files, with YUICompressor for example (well, apart from the fact that it’s manual of course)?
I’ve read the info on the Sprocket site as well as on other blogs (such as this) describing it, but I’m still not convinced.. :-)
Thanks for an awesome JS lib, btw! It rocks (but please stay alive and keep updating![]())
:-D
@Ace: The fact that it’s manual means that you have to know the order in which your scripts need to be joined. Sprockets’ “require” directives explicitly state: “The referenced file needs to have been included by this point, or else the code that comes next won’t work.”
Consider that Sprockets also verifies that you have all the required dependencies. It will throw an error at build time if you do not.
And I should note that the Sprockets build process can incorporate something like YUI Compressor as a final step; in fact, it’s being discussed in this ticket.
I know this is an impossibility, but you might drop rake/ruby and make it work like JavaScriptMVC’s include.
Basically, use rhino, and env.js to load the page server side. Detect where script tags are loaded (either in the HTML or dynamically), and put the text into the single production file.
This will work with something like how Scriptaculous load components.
If Prototype is interested, I’d be happy to work on extracting this from JavaScriptMVC as a joint project.