As the creator of both Sprockets, which underlies Rails 3.1's asset pipeline, and Stitch, which the poster of this article ported beautifully from Node.js to Ru

As the creator of both Sprockets, which underlies Rails 3.1's asset pipeline, and Stitch, which the poster of this article ported beautifully from Node.js to Ruby, I feel obligated to reply here :) While CommonJS modules are undeniably elegant, they carry with them a high conceptual overhead. It would be unreasonable to expect Rails developers to rewrite all their existing JavaScript in order to take advantage of the asset pipeline. Most people do not want to manually import every dependency into every source file (and in fact Rails goes to great lengths to make use of Ruby's "require" method largely unnecessary). Sprockets solves this with the "require_tree" directive that automatically pulls in all source files in a given directory. If you've been keeping your JavaScript source files in public/javascripts, it's trivial to upgrade your app to 3.1 and take advantage of the asset pipeline — just move your source files into app/assets/javascripts. Then when you do need more specific control over source file ordering, the "require" and "include" directives are there for you. Combine this with the implicit closure around each CoffeeScript source file and Sprockets gives you 80% of the benefit of CommonJS modules with 20% of the complexity. Stitch (and CommonJS in general) does not address the problem of CSS preprocessing or concatenation, and does not provide a mechanism for managing other assets like images and sounds. Sprockets supports Sass and SCSS, and provides a global load path which lets you depend on JS, CSS and images from a single logical package — even a Ruby gem — with essentially no configuration. I hope this clarifies why we chose to go with the Sprockets approach rather than CommonJS for Rails 3.1.