This is quite fantastic. I think I'm going to make the switch very soon! I hope this'll save a few hundred milliseconds every time I hit `:w`. That happens a lot when I can stand the look of my ugly designs.
On the other hand, I don't see the long-term benefit clearly that would justify writing this in C++. Most of these open source mini-movements hit maintenance and motivation barriers after some time, not performance ones. Although this could mean Sass overcame the prototype phase quite successfully.
Also, at first sight it seems to me that the author of this library is the same as of Sass' itself. (Please correct me.) In this case, congratulations! Must be a real pleasure to see such a big improvement to what once was a pet project. :)
Actually, I'm the primary developer of the library (I work with hcatlin). Large Sass projects can take a long time to compile (more than several seconds), so the performance increase should not be dismissed. Also, providing a C/C++ library makes it easier to embed Sass in other languages and platforms.
Are there plans to e.g. make the Sass gem we all use take advantage of this native code? That is, will I one day do a `bundle update` and be rewarded with speedy asset compilation?
I just saw hcatlin's presentation on the future of Sass at RailsConf and he mentioned that large codebases (>50k lines) could take over 30s (think he said sometimes up to 2 minutes). One of his key points was that, since Sass is partially aimed at non-technical designers, it needed to be both faster and more accessible.
> While libsass is primarily implemented in C++, it provides a simple C interface that is defined in [sass_inteface.h]. Its usage is pretty straight forward.
Fair enough. My point was really just that the README discusses the specifics in more detail. The title of this thread is taken straight from the project's Github page. I don't think the title is wilfully misleading. I do think there are more interesting things to talk about regarding the project.
Cool! So if you want to, for example, embed Sass compilation in a web framework in $YOUR_FAVORITE_LANGUAGE -- Python, Haskell, some weird dialect of Scheme, whatever -- all it would take is a few lines of code to wrap a few C-style function calls.
That syntax has been essentially deprecated for a while now. I think one of the most important aspects of SASS syntax is that any valid CSS3 file is a valid SASS file and compiles without error.
This can't be true of the indented-syntax, which has two downsides:
* It's a huge barrier to entry for anyone new to the framework when they already know CSS.
* It makes porting and/or incorporating existing CSS unnecessarily complex.
(The same things could be said about HAML, but people generally have no problem writing HTML, while CSS is still a fluid and ever-changing system).
The indented-syntax is way nicer to look at, but it's a good thing that it's heading off into the sunset.
That's false actually. There is a "new" syntax, but the popularity of the language is in many ways due to the terse, easy-to-read original syntax—it's not going away and it's not deprecated.
You're right. It will be supported indefinitely through the gem - so neither officially deprecated or going away.
However, since .sass is no longer the primary syntax (nor default for Rails), and it's not supported by any new development efforts, it's safe to say that it is not the favored child.
Too late to edit anyways, but we're both right on this one. SCSS is a Sass syntax. ".scss" and ".sass" are both Sass files. Their docs tend to name the languages in titlecase, and the formats in all caps. That surely won't confuse anyone!
> Any contribution to the project are seen as copyright assigned to Hampton Catlin. Your contribution warrants that you have the right to assign copyright on your work. This is to ensure that the project remains free and open -- similar to the Apache Foundation.
On the other hand, I don't see the long-term benefit clearly that would justify writing this in C++. Most of these open source mini-movements hit maintenance and motivation barriers after some time, not performance ones. Although this could mean Sass overcame the prototype phase quite successfully.
Also, at first sight it seems to me that the author of this library is the same as of Sass' itself. (Please correct me.) In this case, congratulations! Must be a real pleasure to see such a big improvement to what once was a pet project. :)