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