Interesting points. I would never use Closure because of many of the stated points, since I would never want to risk being stuck with such a monolithic set of t

Interesting points. I would never use Closure because of many of the stated points, since I would never want to risk being stuck with such a monolithic set of tools. Same reason I don't want to touch GWT with a barge pole. Sass and Less, on the other hand, are particularly elegant because their stated scope is very small. There's still no alternative to Closure Compiler. Mozilla Rhino and the YUI JavaScript compressor both do the same thing (AST parsing, analysis and rewriting) and have existed for a longer time. We used Rhino exclusively for several years until Closure came along. Closure produces a little more compressed code, but Rhino had fewer bugs for a while. There's no alternative to Closure Templates if you want to fill templates on both the client and server sides I believe there are several templating solutions that allow the same templates to be run server- and client-side. Mostly based on Node, if I remember correctly. It can globally optimize your CSS classes across JS/HTML/CSS That's interesting and useful. How does it correctly identify JS code that uses CSS classes? Does it look for $() and .addClass() and so on? Sounds potentially brittle. Does it work with, say, Rails or Sinatra apps? Closure Templates are trivially internationalizable I18n is a solved problem outside templates, surely. Eg., look at Rails i18n.