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.
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).
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?
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.
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."
I would say, although it can be easily argued I don't the life long experience needed to make this conclusion, that Programmers tend to overestimate the impact in the long term.
Although, the first clause, which you wrote, may also be applied in a separate but true context.
Again, just my humble opinion from empirical evidence of articles/blogs/past-technologies and logical deduction.
Ah. Now that you mention it, the quote in the context of technology in general makes much more sense. Seeing as new web and programming technologies are created every day, it would be hard to fit everything into those categories, but physical technologies are much different because in order for someone like me to see them, they have gone through lots of stages of refinement and in most cases the idea doesn't get far enough for me to see it. Web apps, however, are relatively easy to make (compared to designing, creating, and then mass producing your new toothpaste dispensing toothbrush).
This quote isn't mine. I forget where I heard about it the other day, but apparently it was originally stated by Roy Amara, and is sometimes referred to as Amara's Law. Though it wasn't originally about programmers, just an inclusive "We."
Sass is DRY applied to CSS. While that is not a very revolutionary concept (we have had preprocessors for many, many years), it has a revolutionary effect on CSS. Its effect on the effort to generate CSS and especially the effort it takes to maintain CSS is revolutionary.
Yeah, Sass spells CSS's demise the same way PHP spelled HTML's. That is to say that it can never replace it, that the success of Sass is contingent on the continued success of CSS, and that the "demise" of CSS would also be the demise of Sass.
The idea is that it's the demise of CSS as the primary language used to style webpages. CSS would still be used as a compile target, but most people would write in higher-level languages like Sass or its descendants.
"Demise" here is probably too strong -- a better word might be "waning".
First off, "most people" won't be using Sass instead of writing CSS directly, any time soon.
Sass hasn't really been picked up at all in the design community (who are the primary users of CSS), it's a programmer's solution to a programmer's problem — the designers' point of view seems to be that Sass doesn't solve any of their problems, it only adds complexity.
Now, I like Sass just fine, but this isn't about me, this is about the retarded "idea" that Sass would somehow spell CSS's "demise" (and that's assuming we completely ignore that Sass produces CSS — the very thing which demise it is supposed to cause).
Sass is definitely not targeted at programmers, and it certainly doesn't just solve "a programmer's problem". As one of the users (a designer, incidentally) put it recently on the mailing list: Sass is for people who write CSS. This includes designers, programmers, and anyone in between. It has users from everywhere on this continuum who love it.
Doesn't matter who it's "targeted" for or what the intentions were — the fact of the matter is that Sass (and basically any other programming language designed to make html/css "better") is not popular in the design community. You can argue with this as much as you like, but when you are done, the cold harsh reality will still be that designers in general don't like programming.
This should not puzzle you, nor the people behind Sass. If designers liked programming they would be programmers.
<i>"If designers liked programming they would be programmers."</i><br />
Amen. Having to express a visual idea in code is about as fun as it would be to have to draw your program and have a compiler turn it into code. If web designers could just draw their beautiful designs and have that magically turn into code, they'd love it. Search the web for services that claim to do just that, and you'll see there's plenty of demand. (I have no idea if those services work.)
It's also a matter of empirical fact that the people who use Sass now are a mix of designers and developers. No, Sass isn't used by most designers. Nor is it used by most programmers. But of the people who use Sass, many of them are designers, and that proportion is growing.
Writing Sass is not programming. Most of the time it doesn't feel like programming, and the future goals for it intend to make it feel even less like programming.
I agree completely that if designers liked programming, they would be programmers. I made the same argument myself on the Compass mailing list the other day, defending a design decision made to make the language easier for designers.
Designers don't like programming? Most web designers I know want to know more about programming and jump at the opportunity to learn. Can you provide references or articles to back up your assertion?
In my opinion Web design requires a very similar skill set. Debugging CSS/HTML takes a programmer's mindset. It is not that difficult for most designers to make that jump. Many of them have picked up Javascript just fine.
Web designers? Again, to be good at web design you have to develop many of the same skills as programmers. Debugging CSS/HTML is about the same as debugging code.
Debugging a turing-complete full-fledged programming language is the same as debugging markup? Interesting.
I thought the whole point of Sass, the topic of this discussion, was to introduce more powerful programming concepts to CSS?
So which is it, is CSS already as powerful a tool as a programming language thus making Sass completely useless, or does it lack the capabilities of a real programming language, thus making it much easier for designers to use with proficiency?
However, when you are dealing with CSS related bugs in browsers a high level of determination and problem solving ability is required to get to the bottom of each bug. The same kind of determination is required to debug Ruby or Java or any other programming language.
So the jump from competent web designer to programmer is not as far as you might think. They actually require a similar skillset.
Programming is a left-brain endeavor, designing utilizes the right side of the brain. Enjoying one of these tasks does not mean you enjoy the other, and certainly not that you're any good at it.
The reality is that most designers aren't also proficient programmers. And most programmers aren't also proficient designers. This is the cold hard truth that your Sass-pushing zealotry cannot overcome.
Most designers simply aren't keen to learn to program, because the two things are drastically different things.
"Programming is a left-brain endeavor, designing utilizes the right side of the brain."
Sorry, that's a myth. Both engage both sides of the brain. Most of what we do involves both sides of the brain. There are plenty of books around busting the myth that 'some people are left brain and some people are right brained'. Programming involves much of what is associated with 'right brain thinking': leaps of intuition, random thoughts, synthesis, looking at the bigger picture. While 'designing' (by which I take you to mean 'aesthetic design'?) involves much of what is associated with 'left brain thinking': analytical, objective, rational, logic.
What many folk do not realise is that 'design' is mostly something technical that can be learned. It's a set of rules, guidelines, processes and techniques that can be taught and practised. It's not some magical, right-brain, talent you're born with, it is something that is learned, practised and honed.
Sass is, in my experience, no harder to learn than HTML or CSS. Much easier, in fact if you already know CSS. It's nowhere near as complex as, say, Javascript or PHP, which most web designers seem to be able to handle to some degree. If a web designer (as in someone who specialises in HTML, CSS, graphic design, typography, IA) finds it too hard or complex, they either need to practice more, or find another career, because they're going to be redundant pretty soon as CSS and HTML get more complex with the transition to HTML5 and CSS3.
I don't seem to be making any headway with you on this, so this will probably be my last reply on this thread. But I'm speaking as a professional web designer that has a programming background. I see a lot of correlation between the two.
If we were talking strictly design (as in art) your point would hold a little more weight with me, but we are talking about web design. The skills that are required here are not that different from the skills that are required by a programmer. One is very visual it is true, but both require strong troubleshooting skills.
I'm not sure about the whole left/right brain thing. I'm speaking from my experience of what it takes to be a good web designer.
Is programming strictly a right brain activity? I hear a lot of talk about beauty and design in programming circles today. Clearly it is not all cold crisp logic. You aspire towards beauty and function just as much as designers do.
I know precisely what you mean. I'm just like you, well, almost. I'm a programmer who started in design. But we are exceptions — we are not the norm.
The norm is that programmers like to program and designers like to design. Most programmers suck at design, and most designers hate programming.
Sass is great for the relatively few of us who actually like to do both. But we are exceptions, not the norm, which is why Sass won't spell CSS's "demise" any time soon: most people who write CSS don't like to and don't want to program.
This is exactly why you should never use your personal experience as an indicator of what the norm is. Instead you should observe the world — and in it designers design and programmers program, only rarely does one person enjoy both.
And what are you using? I have observed the world and my observations about web designers are completely different.
I have asked before for references or articles supporting your point of view and you have not posted anything. @charlesr posted some excellent links below. Where is the evidence that supports your perspective?
Most of the benefit of Sass lies in variables, mixins, and nesting. If there are any programming constructs, they're usually in the background, in library code. When there's debugging to be done, it's the same sort that's done for CSS: touching up styles and so forth. And in many ways Sass makes that sort of debugging much easier.
If some putatively "creative" person has taken the effort to learn HTML and CSS, then they're already working in an area which to them may as well be programming -- odd as that may sound to an actual programmer. (And besides, isn't a significant portion of jQuery's audience comprised of web designers? What does that tell you?)
I find it hard to believe that anyone who has worked with CSS on a regular basis would be intimidated by Sass. As the article makes quite clear, it's conceptually simple and provides obvious maintainability advantages. If anything, it subtracts rather than adds complexity.
> I find it hard to believe that anyone who has worked with CSS on a regular basis would be intimidated by Sass.
Would it be hard to believe still if person after person told you so flat out? Because this is the primary reason people say "no thanks" to Sass (and all other html/css empowering macro languages, etc).
Well, except they don't use the word "intimidated", they say that they don't need html/css to get any more complicated, it's fine as it is.
"except they don't use the word "intimidated", they say that they don't need html/css to get any more complicated, it's fine as it is."
I don't know who you've been observing, but in my experience as a web designer, with a bit over 15 years in the industry, is that web designers are constantly moaning about the limitations of HTML and CSS and hate the slow pace of change (or, to be more accurate, the slow pace of the demise of the IE browsers). They're also hungry to learn more and push the boundaries of current knowledge and practise. You only have to look at the coding section of Smashing Magazine, the most popular web design site online, to see that web designers are in no way the sort who are going to be intimidated or uninterested in Sass.
In fact, the debate regarding the evolution of CSS on, and my impression is that there is serious pressure on CSS to change and evolve, judging by the comments here:
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.
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.
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.
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.
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.
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.
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?
"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.
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.
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.
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.
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.
We're a django shop and that's essentially what we do. We already use the django template engine in our javascript/css files (primarily for URL generation, but it's grown to be several other things). We plugged in Sass and it's been great.
The development servers passes CSS files through the django template engine and Sass every time it's served. In production we do it just during deployment. Thus what sits on our CDN is the end result. From a developers pesrpective your always editing the 'source' file not the 'compiled' version.
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."
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.
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:
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
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.
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.
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.
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.
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.
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 :-)
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.
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.
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.
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!!
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.
