

Why Sass And Languages Like It Will Triumph - jlong
http://wiseheartdesign.com/articles/2010/01/18/the-demise-of-css-why-sass-and-languages-like-it-will-triumph/

======
jeff18
The demise of CSS seems a little dramatic. Sass looks sort of cool, and I'm
glad it exists, but it seems more like a small nicety rather than a
fundamental, web development game changer.

~~~
dbz
Exactly. CSS changed html dramatically. Sass most certainly does not do the
same for CSS. If anything, imho, CSS will evolve to allow some of the "oh
great and wonderful" Sass `abilities`.

Okay fine. I'll admit it. I'm hugely disappointed after reading a title like
that- and an article like that. The exact phrase isn't coming to mind, but
it's something like "All developers are excited about their new technology and
think it will change the future" (But in reality it wont matter in five
years).

~~~
jlong
To be fair this isn't my technology. I didn't invent Sass. But having used it
for over two years now I can say it is a huge improvement over CSS. And yes
hopefully the features found in Sass will eventually make it into CSS, but if
it replaces CSS or is incorporated into CSS isn't that the same thing?

~~~
dbz
There is a slight difference conceptually. The goal/concept of CSS is to
simply html AND provide a means to generate advanced layouts (while keeping
the simplicity). The goal/concept of Sass is to speed up the process of
writing CSS because well, even if you know what you want, it's pretty damn
time consuming. (Note: I say the exact same thing about html and will prove a
`post script`.)

And when I said it would incorporate some of the features, I really meant
"Eventually CSS may become a very primitive scripting language with variables
and functions," but I didn't quite say that because at the same time I'm
thinking "JAVASCRIPT!" So to be honest, imho, CSS will never incorporate
anything from Sass- ever. However, there is a good chance _text editors_
(inferable via my `post script`) will.

P.S I recently pounced upon a project called zen coding:
<http://code.google.com/p/zen-coding/>

Does pretty much the same thing, but with html. It's a plugin and there is
support for different editors. It's pretty awesome- By does pretty much the
same thing, I mean it allows you to write html code very quickly by writing in
a "shorthand."

~~~
charlesr
The next version of Zen Coding is going to support Haml:
<http://twitter.com/zen_coding/status/7665962389>

They may look similar, but you quickly realise they're not if you actually
give them a decent try out.

------
Pistos2
I won't use Sass, Haml, LessCSS or things like that until I see Sass, Haml and
LessCSS in Firebug or View Source (or whatever your choice of web development
tools). The claimed benefits are nice in theory, but I think it is a debugging
roadblock to have to mentally translate and associate your source code with
what the web server serves.

If I code in CSS and HTML, that problem is practically nonexistent (excepting
things like templating). The CSS and HTML the web server serves _are_ the CSS
and HTML in the source code.

~~~
rubyrescue
to further the point, when you EDIT styles in the browser, you are always
working on the generated file. Editing styles in the browser is WAY more
common than editing HTML in the browser, and because the tools with which you
edit the CSS in the browser generate CSS, it becomes much more tedious,
ironically, to do a lot of CSS work, then convert to Sass.

~~~
rufo
Perhaps it's just the way I work, but generally if I'm adjusting CSS in the
browser, I'm previewing how some potential changes will work. I already know
what the affected class is (since I'm editing it inline), and I've already
targeted the CSS I'm about to modify, so once I'm done previewing it's a
simple matter to go back to the Sass and change things around.

------
voidpointer
Notice how similar this is to what happened when programming computers was
made easier through the introduction of high level languages. CSS (and HTML)
are the the Assembly Language of web page layout. The more standardized they
become, the more it makes sense to use higher level abstractions in order to
produce code. JavaScript frameworks which hide particularities of the
different browsers are another part of the same equation. This is progress.

~~~
BrandonM
Heh. Someone didn't finish reading the article (including at least 5 others
who thought this comment was insightful).

------
houseabsolute
Someone should write an article on why technologists are so excited/desperate
for the future in which they believe all the right things must surely happen
because all the right reasons are in place.

~~~
jodrellblank
I read the title and I thought "this is going to say 'because it's better'.
When does that correlate with massive technology standard popularity?".

What's next for CSS? Probably CSS Current_Version+1, designed by committee,
late, missing really desirable and important features and including really
lame and awkward features, not exhaustively specified and not implemented
completely by anything other than Opera, and not done in the same way on all
browsers.

"Someone should write an article on why technologists are so excited/desperate
for the future"

Nobody ever writes about a utopian future filled with backwards compatibility
and design by committee. Is the future more rosy because it works as an
imagined place without the thorns and caterpillars and fungi and drought and
hay fever and pollen allergies and cheap imported roses and Monsanto seeds?

~~~
jlong
"What's next for CSS? Probably CSS Current_Version+1, designed by committee
[...]"

But this is the beautiful thing about popularizing the concept of compiling to
CSS. Once you are liberated from the Browser's implementation a whole new
world opens up. Experimentation can be conducted in languages that compile to
CSS.

Right now the reason why we need a committee to decide what goes into CSS is
that we all suffer the consequences if they get it wrong. With languages that
compile to CSS, bad ideas only hurt that language.

Freedom for experimentation can only be good for CSS in the long run.

~~~
toothcomb
But sadly you have to consider the browser's implementation. Or are you
referring to the little macros's or mixins or whatever they are called?

~~~
nex3
I believe jlong is referring to the functionality added by an abstraction
layer. Sass allows people to experiment with additions to CSS, and it gives
the CSS designers good insight into what people would find most useful.

~~~
toothcomb
Css has been thwarted by poor implementation that has led to confusion, and
elitism. With regards to abstraction I don't see why there aren't any
excellent WYSIWYG editors.

~~~
nimbupani
There is, it is called WidgEditor
<http://www.themaninblue.com/experiment/widgEditor/>

------
mmastrac
This reminds me vaguely of what Coffeescript does for Javascript
(<http://jashkenas.github.com/coffee-script/>). It's a nicer, more modern
syntax than the underlying language.

The killer is that they both require a compile to make it usable by a web
browser. It would be far nicer if the compilers were written in JS and
processed the languages dynamically.

The final compile before deployment can still happen via command-line tool,
but this lets developers work in a simple edit-save-refresh environment.

~~~
ryanwaggoner
Or even better, a server-side module or component that Apache sends all .sass
files to, and it outputs css.

~~~
jlong
For development I like to use Serve: <http://github.com/jlong/serve>

------
gnaritas
I prefer LESS <http://lesscss.org/> because it does something SASS doesn't, it
simply extends CSS with new features using the existing syntax allowing you to
use it on your existing code without having to rewrite everything into someone
else's idea of a simpler syntax.

It's much simpler to tell your designer "here, now you have x new features"
than it is to tell them they have to learn an entirely new syntax and "on by
the way, you need to rewrite all your existing CSS to use this."

~~~
nex3
Sass is coming out with a new syntax that's an extension of CSS. It's
available to use right now: <http://github.com/nex3/haml/commits/scss>

------
halo
I don't think the idea that people will use tools to automate generation of
CSS is a new idea, nor is it worth claiming the "demise of CSS" over it since
it's only a paper-thin abstraction over CSS anyway. People aren't calling web
scripting languages "the death of HTML", afterall.

I'm not sure the analogy between languages compiling to machine code is a
particularly good one. High-level languages compile to machine code because
it's extremely tricky to create or update hardware to support high-level
languages, and machine code is especially ugly. Neither of these apply to
anywhere near the same extent to CSS, which significantly reduces the
advantages of added abstractions.

I'd also be way of calling Sass a "programming language". CSS preprocessor
would be more accurate.

~~~
ighost
I agree, CSS preprocessor is a more fitting term.

It does trivial macro expansion and arithmetic. No control or data structures.

~~~
chriseppstein
That's incorrect. Your knowledge is more than 1 year old.

SassScript is Sass's built in scripting language and it is turing complete.
Here's a stylesheet that calculates and displays the mandlebröt set using
background colors:

<http://gist.github.com/280756>

------
brettnak
My company uses this and I write a lot of the front end web stuff. Personally,
I can tell you that this is not that much better than plain css. It's great to
have variables and what not, but the I think the biggest change is that you'll
notice that you do more things like:

"+standard_padding"

Instead of adding what you would in css. The stuff I do with it is not
perfect, but I was super jazzed about it at first, now, I don't really care
either way. Sometimes it helps and sometimes it hurts. It's not really
revolutionary. People who don't spend a lot of time doing front end html/css
stuff or don't really understand how to write a good stylesheet will probably
like sass more, it just shifts your thinking a little bit.

~~~
nex3
I suspect you aren't using it to its full potential. It's not enough just to
take bits of CSS that are exactly the same and put them into mixins. When you
start seeing patterns, places where you're using the same idea with slight
variations, then you can make a mixin with arguments that you can use for that
idea whenever you need it again. That's when Sass really starts to shine.

~~~
brettnak
We have those all over the place. I suspect that you are right that we could
be doing a better job of things though. It just seems to be another layer of
abstraction which doesn't abstract enough for it to be worth it. Personal
preference I suppose. I really do like being able to have 'functions' and
variables though.

------
zck
I liked this article, but at the end, it seems like the author conflates
dynamic and interpreted languages:

> Interpreted languages like Ruby, Python, Perl, and yes, even PHP, are now
> replacing compiled languages...Yes I am aware Ruby, Python, Perl, and PHP
> can now be compiled, but they will always retain their dynamic heritage.

As far as I know, it's only historical accident and ease of programming that
has made them correlate.

~~~
jordanb
You have to include a lot more in a binary to make a dynamic language
compilable to machine language.

So there's some natural fit to running a dynamic language on a virtual
machine.

That said, you're completely correct that you can compile dynamic languages to
machine language, and that static languages (hello Java) run great on virtual
machines.

His "history" of languages is pretty warped too. The original IBM Fortran
compiler could produce code as efficient as assembler. That was a design
requirement. The issue in the early days was that -- for those who were
capable -- writing machine language was quicker than having to go through the
additional step (on batch processing machines) of getting the code compiled.

Furthermore, the original FORTRAN compiler was designed to turn algebra-like
expressions into 704 machine code. What really made HLLs take off was the idea
that you could abstract away the particulars of the machine. This decoupled
programs written in HLLs from particular machines, it also made the
abstraction layer much thicker than existed in FORTRAN I.

For a long time, there was performance gap between code written with
contemporary HLLs and hand-tuned machine code. If you had a particularly tight
loop of a program, it might make sense to write it in assembly for at least
some of the supported platforms, to avoid the gap. Actually that gap still
exists in some situations, but compilers have gotten better and Moore's Law
has reduced the effect.

He seems to think that there was some fundamental cultural shift at work --
when in fact it was a matter of a slow evolution of compiler and machine
technology which eventually changed the engineering calculation such that
hand-writing assembler code has become a very rare activity.

~~~
mahmud
How would you classify Forth in terms of typing, and runtime binary size? :-)

The only reason dynamic languages need to do more to run on stock hardware is
that mainstream processor design has been about optimizing for Fortran
evaluation.

Algolish languages generate small binaries because their necessary runtimes
are already pre-wired into the x86 :-)

------
jerf
This is a localized instantiation of a much larger debate about code vs. data.
Yes, the same debate that Lisp people go on about. On the one hand you have
people who think that data should be dead, and on the other you have people
who think that code should be freely intermixed with the data, which has the
advantage of simplifying some things and the penalty of letting you go quite
deep down the rabbit hole if you're not disciplined about it.

The only special thing about CSS is that usually the people insisting that it
should be dead data don't mind if you generate the dead data with code, but
somehow CSS fundamentalism has taken hold and the claim is that you should
never write anything but literal CSS. Once you see it in context you can tell
this makes no sense. If you're going to make CSS a dead data language, then
you are practically begging people to generate it with other technologies,
because it's the only way to solve problems.

Frankly, I've about had it up to here with CSS fundamentalism. We're up to a
decade of CSS people lecturing about how you should do this and not do that
and sometimes do the other thing while all the while the "official" stuff
barely works. Arguing against generating CSS is like arguing against
generating HTML. If it works for you, do it.

------
walkon
While I understand the analogy, it is a bit extreme. The gap between C and
assembly quite wide, while the work Sass is doing looks relatively trivial.

~~~
chriseppstein
Trivial, from a technology perspective. Sass is not breaking any technical
ground, that is true.

But Sass challenges the way stylesheet authors approach building and
maintaining their code. And so from a work-flow perspective, Sass is
incredibly disruptive.

~~~
krakensden
I'm disappointed you didn't use 'paradigm', I almost had bingo.

------
glyphobet
The CleverCSS Python module has a very similar set of features:
<http://sandbox.pocoo.org/clevercss/>

~~~
nex3
CleverCSS has a significantly smaller feature set than Sass. It doesn't
support mixins, dynamic selectors, and a host of other Sass features.

------
steamer25
Sounds like it should be integrated into the browsers although I won't hold my
breath.

------
55
sass is full of crap!!! I opened the link <http://sass-lang.com/> in IE6,
after reading the front page comment "decreased IE headaches.", the simple
front page is not rendering properly, download button is coming down... and
lots of mis placing of the box... I tot to give it a try, if it solves my
struggle with IE.... I felt it may be same like what jQuery for javascript ...
but no luck!!

~~~
nex3
The Sass site has made the conscious decision not to support IE6, seeing as it
only comprises about three fifths of a percent of its visitors.

