
A C implementation of a Sass compiler - g3orge
https://github.com/hcatlin/libsass
======
pestaa
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. :)

~~~
akhleung
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.

~~~
alanh
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?

~~~
akhleung
There's a proof-of-concept Ruby gem, which will mature as libsass matures.

<https://github.com/hcatlin/sassc-ruby>

------
dcope
Misleading title and description. This is actually written in C++.

~~~
telemachos
> 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.

~~~
eridius
_A C implementation of a Sass compiler_

"implementation of". Not "interface to".

~~~
telemachos
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.

------
semanticart
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>

~~~
ddagradi
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.

~~~
drewyeaton
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.

~~~
ddagradi
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.

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

------
jvc26
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?

~~~
riffraff
not too uncommon, similar things exist elsewhere

<http://en.wikipedia.org/wiki/Contributor_License_Agreement>

------
pjmlp
Please fix the title, it is a C++ implementation.

Besides that, going native, great job!

------
agentgt
Its C++ not C. Although I suppose you could refactor it or call it from C.

