Why Sass And Languages Like It Will Triumph
wiseheartdesign.com
wiseheartdesign.com
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).
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."
They may look similar, but you quickly realise they're not if you actually give them a decent try out.
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.
"Demise" here is probably too strong -- a better word might be "waning".
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).
This should not puzzle you, nor the people behind Sass. If designers liked programming they would be programmers.
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?
CSS is not a programming language.
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.
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.
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.
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.
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?
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.
Because they enjoy it, or because they want to advance in their career?
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.
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.)
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.
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.
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.
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.
http://www.smashingmagazine.com/category/coding/
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:
http://www.smashingmagazine.com/2009/09/10/css-wishlist-new-...
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.
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.
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?
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.
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.
See documentation for more detail: http://wiki.github.com/chriseppstein/compass/command-line-to...
http://github.com/creationix/coffeepot
Here's a link to Tim's alpha, which is able to parse a limited subset of CoffeeScript (we need to figure out what to do with left-recursive rules):
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.
It's seamless and works great.
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'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.
It does trivial macro expansion and arithmetic. No control or data structures.
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:
"+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.
> 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.
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.
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 :-)
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.
But Sass challenges the way stylesheet authors approach building and maintaining their code. And so from a work-flow perspective, Sass is incredibly disruptive.