Libsass – C implementation of a Sass compiler

by kudu • 13 years ago

117 74 13 years ago

leif2• 13 years ago

I'm not a web guy, but isn't sass a CSS generator, as in something you run once before deploying anything? What's the advantage of speed for something like this?

jhgg• 13 years ago

Saves a bit of time when you're in the edit your scss/sass files -> refresh browser workflow. A designer friend of mine always complains about how slow the ruby sass compiler is for larger projects, but he says the time saved in writing stylesheets with it beats the time spent having to wait for them to compile.

chrisbolt• 13 years ago

Speed of deployment, especially for larger sites with more CSS to process.

dpritchett• 13 years ago

Faster deploys means more deploys means more features and fixes and a better chance of survival. See: John Boyd.

TylerE• 13 years ago

Depends. Many newer frameworks (Rails, at least, specifically) do not pregenerate but instead compile on the fly and then cache, at least in development mode.

Also, the canonical SASS implementation is in Ruby, which is a fairly heavyweight dep if you need it JUST for to compile SASS

akhleung6• 13 years ago

On huge projects, Ruby Sass can be quite slow, taking several seconds or even minutes to compile. If you have an interactive, iterative workflow where you're constantly refreshing the styles, having a faster Sass compiler can be a godsend.

clarle• 13 years ago

If you're in a language that allows C bindings, then it makes it easier to port a SASS library to that other language.

habitue• 13 years ago

Notably: https://pypi.python.org/pypi/sass

hcatlin5• 13 years ago

So, when big companies like Linkedin generate their Sass projects, it can take hours on a single machine. Tons of programmers all working in Sass.

At Moovweb, some of our customer's projects can take 30 seconds just for the Sass to compile for fairly straightforward sites.

leif2• 13 years ago

Ok, that's more drastic than I thought. I think I get the point now.

gkoberger• 13 years ago

Seriously? I believe you, but if it's taking hours then it seems like the problem isn't as much with SASS but rather the way they write CSS or their build process. If they only recompiled changed files, there's no way it could take "hours".

Even if they recompile everything... all CSS needs to be interpreted by the browser at some point. How much CSS do they have?

That being said, what are the speed comparisons like?

drdaeman• 13 years ago

Hours?

Either they have several gigabytes of CSS output (ouch) or they're using a ZX-Spectrum as a build machine. Or, possibly, they're constantly recompiling, like doing a change in SASS a hundred times per second.

Otherwise, interpreted script-based parser (given that it's written properly, algorithm-wise) should be sufficiently performant to produce results in a sane time.

colechristensen2• 13 years ago

With a C binding, this library is usable in more or less every language under the sun without messiness.

Written in the correct way, a library like this will compile and run on a 15 year old OS, and will probably run on plenty of OSes in 15 years. The dependency hell of building old language binaries with a dozen badly supported other libraries doesn't exist when you link to libc/libstdc++/etc.

There ought to be a speed advantage, but it definitely isn't the only motivation.

ufo• 13 years ago

What do you mean by "written in the correct way"?

twhid2• 13 years ago

Real world example: our project was taking almost 1 minute to compile via Ruby (all CSS).

Using sassc (libsass) that went to 5 seconds.

Development was where we saw real gains, different sections that would take 4-6 seconds to compile, went down to <500ms (our asset watcher is smart enough to compile only blocks of Sass files that are associated, not the entire site's Sass). Meaning that in the time it takes you to switch to your browser and refresh, the Sass would be compiled to CSS.

Made my devs life much, much better!

lightblade4• 13 years ago

Whoa! 5 seconds is still a long time. If you don't mind me asking, how many lines of SASS does the project have?

WalterSear4• 13 years ago

Every tiny change requires a recompile. On a really complicated site, that could be 30 seconds or more. And CSS is a >visual< language, that looks subtly different in all browsers and eventually requires a lot of 'stabbing in the dark' to find the perfect compromise.

nadinengland• 13 years ago

If you were making small changes to see what worked in different browsers, rather than editing the CSS or SASS, it may be more beneficial to use the browser's Web Tool to do it live!

vezzy-fnord• 13 years ago

Given that this is a C++ implementation, why the incorrect article and repo title?

Was it rewritten in C++ later on?

Otherwise, it seems interesting. I'll look into it.

solox3• 13 years ago

While libsass is primarily implemented in C++, it provides a simple C interface that is defined in [sass_inteface.h].

sheetjs• 13 years ago

To be fair, that argument can be applied to most scripting languages:

A C header for a C++ library that integrates V8 and runs JS code can, according to your logic, count as a C implementation.

hcatlin5• 13 years ago

Wow, didn't expect to see this at the top of HN. Thanks kudo for promoting the project!

Aaron Leung and I have been working on this for a while. I'm the original creator of Sass and Aaron is a badass computer linguist. Hoping to announce some big new features around the end of the year.

Official site is at: http://libsass.org Or, follow us on Twitter for more updates: @hcatlin & @akhleung

akhleung6• 13 years ago

Yes, playing catch-up with Ruby Sass has been difficult (the sophistication and subtlety of some of Sass's features are impressive), but we're hoping to make some big leaps by the end of the year!

mradmin• 13 years ago

Are you planning on creating the sass-convert utility?

kudu• 13 years ago

No problem, thanks for your work on Sass! I suggest linking to the website from the GitHub repo, I hadn't seen it.

mhogomchungu• 13 years ago

a bit of optimization in $src/libsass/copy_c_str.cpp

        char* copy_c_str(const char* orig)
        {
                size_t len =  strlen(orig) + 1 ;             
                char* copy = (char*) malloc(sizeof(char) * len );
                memcpy(copy, orig, len);
                return copy;
        }

akhleung6• 13 years ago

Thanks, I'll give it a try and benchmark it. Also, pull requests are welcome for this sort of thing!

mtklein• 13 years ago

or maybe just #define copy_c_str strdup ?

unwind• 13 years ago

Uh, okay. I didn't read the original, sounds somewhat scary.

Anyway, please don't cast the return value of malloc() in C (http://stackoverflow.com/a/605858/28169).

Also, of course len should be const and sizeof (char) should be removed. Also testing whether malloc() succeeded before relying on the result being valid is a good idea (but perhaps there's machinery in place to abort on error), as is deciding what to do if the input string is NULL.

stevekemp• 13 years ago

Wouldn't this be even better:

    return( strdup( orig ) );

?

WalterSear4• 13 years ago

I'm sure I'm not the only person who's spent more time than they should trying to decide whether rebuilding sass would take longer overall than just waiting for the ruby one to finish compiling something :)

Thanks for this!

nightwolf• 13 years ago

JFYI: The link to SassC on http://libsass.org is broken.

danenania• 13 years ago

This is great as compilation in ruby really is painfully slow for anything substantial, but I wonder about the choice of an independent project vs. forking the ruby compiler and optimizing the bottlenecks with C extensions. Might that allow you to fix the most serious issues without having to worry about maintaining feature parity in a completely separate code base?

In any case, nice work. I look forward to trying it out in my next project.

iamlacroix• 13 years ago

One benefit of being a separate project is that it can be used with non-Ruby wrappers. See node-sass https://github.com/andrew/node-sass as an example.

WalterSear4• 13 years ago

And consequently from that project: https://npmjs.org/package/grunt-sass

Since I'd guess most people interested in the node version will want the grunt one.

luikore2• 13 years ago

Ruby is fast in non-benchmark jobs like text processing. It's not ruby slow, it's sass's implementation of dependency analysis slow. Good compilers in Ruby, like Slim is even faster than most template engines in Javascript or Go.

pmr_• 13 years ago

Can you provide a source for the first statement? It seems unlikely to me that a language implementation is going to be fast on text processing which is essentially a aggregate task of what most benchmarks try to profile individually, but I could be missing something less obvious.

calinet6• 13 years ago

Let's get down to brass tacks—is there a ruby gem which can use this and drop into the Rails asset pipeline to speed it up? If not, what would be the best way to get that started?

Edit: found this: https://github.com/hcatlin/sassruby -- Looks like it's not quite mature enough, but promising!

charliesome• 13 years ago

is there a ruby gem which can use this and drop into the Rails asset pipeline to speed it up?

Often the source of slowness in the asset pipeline is not the compilation but the asset pipeline itself. It does some weird stuff.

I'd imagine dropping a libsass based SASS compiler into a Rails app wouldn't actually translate into much of a performance improvement.

pilif• 13 years ago

I'm periodically updating a PHP binding to libsass on my companies github account here: https://github.com/sensational/sassphp

It was my intention of keeping up with releases, but it looks like updating it periodically to git HEAD of libsass might be what's needed. I'll look into getting the submodule updated to a later release today.

That said: last summer when I started maintaining this fork of an earlier binding, I noticed that libsass (even tag RELEASE-1.0) was in a bit an early state of development: HEAD was flat-out segfaulting and RELEASE-1.0 was producing miscompilations.

I've reported a few bugs but in the end, we've settled back with ruby sass for the time being. The speed up is nice, but only if the library is actually producing valid output without crashing.

Maybe by now this is better and I should give it another go :-)

Also, I'm certainly no C++ programmer and thus this might be common, but their template based parser with a lot of implementation code in a header file kind of scares me (https://github.com/hcatlin/libsass/blob/master/prelexer.hpp)

akhleung6• 13 years ago

We did a lot of development during the summer (including a rewrite that was long overdue), so there were a few segfaults back then. The library should be pretty stable now though -- we've embedded it into our SDK and build system, and it's been working fine.

As for the parser -- that started out as an experiment of sorts. I wanted to do something like parser combinators (but for scanning), and I decided to templatize the whole thing so that all of the scanning code would be generated at compile-time. If I were to redo it, I'd probably use expression templates (which I didn't know about at the time).

lobster_johnson2• 13 years ago

Unfortunately it only implements the curly-brace SCSS syntax, not the indented SASS syntax [1] (which is weird considering it's called Libsass, not Libscss), and there are no plans to support both syntaxes.

The companies I have worked for all use the indented syntax, since it meshes very well with HAML and CoffeeScript. But it looks like more people use the brace syntax (roughly 980k SCSS files on Github, vs. 85k SASS files).

[1] https://github.com/hcatlin/libsass/issues/16

akhleung6• 13 years ago

We do want to support the indented syntax eventually (and I believe it should be possible with a relatively simple pre-processing step), but it's still a low priority compared to reaching feature parity with the canonical implementation.

myers• 13 years ago

I agree about fitting in well with HAML and CoffeeScript. You might also consider Slim as a less noisy HTML shortcut language.

This covers why I like Slim over HAML

http://me.phillipoertel.com/articles/2013/02/03/why-i-like-t...

lobster_johnson2• 13 years ago

I don't know. I wish developers could stop reinventing/tweaking stuff that isn't particularly broken (the differences between HAML and Slim, for example, are marginal and not really interesting) and start standardizing on something. Node, meanwhile, seems to have standardized on Jade.

chavesn• 13 years ago

I know this is completely juvenile of me, but I can't help but see "libs ass".

It's kind of like "xbone". I'm sure it's not intentional, but people will see it nonetheless.

lightblade4• 13 years ago

Do wanted to note that this does not work with Compass currently as Compass extends SASS with Ruby.

legutierr• 13 years ago

Are you aware of any plans for Compass to remove the Ruby dependency?

lightblade4• 13 years ago

I don't know, but I suspect it doesn't looks positive. Compass haven't had any new releases for a year now.

antihero• 13 years ago

I think a better direction would be for projects to remove their compass dependency.

mfkp• 13 years ago

For all the Go fans out there, I built a sass watcher/compiler using Go + libsass, I'd love to get some feedback. https://github.com/mfkp/gassy

chrismorgan• 13 years ago

So, three months ago they started using Travis CI and, as far as I can tell from looking at the results (https://travis-ci.org/hcatlin/libsass/builds), not once have the tests actually passed. (Builds 1 and 2 failed silently and build 8 didn't test anything. The rest were all detected as failing.)

akhleung6• 13 years ago

Ah, that's because Travis is running all of the "to-do" tests as well. Reorganizing the tests and making Travis happy is ... well, it's on the to-do list.

hcatlin5• 13 years ago

Yeah, its run against the WHOLE sass spec!

Also, thanks for the supportive post!

pjmlp• 13 years ago

It looks like C++ to me.

smrtinsert• 13 years ago

I really want a pure js impl.

phaer• 13 years ago

Write one :)

__david__• 13 years ago

I've been maintaining a Perl binding to libsass.

CPAN page here: http://search.cpan.org/perldoc?CSS%3A%3ASass

Github here: https://github.com/caldwell/CSS-Sass

pedrocr2• 13 years ago

Any contribution to the project are seen as copyright assigned to Hampton Catlin, a human on the planet earth. Your contribution warrants that you have the right to assign copyright on your work. The intention here is to ensure that the project remains totally free (liberal, like).

That's a curious setup. The license is MIT so you're not getting the "if you distribute it you have to use the same license" that you get with GPL. So as long as the contributions use the same MIT license why does the author need copyright assignment? The MIT license is simple and standard enough that relicensing doesn't seem like a likely need.

hcatlin5• 13 years ago

Good question. I've gotten conflicting legal advice. Some say I need full signed contributor agreements for everything, no matter the license, and some say that's not needed at all. I opted for something in-between. Just a notice that could cover our ass in the future. Several big companies are working on submitting code, and so licensing there can get tricky... hence, just go overkill and never worry about it. ;)

pedrocr2• 13 years ago

Thanks for the reply. That makes sense. I don't see why saying "anything that's contributed is MIT licensed" wouldn't cut it but I'm no lawyer... :)

Libsass – C implementation of a Sass compiler

Related Stories