About Me
Feed
Sass Supports Rack
I’ve just released Haml and Sass 2.2.14. There are a bunch of useful changes in there; a few bug fixes, a few very minor feature additions. But there’s one feature in particular that’s more exciting than the rest: Sass now has native support for all Rack-based frameworks.
Just put this in yourconfig.ru:
require 'sass/plugin/rack' use Sass::Plugin::Rack
The Sass Rack plugin works just like the Rails and Merb plugins.
Every request, it looks for Sass files in public/stylesheets/sass
and compiles them to CSS files in public/stylesheets if necessary.
These paths can be configured like so:
Sass::Plugin.options[:css_location] = "./stylesheets" Sass::Plugin.options[:template_location] = "./sass"
See the Sass reference for a full listing of available options.
For now, using Rack support is completely optional. It’s never loaded unless the user explicitly specifies, as above. Rails and Merb will continue to use their default plugins for version 2.2.x. For version 2.4, Rails versions that support Rack will use the Rack plugin, although Merb may not.
Haml Benchmark Numbers for 2.2
Beautiful! I’m doing more work with Sinatra lately and this will make it even easier to use Sass.
Awesome, great addition to Sass.
This is brilliant – and coming handy, as I want to use it with Sinatra. Thanks for your work!
Whooa! A clean and handy plugin to use sass with rack based framworks! Nathan, thank you for your high quality work!
Hi,
I used the Sass Rack plugin for a couple of small Rack apps, and it works great. Not having something similar for Haml, I just put together a simple middleware to compile the files when needed.
That works, but I was wondering if there is any technical reason why there is no official Haml plugin. If there is no know roadblock ahead, I am interested in writing a Haml Rack plugin similar to the Sass one.
—dira
dira: Haml, unlike Sass, is generally meant to be used as part of a larger view framework, usually itself part of a web framework. It makes less sense to have it have a separate Rack middleware, unless you’re building a very bare-bones Rack app. In this case, it might make more sense to make a generic view middleware, possibly using Tilt to delegate between multiple view engines.
Hi Nathan,
thanks for the explanation.
Indeed I have some bare-bones Rack apps, with only one, static, haml. I was thinking about a Haml Rack plugin because I would love to keep it bare bones (without more generic – and therefore complex – middleware. :). But probably that’s a very specific use case, so I understand your point of view.
dira: Actually, I’d expect a Tilt middleware to be substantially simpler than a Haml middleware—or at least, push almost all the complexity into Tilt. Tilt will take care of things like caching, which otherwise you’d have to implement manually in your middleware.
with only one, static, haml. I was thinking about a Haml Rack plugin because I would love to