A C implementation of a Sass compiler(github.com)
github.com
A C implementation of a Sass compiler
https://github.com/hcatlin/libsass
10 comments
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?
There's a proof-of-concept Ruby gem, which will mature as libsass matures.
https://github.com/hcatlin/sassc-ruby
https://github.com/hcatlin/sassc-ruby
[deleted]
I'm the primary author of Sass. Hampton came up with the original idea, but he hasn't worked directly on the language in years.
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.
> I hope this'll save a few hundred milliseconds every time I hit `:w`.
“few hundred milliseconds”? In a project where I'm working, our SCSS files take almost 10 seconds to recompile after every little change.
Maybe this new compiler will make the development less painful.
“few hundred milliseconds”? In a project where I'm working, our SCSS files take almost 10 seconds to recompile after every little change.
Maybe this new compiler will make the development less painful.
We're also working on improving the compilation speed of the canonical implementation. 3.2 will have some improvements that should help considerably.
Misleading title and description. This is actually written in C++.
> 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.
A C implementation of a Sass compiler
"implementation of". Not "interface to".
"implementation of". Not "interface to".
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.
[deleted]
^ "misleading" comment.
PS. Upvote if you got it :)
PS. Upvote if you got it :)
This is super exciting in terms of speed, but I'm saddened that the indented-style syntax isn't supported.
https://twitter.com/#!/hcatlin/status/194558078098747393
https://twitter.com/#!/hcatlin/status/194558078098747393
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.
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.
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.
“any valid CSS3 file is a valid SASS file” — Clearly you mean .scss. I imagine you’ll fix that in a minute :)
I’m also not so sure that this parser can only handle one of the two SASS syntaxes — what gives you that impression?
I’m also not so sure that this parser can only handle one of the two SASS syntaxes — what gives you that impression?
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!
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.
Slightly bemused by the licensing agreement:
> 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.
That seems a little non-standard to me?
> 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.
That seems a little non-standard to me?
not too uncommon, similar things exist elsewhere
http://en.wikipedia.org/wiki/Contributor_License_Agreement
http://en.wikipedia.org/wiki/Contributor_License_Agreement
Please fix the title, it is a C++ implementation.
Besides that, going native, great job!
Besides that, going native, great job!
Its C++ not C. Although I suppose you could refactor it or call it from C.
[deleted]
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. :)