Tuesday, July 13th, 2010

Quilt: Stitching Your JavaScript Modules Together

Category: JavaScript

It floors me what young, talented developers are building these days. Kit Goncharov, who only recently turned 17, just cranked out Quilt, a JavaScript preprocessor written in JavaScript.

Quilt is very similar to the Sprockets JS preprocessor in that it allows you to improve code organization by logically separating your code into multiple modules within their own specific directories. Instead of having one massive JavaScript file with all your source code in it (increasing the potential for errors and complications), you can break out your code into separate physical files and at build time, allow Quilt to roll it all up, line by line, into a single file, ready for deployment. Via support for directives, you can tell Quilt about dependencies to ensure your builds are structured the right way.

In addition, if you use third-party frameworks in your code, Quilt allows you to specify a “load path” or “search path” which tells the preprocessor where to look for your specific lib. Then, when you build the final concatenated output, the library is included right in the source code.

Although Quilt was heavily inspired by Sprockets, it does have several significant differences. Perhaps the most obvious is that it’s written in pure JavaScript (as opposed to Ruby) and runs on Rhino. This means it’s very portable and easy for JS developers to understand. Quilt also uses a slightly different syntax than Sprockets for including files (for instance, it allows single-quoted pathnames, and uses backticks instead of angle brackets for specifying third-party code), and can strip multi-line comments as well as single-line ones.

As our client-side applications continue to grow, these types of solutions are becoming increasingly important for having a well-structured and maintainable codebase and it’s great to see that the future development leaders are taking that into consideration. Be sure to check out Quilt along with Kit’s other projects on GitHub.

Posted by Rey Bango at 7:00 am

4 rating from 1 votes


Comments feed TrackBack URI

Why do people try to implement minifiers in their preprocessor and forget the most basics preprocessors command like #define, #undef, #if, #ifdef, #ifndef, #else, #elif, and #endif.

Basics minifiers have nothing to do in a preprocessor, most of the time they are a nuisance who breaks the other parts of the build process which depends on specifics comments.

Just use the right tool for the right job.

Comment by ywg — July 13, 2010

Just forgot : I’ll give it a try, if it’s stable I’ll migrate my projects and get ride of Sprockets which is the only part of my build process not based on Java/Rhino. I’t will make them easier to redistribute.

Comment by ywg — July 13, 2010

@kitgoncharov – I can’t wait to try this with FuseJS and because Quilt is on github it makes using it as a submodule so nice!
I am excited about the simple doc parser too. I noticed in the readme that you support /*! style comment compatibility with YUI compressor. Do you plan to eventually automate and pass the minification tasks off to it?
Keep up the prolific coding :)

Comment by jdalton — July 13, 2010

@wyg: Sorry, I’m not quite sure what you mean…apart from stripping comments (configurable via an option), Quilt doesn’t actually minify JavaScript source code. Can you please elaborate a bit?
@jdalton: Awesome! I’m excited to see this in FuseJS, too…as soon as I’m done rewriting the unit tests for Scotch (which shouldn’t take too much longer), we can remove the ERB dependency and use Quilt. I’ve also replaced Scotch’s Ruby build system with Quilt, so you can see it in action.
Re:documentation. Yep, I’ll try to finish that up this week, too. Quilt 0.1 had a working implementation, but the API seemed far too clunky and inflexible…with the 0.2 rewrite, it should make it a lot easier to add doc generation (and other plugins).
Re:comments. That’s precisely why I’m using that syntax. :) Since YUI Compressor (or Closure Compiler, for that matter) is a Java library, I can script it right from within Rhino and automate minification.

Comment by kitgoncharov — July 13, 2010

Whoops, sorry @ywg. Misspelled your handle. :)

Comment by kitgoncharov — July 13, 2010

I have this too. It’s called cat.

Comment by balupton — July 13, 2010

@balupton: Yes…but `cat` doesn’t do dependency analysis, comment stripping, constant interpolation, or doc parsing. :)

Comment by kitgoncharov — July 13, 2010

@kitgoncharov :
My point is that people that will use Quilt are obviously using it as a piece of a complete build process. Most of the building tools relies on specific comments syntax. By removing comments you just make the building process (and Quilt) more complex and less reliable. I understand that this can be disabled by a simple option or a special comment marker, but is this really necessary ? Most build tool have the bad idea to integrate a comment stripper… this is how you end up with insanely complex comments syntax like “/*!*#”. This is unmaintanable, if you change one step of the build process everything breaks and you have to reformat all your comments.
Preprocessing is the first step of the building process, comments stripping and minification is the last.
Quilt will be a better preprocessor without comment stripping and without documentation parsing. Try to focus on preprocessing, there’s still a lot of preprocessor functionnalities to implement. If you want to do a documentation tool or a minimifier make this in a separate tool. This do not belong to a preprocessor.
Just embrace the Unix philosophy: Write programs that do one thing and do it well.

Comment by ywg — July 14, 2010

@ywg: Thank you for clarifying your point…I completely agree with you. When I was using Sprockets to preprocess and concatenate my code, I found the comment stripping feature quite useful; however, I didn’t take into account the fact that most build tools also rely on such comments to fulfill their respective directives. The `/*!` syntax was intended primarily for feature parity with the YUI Compressor, but you’re absolutely right: this functionality belongs in a dedicated minifier, not a preprocessor.
With that in mind, I’m currently working on rewriting Quilt to make it significantly more modular and extensible. The single `Concatenation` class will be supplanted by a `Concatenator`, a `Documenter`, and a `Minifier`. All three of these classes will implement an abstract `Parser` class, which will scan each JavaScript module and collect the necessary source lines. This will also make it easy to customize Quilt, as you’ll be able to add your own custom preprocessor by simply subclassing `Parser`.
As to the further preprocessing functionality that I can add to Quilt: I’ll investigate the C preprocessor and see if I can implement or port some of its functionality. Like Sprockets, though, I want for Quilt to remain a non-evaluative parser (i.e., statically analyzing each JavaScript module, as opposed to executing it), so some features, such as conditional compilation with `ifdef`, might need to be significantly modified for use with Quilt.
Finally, I’d like to thank you for the valuable feedback that you have provided. If you have any other suggestions for improving Quilt, please don’t hesitate to let me know!
P.S. “Write programs that do one thing and do it well” — this is a mantra that I’ve continuously struggled with, although I’ve often found that a from-the-ground-up rewrite works wonders for pruning most extraneous code. :)

Comment by kitgoncharov — July 15, 2010

Leave a comment

You must be logged in to post a comment.