9 ms·

Why Sass And Languages Like It Will Triumph

100 points by jlong 17y ago

zck 17y ago
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 17y ago
  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 17y ago
    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 :-)
houseabsolute 17y ago
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 17y ago
  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 17y ago
    "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 17y ago
      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?
jeff18 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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/ 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."
mmastrac 17y ago
This reminds me vaguely of what Coffeescript does for Javascript (http://jashkenas.github.com/coffee-script/ 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 17y ago
  Or even better, a server-side module or component that Apache sends all .sass files to, and it outputs css.
  - jlong 17y ago
    For development I like to use Serve: http://github.com/jlong/serve http://github.com/jlong/serve
  - jamesbritt 17y ago
    Sounds like a job for Rack, too.
- endergen 17y ago
  I believe that if you use Compass, it has a command line utility that watches for changes and then compiles the appropriate files automatically when changes occur. This makes your workflow similar to working with css where you have refresh to see your changes. See documentation for more detail: http://wiki.github.com/chriseppstein/compass/command-line-tool http://wiki.github.com/chriseppstein/compass/command-line-to...
  - wfarr 17y ago
    Future versions of sass will support this without 'having' to use Compass.
- toothcomb 17y ago
manbearpig 17y ago
This actually seems really helpful. I can see variables saving me a lot of time. I hate going back to a sheet I haven't used in a while and not knowing what any of the colors are. But I think it's silly to say that a tool to help you write better CSS will lead to the demise of CSS.
halo 17y ago
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 17y ago
  I agree, CSS preprocessor is a more fitting term. It does trivial macro expansion and arithmetic. No control or data structures.
  - chriseppstein 17y ago
    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 http://gist.github.com/280756
  - jlong 17y ago
    I prefer to call it a designer's programming language. BTW, Sass does have simple control statements (if and while). I didn't cover all of the things that Sass can do. To get that see: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html
walkon 17y ago
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.
- jlong 17y ago
  Possibly. Perhaps it correlates better with the gap between C and C++.
  - walkon 17y ago
    Ah, that seems like a more reasonable analogy.
- chriseppstein 17y ago
  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 17y ago
    I'm disappointed you didn't use 'paradigm', I almost had bingo.
- imd 17y ago
  I agree; Sass looks more like a macro language. That's not a bad thing; I've wanted variables and calculated values before. Now I know I can have them.
55 17y ago
sass is full of crap!!! I opened the link http://sass-lang.com/ 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!!
- chriseppstein 17y ago
  The design and bug-free nature of a website is your job, just like it is in CSS. Sass can help you accomplish a more bug free design by giving you better tools for managing, organizing, and reusing your styles.
- nex3 17y ago
  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.
brettnak 17y ago
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 17y ago
  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 17y ago
    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.
voidpointer 17y ago
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.
- jlong 17y ago
  This is exactly my point.
- BrandonM 17y ago
  Heh. Someone didn't finish reading the article (including at least 5 others who thought this comment was insightful).
glyphobet 17y ago
The CleverCSS Python module has a very similar set of features: http://sandbox.pocoo.org/clevercss/ http://sandbox.pocoo.org/clevercss/
- nex3 17y ago
  CleverCSS has a significantly smaller feature set than Sass. It doesn't support mixins, dynamic selectors, and a host of other Sass features.
gnaritas 17y ago
I prefer LESS http://lesscss.org/ 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 17y ago
  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 http://github.com/nex3/haml/commits/scss
Pistos2 17y ago
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.
- oscardelben 17y ago
  Maybe I've misunderstood your post, but what's preventing you from seeing the generated code in your browser?
  - Pistos2 17y ago
    Indeed, generated code is seen in the browser. The issue is that the generated code is not the source code when you use Haml, Sass, etc.
- rufo 17y ago
  Haml is literally a one-to-one relationship with HTML tags, so there's almost zero mental overhead. If anything, the tight relationship between indentation of HAML and outputted HTML makes it far easier to debug things, and I haven't had to debug a pesky missing closing tag bug in eons. Sass is slightly more difficult, but by default in development mode it outputs comments describing which Sass rules generated the CSS you're looking at, so it's not too difficult to go back - and it's a far simpler language than whatever you're coding your app in. Honestly, I don't see it as being any different than (as you point out) translating the outputted HTML/CSS back into ERB/PHP/etc, or as difficult as trying to trace output backwards through your codepath.
- rubyrescue 17y ago
  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.
jerf 17y ago
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.
steamer25 17y ago
Sounds like it should be integrated into the browsers although I won't hold my breath.

100 points by jlong 17y ago

zck 17y ago

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 17y ago
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 17y ago
  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 :-)

houseabsolute 17y ago

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 17y ago
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 17y ago
  "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 17y ago
    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?

jeff18 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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/ 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."

mmastrac 17y ago

This reminds me vaguely of what Coffeescript does for Javascript (http://jashkenas.github.com/coffee-script/ 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 17y ago
Or even better, a server-side module or component that Apache sends all .sass files to, and it outputs css.
- jlong 17y ago
  For development I like to use Serve: http://github.com/jlong/serve http://github.com/jlong/serve
- jamesbritt 17y ago
  Sounds like a job for Rack, too.
endergen 17y ago
I believe that if you use Compass, it has a command line utility that watches for changes and then compiles the appropriate files automatically when changes occur. This makes your workflow similar to working with css where you have refresh to see your changes. See documentation for more detail: http://wiki.github.com/chriseppstein/compass/command-line-tool http://wiki.github.com/chriseppstein/compass/command-line-to...
- wfarr 17y ago
  Future versions of sass will support this without 'having' to use Compass.
toothcomb 17y ago

manbearpig 17y ago

This actually seems really helpful. I can see variables saving me a lot of time. I hate going back to a sheet I haven't used in a while and not knowing what any of the colors are. But I think it's silly to say that a tool to help you write better CSS will lead to the demise of CSS.

halo 17y ago

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 17y ago
I agree, CSS preprocessor is a more fitting term. It does trivial macro expansion and arithmetic. No control or data structures.
- chriseppstein 17y ago
  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 http://gist.github.com/280756
- jlong 17y ago
  I prefer to call it a designer's programming language. BTW, Sass does have simple control statements (if and while). I didn't cover all of the things that Sass can do. To get that see: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html

walkon 17y ago

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.

jlong 17y ago
Possibly. Perhaps it correlates better with the gap between C and C++.
- walkon 17y ago
  Ah, that seems like a more reasonable analogy.
chriseppstein 17y ago
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 17y ago
  I'm disappointed you didn't use 'paradigm', I almost had bingo.
imd 17y ago
I agree; Sass looks more like a macro language. That's not a bad thing; I've wanted variables and calculated values before. Now I know I can have them.

55 17y ago

sass is full of crap!!! I opened the link http://sass-lang.com/ 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!!

chriseppstein 17y ago
The design and bug-free nature of a website is your job, just like it is in CSS. Sass can help you accomplish a more bug free design by giving you better tools for managing, organizing, and reusing your styles.
nex3 17y ago
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.

brettnak 17y ago

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 17y ago
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 17y ago
  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.

voidpointer 17y ago

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.

jlong 17y ago
This is exactly my point.
BrandonM 17y ago
Heh. Someone didn't finish reading the article (including at least 5 others who thought this comment was insightful).

glyphobet 17y ago

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

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

gnaritas 17y ago

I prefer LESS http://lesscss.org/ 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 17y ago
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 http://github.com/nex3/haml/commits/scss

Pistos2 17y ago

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.

oscardelben 17y ago
Maybe I've misunderstood your post, but what's preventing you from seeing the generated code in your browser?
- Pistos2 17y ago
  Indeed, generated code is seen in the browser. The issue is that the generated code is not the source code when you use Haml, Sass, etc.
rufo 17y ago
Haml is literally a one-to-one relationship with HTML tags, so there's almost zero mental overhead. If anything, the tight relationship between indentation of HAML and outputted HTML makes it far easier to debug things, and I haven't had to debug a pesky missing closing tag bug in eons. Sass is slightly more difficult, but by default in development mode it outputs comments describing which Sass rules generated the CSS you're looking at, so it's not too difficult to go back - and it's a far simpler language than whatever you're coding your app in. Honestly, I don't see it as being any different than (as you point out) translating the outputted HTML/CSS back into ERB/PHP/etc, or as difficult as trying to trace output backwards through your codepath.
rubyrescue 17y ago
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.

jerf 17y ago

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.

steamer25 17y ago

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