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

Thanks for this!

        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;
        }

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.

It's C++.

    return( strdup( orig ) );

?

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

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

From what I understand there are some limitations to the implementation, but I haven't encountered any so far.

Instead of Compass, I've switched to using Bourbon (bourbon.io) but may consider just using Auto Prefixer in future dev efforts.

Source maps I can live without since I haven't gotten used to them. I know it's in the works or at least being thought about: https://github.com/hcatlin/libsass/issues/122.

In the computer benchmark games (http://benchmarksgame.alioth.debian.org), most of the benchmarks are heavy on floating-point arithmetic or raw loops, which are completely not for the case of web applications. You can also see in text benchmarks like regex-dna, Ruby performs much faster.

If you do benchmarks regardless the implementation details. You may find Ruby can be several times faster than Java in cases like AES encryptions: https://gist.github.com/luikore/7746976 --- though this is not a valid micro-benchmark, it is in fact comparing JCE and OpenSSL. But this is what real-world programs do and the speed of calculating Mandelbrot sets or simulating n-body systems really doesn't matter.

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)

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).

Was it rewritten in C++ later on?

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

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

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!

Edit: > 24,000 (counting all files this time ;-)

But I noticed that files missing a newline at the end weren't being counted correctly (missing 1 line in the count).

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.

This involves things like keeping linked libraries to a minimum (and only to use ones which are commonly part of a default unix install), actually testing on a few different platforms, using standard build tools (despite their wonkiness), avoiding (compiler|architecture|OS)-specific features, and all sort of other guidelines that one should follow when trying to write portable software.

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

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?

Though I completely get the portability aspect.

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.

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

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

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

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

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.

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.

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

This covers why I like Slim over HAML

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

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

Also, thanks for the supportive post!

I just tried the pre-release version of 0.13. I found it was installing something with native binding? I believe it was one of the dependencies on Compass. I don't think this works well for us as our build process relies on Maven with JRuby to power Compass.