Sprockets is a tool from the makers of the “Prototype” Javascript library designed to ease the integration of multiple files via an inclusion system. yavascript is that and so much more, integrating syntax-aware minification and conditional compilation. While writing up my report on yavascript as part os my third year project I had to justify why I chose not to use Sprocket’s way of doing things. The simple answer is I didn’t want to, I like C and wanted to do it C’s way, but I figured that wouldn’t cut it in a technical report, so this led to a serious critical analysis of both systems.

In my report I mention that yavascript’s design went through three major phases, what I don’t mention is that the third phase began less than two weeks before the project was due in (as I wrote a post about the other day). The third phase could have easily used Sprocket’s “//=” style directives, giving greater compatibility with other scripts as it’s also a comment, so why use “#” instead?

Apart from liking “#” I don’t like the way they did their definitions. Having them all in a single file destroys all modularity, everything needs to be merged properly. I also don’t like their way of inserting definitions:

var a = <%= MY_DEF %>;

Having said that, their solution to directives is quite nice, allowing greater integration by being different yet valid. The only concern I had was that the directive set is very small (currently limited to two, one of which I’m not interested in). for yavascript I have implemented “#if”, “#ifdef”, “#ifndef”, “#else” and “#endif” for conditional compilation and “#define” and “#undef” for macros. There is nothing stopping these being converted to the “//=” prefix, which would bring greater cohesion into the JS community (not that yavascript currently has a large share), yavascript has a lot to offer and being compatible with existing systems would be a great booster for it.

The issue here is that as unofficial extensions to the Sprockets directive set these would face possible rejection or incompatibilities if Sprockets were ever to be upgraded. I’m going to try discuss this with the Sprockets team and see if it’s possible to get some form of (very) rough API drawn up to given an idea of future moves, even if neither party implement the extensions just yet.

The final point I came up with is that their “//= require” directive is far more akin to Java’s import than C’s or PHP’s “include” or “require”. It makes sure the code is in once and once only, providing functions to scripts, but not code. Although yes, the most obvious solution to wanting to execute the same piece of code multiple times in different areas would be to put it in a function and call it, but their single include limitation removes the OPTION of having the same code in multiple places. Highly pointless example:

message.js:

alert

main.js:

//= require "message.js"
("Hello");

//= require "message.js"
("World");

The obvious usage being to swap out “message.js” files for different targets:

alternate message.js:

console.log

There are other solutions to this (although none quite so end-user fast or small, but so close as to make no difference), but I’m sure there are better examples.

Anyway, I would propose, based on both APIs:

• //= require
  Ensure a file exists once
• //= include
  Insert given code file regardless of previous inclusion
• //= provide
  Sprocket’s existing provide
• //= if
  Conditional compilation based on known constants
• //= else
  Failure code for “//= if”
• //= endif
  End code optionally included from “//= if” and “//= else”

I’m not sure about definitions, I obviously like my implied style of “//= define” and “//= undef”, but this would be in direct contradiction of their style. I’ve also got “//= ifdef” and “//= ifndef”, but they’re hardly worth noting. Any other extensions I’ve not thought of would be good.

API · javascript · Prototype · Sprockets · yavascript

3 comments

<< yavascript debug mode

Bad NoScript update >>