Jeff Croft

I’m a product designer in Seattle, WA. I recently worked at Simply Measured, and previously co-founded Lendle.

Some of my past clients include Facebook, Microsoft, Yahoo, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

I’m currently accepting contract work and considering full-time opportunities.

Blog entry // 01.31.2012 // 4:55 PM // 37 Comments

On CSS preprocessors

Over the past couple of years, I’ve become a huge fan of Sass. It’s really the only way I write CSS now, and frankly, if anyone tried to make me write plain ol’ CSS I’d probably knee them straight in the taint.

But CSS preprocessors like Sass and LESS aren’t for everyone. At least not yet. There’s still a lot of resistance to them from the community. In fact, I resisted them for a long time, myself (here’s an old post from Nathan Borror’s blog where I outwardly hated on Sass). When you’re very comfortable with something, like many of us are with CSS, it’s hard to switch to doing it a different way.

Folks who are used to writing a lot of CSS seem discomforted by the idea of writing in one language and having it output another. I used to have to exact same discomfort, so I know how they feel.

Years ago, we wrote static HTML. Now, we almost never do. Our HTML is virtually always pre-processed, be it by PHP, Python, Ruby, Perl, .NET, Java, or something else. Today, we almost never write and serve straight HTML. Instead, for example, we write PHP that outputs HTML.

Amber Weinberg, a talented front-end developer in London, wrote a piece today about her explorations into Sass and LESS, and (among many other insightful things), had this to say:

What happens if another developer needs to edit the CSS and doesn’t know or realize a preprocessor is being used? How do you sync the two?

It’s a fair point. Once you move to writing your CSS with a preprocessor, you pretty much have to move to a workflow where everyone on the team edits the pre-processed file, rather than editing the plain ol’ CSS that’s generated during processing.

But isn’t that true of HTML, too? Couldn’t you rebut Amber’s question by asking: “What happens if another developer needs to edit the HTML and doesn’t realize you’re using PHP?” The answer, of course, is just the same: that developer needs to edit the PHP code, not the HTML it outputs. But no one seems to mind that. No one calls it a knock against PHP.

It’ll take some time for folks to get comfortable with it, but my feeling is that virtually all CSS is going to be written this way in the relatively near future, just like virtually all HTML is now pre-processed through PHP, Python, Ruby, or whatever.

What do you think? What’s been your experience with CSS preprocessors?

Comments

  1. 001 // Nicolás Sanguinetti // 01.31.2012 // 5:28 PM

    There’s a trick there, though: Usually you don’t keep both the PHP files and the generated HTML files, you only have one, and the server handles generating and serving the other. So people would not confuse them.

    That said, depending on what technology is used, you might have the same thing for pre-processed front end files: For example, I never see a css or javascript file, I only see a bunch of SCSS and CoffeeScript files, and Rails magically compiles them into a single, compressed, neatly arranged stylesheet and javascript file on the fly while developing, and once when I deploy to our servers.

    If you use LESS and you use the browser JS compiler for it, then it’s the same: you only see LESS.

    Etc, etc :)

    BTW, I agree with you, just wanted to get that point across and clarify it’s the same before anyone else says that :)

  2. 002 // Jeff Croft // 01.31.2012 // 5:34 PM

    There’s a trick there, though: Usually you don’t keep both the php files and the generated html files, you only have one, and the server handles generating and serving the other.

    That’s exactly how I use SASS, too.

    For example, I never see a css or javascript file, I only see a bunch of scss and CoffeeScript files, and Rails magically compiles them into a single, compressed, neatly arranged stylesheet and javascript file on the fly while developing, and once when I deploy to our servers.

    Right. I have basically that same setup, but with Django (django-compressor handles this beautifully).

    If you use less and you use the browser js compiler for it, then it’s the same: you only see less

    True, except I think that’s a pretty terrible idea for performance. I really wish that JS version didn’t exist. I think it tempts people into shooting themselves in the foot.

    btw, I agree with you, just wanted to get that point across and clarify it’s the same before anyone else says that :)

    Thank you, sir!

  3. 003 // Matt Menzer // 01.31.2012 // 5:37 PM

    A lot of the web work we do is use our experience with mobile-specific issues to build static HTML + CSS that we deliver to clients with dedicated integration teams that are familiar with services and backend infrastructure. While we use some light templating for efficiency in our development, we actually deliver static code to be chopped up again, and we know that at some point in the process, probably while they’re integrating what we just delivered and we’re working ahead on the next sprint, we and the client integration teams will have to adjust the code we’ve delivered, both the HTML and CSS, as new QA issues inevitably arise.

    The challenge of teaching integration teams how to use preprocessors or other tools that we are comfortable becomes extra overhead we avoid. Until they become reliable industry standards, for us, the real benefits of CSS preprocessors still don’t outweigh the potential complications.

    A lesser reason we don’t use them is the potential for CSS bloat if they’re misused by anyone on either team, and the real performance impacts that bloat can have on large mobile sites.

  4. 004 // Hugh Guiney // 01.31.2012 // 5:40 PM

    I’m still not sold on either one; reason being that this kind of stuff is coming soon to the actual CSS spec. And when it does, at the very least you’re going to have to re-learn the syntax, and at the most, throw out the workflow you built around the technology you chose. I also highly doubt that anyone will, once this gains widespread support, want to continue using LESS or Sass, just as no one today wants to continue using divs for rounded corners (at least, I would hope not).

  5. 005 // Jeff Croft // 01.31.2012 // 5:43 PM

    The challenge of teaching integration teams how to use preprocessors or other tools that we are comfortable becomes extra overhead we avoid. Until they become reliable industry standards, for us, the real benefits of css preprocessors still don’t outweigh the potential complications.

    That’s totally fair. That’s why I say they’re not for everyone yet. You really do have to get the entire team on board if you’re going to use one, and in your case, “entire team” includes people who aren’t even part of your organization. So yeah, probably not practical for you at this point.

    A lesser reason we don’t use them is the potential for css bloat if they’re misused by anyone on either team, and the real performance impacts that bloat can have on large mobile sites.

    Just like any tool: with great power comes great responsibility. You can definitely shoot yourself in the foot with CSS preprocessors — but that’s true of almost anything.

  6. 006 // Justin Sinclair // 01.31.2012 // 5:47 PM

    @Hugh, isn’t this the way of web development - use the best available solution until a better one comes? To ignore CSS preprocessors for now means you’re missing out on the current “best available solution”.

  7. 007 // Jeff Croft // 01.31.2012 // 5:47 PM

    I’m still not sold on either one; reason being that this kind of stuff is coming soon to the actual css spec.

    Coming soon? To the CSS spec? How do you define soon? That stuff is by no means settled on by the W3, and while I believe it will come to WebKit in the relatively near future (late this year, I’d guess), even at that point it will only be useful to you if you’re only targeting WebKit (which a lot of folks are).

    I’d love to see this stuff come to CSS proper and be implemented by all browsers (and have good backwards compatibility), but the chances of that happening in my lifetime are slim to none.

  8. 008 // Patrick Minton // 01.31.2012 // 5:48 PM

    The challenge of teaching integration teams how to use preprocessors or other tools that we are comfortable becomes extra overhead we avoid. Until they become reliable industry standards, for us, the real benefits of css preprocessors still don’t outweigh the potential complications.”

    I would argue that sass, scss, and less are a) acceptable standards already (rails now defaults to sass/scss) and b) not particularly difficult to learn if you have a good grasp on what’s actually being abstracted.

    Besides, the performance wins of having one developer cut down his time by 10-20% are HUGE. Why not worry about the hyuthetical cost of teaching a second dev the language later?

  9. 009 // Gercek // 01.31.2012 // 5:53 PM

    I love SASS but it’s so hard to teach pure designers how to write SASS. They don’t usually have tools to render SASS. In addition, they should be able to run a server locally (or at least need to know how to ssh to a server, sync files to git etc) in order to work with the code base. Long story short, there’s definitely a big learning curve for designers in order to step into SASS world.

    Btw, @t mentioned last week that variables are coming to CSS pretty soon. I’m not sure when we’re going to get nesting, mixins or inheritance but I doubt that it will take too long. The world would be a better place when we get all of these part of CSS core .

  10. 010 // Andrew Woods // 01.31.2012 // 5:59 PM

    I agree. CSS preprocessors will become the norm. When I first looked at LESS and SASS, I asked the same question “What if someone doesn’t know …” but soon realized it’s not a big deal. That will get resolved quickly. The next time someone on their team updates the sass or less source file and blows away their changes, they’ll get reminded they edited the wrong file. They’ll quickly adapt to the new workflow.

    I like the analogy of needing to edit the PHP instead of the HTML. It clearly demonstrates the mindset. The good thing about LESS and SASS though, is the syntax is a superset of CSS. It’s not as jarring as the switch from HTML to PHP. This will go a long way to helping adoption

  11. 011 // Jeff Croft // 01.31.2012 // 6:01 PM

    Btw, @t mentioned last week that variables are coming to css pretty soon. I’m not sure when we’re going to get nesting, mixins or inheritance but I doubt that it will take too long. The world would be a better place when we get all of these part of css core .

    I’ll say it again: I agree it’d be great if these features were backed into CSS. But even if they’re baked into CSS tomorrow, it’s going to be years, if not decades, before it’s practical to use them, for backwards compatibility reasons. Current browsers won’t support them, and when they’re updated to, it’ll take forever to get users to update to those newer versions.

    I’m not going to wait around for that, myself.

  12. 012 // Greg // 01.31.2012 // 6:03 PM

    I’m loving LESS it for the project I’m working on right now. I use less.app to compile all my source into a single minified CSS file that is loaded in production. I don’t like the idea of compiling on the fly with js.

    If you design in the browser, then the color transformations are awesome. Variables and mixins make the code very readable.

    IMO the advantages completely justify making LESS or SASS a pre-requisite for front end devs in your team. They will thank you for it once they experience the advantages. Of course, there are some environments (enterprise?) where Amber’s point is valid.

    Plus, we wouldn’t have had much progress in programming languages if everyone had thought “why not just type in the correct number in the first place?” :-)

    I doubt I will go back to raw CSS.

    Jeff, I’m interested in your thoughts on LESS versus SASS.

  13. 013 // Jeff Croft // 01.31.2012 // 6:04 PM

    The good thing about less and sass though, is the syntax is a superset of css. It’s not as jarring as the switch from html to php. This will go a long way to helping adoption.

    Great point, Andrew. This really makes it easy to switch to Sass or LESS. You can take your existing CSS, change the filename, and you’re basically off and running. Then you can slowly start using the preprocessor’s advanced features as you see fit. Maybe just start with a color or font-family variable. Simple way to get started.

    (Even if I personally prefer Sass’s original, whitespace-sensitive syntax to the SCSS syntax, which is a superset of CSS.)

  14. 014 // Jeff Croft // 01.31.2012 // 6:12 PM

    I don’t like the idea of compiling on the fly with js.

    Totally agree. That’s a terrible idea. But I like compiling on the server-side, on the first request, and then caching the result. That’s how I handle it, myself. Another good option is to make the compilation step part of the deployment process.

    Jeff, I’m interested in your thoughts on less versus sass

    I don’t have a really strong opinion either way. I use Sass, but that’s mostly for two reasons, and I’m not sure they’re relevant to anyone else:

    1. I started using Sass before LESS was as robust as it is today. At that time, Sass clearly had more features. I got into Sass back then and LESS has never given me any reason to consider switching. That’s not true anymore. Now they’re basically equals, so this is irrelevant at this point.
    2. I really, really like the original Sass syntax, which is whitespace-sensitive. I like it because I write Python, which is also whitespace-sensitive, all the time, and I’ve grown to really appreciate that in a language. But most folks getting into Sass or LESS are probably going to use the CSS-superset syntax (which Sass calls SCSS and which is the only syntax Less offers), so that makes this mostly irrelevant, too.

    The only real beef I have against LESS is that it ships with a Javascript implementation. That just feels like such a horrible idea that I think it’s actually irresponsible to include it. They do state that it’s not for production use, but I think it’s really tempts folks into doing something incredibly stupid. But that’s a very small nitpick, really. LESS seems great, too, overall.

    At this point, I don’t see a strong reason to choose one over the other.

    Update: Chris Eppstein points out to me that Sass does have a couple of significant feature advantages over LESS. The most notable is probably its extend directive, which really helps with the potential for code bloat CSS preprocessors introduce. I didn’t realize LESS doesn’t have this. Additionally, Sass has more robust conditionals and control structures. Here’s a nice comparison of the two languages: Sass/Less Comparison

  15. 015 // Hugh Guiney // 01.31.2012 // 6:26 PM

    @Hugh, isn’t this the way of web development - use the best available solution until a better one comes? To ignore css preprocessors for now means you’re missing out on the current “best available solution”.

    Yeah, but what is actually ”best” here? I have to choose between at least 3 different competing technologies, and they’re all stopgaps that don’t have much community consensus. It is a bit like jQuery vs. MooTools vs. the myriad other JavaScript frameworks that popped up around the same time. All saved time, all good in their own ways, but in the end it was jQuery that became the de facto library. The people who were all about MooTools (and I’m sure some still are) had to re-learn the tool if they wanted any hope of interoperability and relevance in their work. You may say that the people who stuck with plain JavaScript while this battle was being waged were fuddy-duddies missing out on a better solution, but for them adopting the lingua franca was less costly than those who went with something else. Even if they never switched, they’d still have faired pretty well, as JavaScript got new methods etc. which made it easier to write on its own.

    And yes, @Jeff, the W3C is infamously slow, but standardization isn’t easy and the problems are being worked on. My suggestion isn’t “Wait for the W3C version every time before using a new methodology”—and in fact, it’s specifically because of stopgap tools like Modernizr that proved author need that we’re getting stuff like the @supports API in legit CSS—but rather, don’t be in such a rush to marry that fancy new tech you met at the bar the other night. Give it some time, see where things go.

  16. 016 // Jeff Croft // 01.31.2012 // 6:30 PM

    …rather, don’t be in such a rush to marry that fancy new tech you met at the bar the other night. Give it some time, see where things go.

    I’ve been using Sass for a couple years. I don’t think I rushed into it. I also don’t think I’m married to it. If something better comes along, I’ll switch. It’d be trivial for me to switch to a different syntax to the same features, just as it was trivial for anyone with a core understanding of Javascript to switch from MooTools to jQuery. It’s just learning a few new APIs or a new syntax. No big deal.

    But your point is well-taken.

  17. 017 // Hugh Guiney // 01.31.2012 // 6:33 PM

    Current browsers won’t support them, and when they’re updated to, it’ll take forever to get users to update to those newer versions.

    That may have been the case in years past, but in the immediate future this problem will go away completely. Chrome auto-updates, Firefox already auto-update, and even Microsoft has announced that they plan to do it for IE. Opera has an option for it but with all the others doing it opt-out it’ll only be a matter of time before they do too. There will obviously still be barriers to adoption, but the bottleneck won’t be IT departments and grannies anymore.

  18. 018 // J Wynia // 01.31.2012 // 7:24 PM

    It’s funny. When Less and SASS, etc. showed up, I was more surprised by how many developers were still writing static CSS. 10 years ago, I was generating CSS just like I generate HTML, using whatever server-side language I was working in. I’ve done so in PHP, Perl, ASP.NET, etc.

    In every case, I have had variables, loops, etc. for that whole time because I had my server-side toolkit available. With headers set properly for caching, etc. it has worked great.

    These new tools are purpose-built for CSS, but this shouldn’t have been as revolutionary as people have been acting.

  19. 019 // Jeff Croft // 01.31.2012 // 7:35 PM

    It’s funny. When Less and sass, etc. showed up, I was more surprised by how many developers were still writing static css. 10 years ago, I was generating css just like I generate html, using whatever server-side language I was working in. I’ve done so in php, Perl, asp.net

    Yeah, good point. I experimented with that back in the day, too.

  20. 020 // Thibaut // 02.01.2012 // 2:05 AM

    Great discussion here!

    LESS gave me a real hard time on a recent project: I had to dig in a LESS file with 4-5 levels of nesting, 20+ color variables and mixins more than you need. This is what happens when a curious and willing developper with little background in css gets excited! While he was truly trying his best, I found myself cursing a lot, while trying to make sense of it all.

    What really annoyed me was the debug process got broken. I’m used to this sequence: inspect an element, read the css proprieties linked to it, get the line number of the propriety I need to edit, alt-tab to my css file, jump to the line number and do my work. LESS makes it impossible as it unlinks line numbers, and I lost a fair amount of time searching the LESS code tree for the proprieties I needed to fix. The 5 levels of nested rules combined with 2 spaces indents might not have helped for readability, but it seems to me I’d spend more time fixing code even with a clean less style sheet. Maybe I should change the way I debug?

    The other thing that really got me overheating was the use of variables: getting on a LESS file I didn’t know, it was complicated to be sure that changing this variable would only affect the instances I identified. I used project search so I could have a list of the variable instances, but it was still hard to get my head around the file. Do you have any advices about this?

    From this experience, I understood that LESS could be used as a way to better organize css code (nesting), save you time from typing 4 prefixes css3 proprieties (mixins) or obscure color hex codes (variables). The parallel you make with the relation between HTML and CSS makes a lot of sense, but I have a slightly different point of view to offer : PHP is to HTML what a lego brick injection mold is to a lego brick. Using PHP allows you to produce as many HTML bricks you need for as many HTML pages require them, allowing the pages served to be contextualized for each client if you want to. A server is like a factory churning out thousands (millions!) personalized lego models, using PHP molds to produce the required HTLM bricks for each model. What LESS to CSS does is different : there is only one CSS file existing at the end. Using an industrial tool to produce a single piece feels strange. I don’t see - for now - why CSS editing would need industrial processes.

    In the end, it seems to me the features offered by LESS should belong to a CSS editor : CSSEdit already does it offering you a list view of your proprieties and folders to organize them. I’ve worked on Magento projects where the master file was 5000+ lines, and these folders saved me a lot of time. Managing variables and mixins could very well be features for a next version of Espresso. Color variables could be represented as a “palette”, and mixins invoked with a tooltip.

    This subject is really interesting in any case, thank you for starting this discussion.

  21. 021 // Newotn // 02.01.2012 // 6:39 AM

    I must say that, while I understand your points Jeff, as they are completely valid, I disagree. First and most importantly, the entire idea behind the HTML/CSS/Javascript stack is its portability. It requires no setup and anyone who knows the language can generally pick up a file and begin to edit. I believe in writing code in the same design as the languages, portable. In a large team environment, I’ve been really working towards writing code for others so they can easily understand what I’m writing and edit accordingly, thus preventing any introduced bugs or inherent code bloat due to lack of understanding. You made the point that its not for everyone; I make the point that it’s only place is in personal projects that will never have to be handed off to another developer. Even in jobs where one developer may be the only one touching the code, you still should be thinking about what happens to your code when you have to hand it off to the next developer. Are they going to understand what your doing with the preprocessors? If we really are trying to build a community for web developers, shouldn’t we be following the standards set forth for us as well as build projects that can easily be handed off to one another? The problem with these preprocessors, in my opinion, is that requires one to learn a complex language that sits on top of another language that was already easy to write.

  22. 022 // Jeff Croft // 02.01.2012 // 10:54 AM

    Hi Newotn: Does your team use a backend development environment, such a PHP, Python, Ruby, Java, .NET, etc.? Or do you write static, flat HTML files with no logic and no database?

    I ask because you say:

    The problem with these preprocessors, in my opinion, is that requires one to learn a complex language that sits on top of another language that was already easy to write.

    If you do have some kind of backend development environment beyond static HTML, don’t you think this applies to that, too? Why is advanced logic okay on the backend but not okay on the frontend?

  23. 023 // Newton // 02.06.2012 // 5:36 PM

    You make a good point. We do use PHP with MySQL/MongoDB as a database. But I guess my counter point is that CSS was never devised to act as a complex logic-based language, where as PHP, Ruby, Python, etc, were designed with that in mind initially. With what you’re suggesting, would you expect CSS to start adding in more parts of the logic/business layer?

    And what are you’re thoughts on my comment regarding portability with preprocessors?

    You made the point that its not for everyone; I make the point that it’s only place is in personal projects that will never have to be handed off to another developer. Even in jobs where one developer may be the only one touching the code, you still should be thinking about what happens to your code when you have to hand it off to the next developer. Are they going to understand what your doing with the preprocessors? If we really are trying to build a community for web developers, shouldn’t we be following the standards set forth for us as well as build projects that can easily be handed off to one another?

  24. 024 // Jeff Croft // 02.06.2012 // 8:18 PM

    But I guess my counter point is that css was never devised to act as a complex logic-based language, where as php, Ruby, Python, etc, were designed with that in mind initially.

    Right, but HTML wasn’t. We use PHP, Ruby, Python, etc. to pre-process HTML, use like we use Sass, Less, etc. to pre-process CSS. In both cases, we’re wrapping programming logic around a language that wasn’t designed with it in mind.

    And what are you’re thoughts on my comment regarding portability with preprocessors?

    Again, I think it’s exactly like PHP, Ruby, Python, etc. You said you built your sites with PHP. Well, that means you have to hire developers who understand PHP. It also means you have to run your sites on servers that have PHP installed. Same here. If you choose to use Sass in your workflow, then your developers need to understand it, and your servers need to have the compiler installed. Exactly the same thing. No big deal.

  25. 025 // Luca Lenardi // 02.07.2012 // 4:56 AM

    Hello Jeff.

    I’m quite unexperienced with those technologies, but I’m missing the point here.

    I think that the meaning of a CSS pre-processor is simply a matter of abstraction, as it is for a lot of different situations in software development. I’m still writing plain CSS (mostly for laziness), but I’m sure that using some kind of abstraction to simplify and make a stylesheet much more clean, dry and (probably) readable is definitely a good idea.

    To put it simply and to exceed it a bit: there are some cases where writing assembly code could be meaningful, but would you write a website with it?

    Regarding the team and workflow issue, It’s absolutely the same as for any other programming language or framework. If you choose a technology, you should probably hire developers experienced in that technology or invest the time necessary to make them acquire those skills.

  26. 026 // Jeff Croft // 02.09.2012 // 10:21 AM

    Luca, it sounds to me like you’re not missing the point at all. I totally agree: abstraction (while it can be overdone) is generally a good idea, and these tools generally do it well. Sounds like we agree 100%. :)

  27. 027 // Newton // 02.13.2012 // 7:12 AM

    Right, but html wasn’t. We use php, Ruby, Python, etc. to pre-process html, use like we use Sass, Less, etc. to pre-process css. In both cases, we’re wrapping programming logic around a language that wasn’t designed with it in mind.

    You keep saying that PHP, Ruby, & Python pre-process the HTML. So please explain to me how you’re working that these are pre-processing your HTML. Am I to understand correctly, that you have a .php file that contains all classes, methods, functions to spit out your html into a generated .html file? In my development environment, I do use the server side languages to help dynamically populate my data. The only thing I would consider being pre-processed is if I need my css classes to be dynamically inserted based on the data, but that’s rare.

    The exception here Jeff, is that I’m not using those languages to spit out my HTML. My php files include the logic for spitting out content and data. I’m not maintaining a PHP file and a generated PHP.HTML file. I have a php file that is interlaced with obviously marked-up HTML. The only part that spits out my HTML would be if classes are needed dynamically.

  28. 028 // Jeff Croft // 02.20.2012 // 11:40 AM

    It’s very simple, Newton. I think you’re trying to overcomplicate it. When someone makes a request to your site/app/page, they aren’t requesting a static HTML file. Instead, they’re requesting a PHP file. PHP, as I’m sure you know, stands for “Hypertext Preprocessor.” That’s because, before regular HTML is served to the browser, PHP code is executed. The result is plain HTML, but there’s a pre-processing step involved where logical code is executed.

    This is exactly how Sass and similar work. The result is plain CSS, but there’s a pre-processing step involved where logical code is executed.

  29. 029 // Amber Weinberg // 02.23.2012 // 2:46 AM

    I think your comparison of preprocessors and CSS to PHP and HTML is fundamentally flawed in several ways:

    1) Using PHP doesn’t require the use of a separate app or command line. 2) There’s no compiling with PHP/HTML 3) Especially for the “what if someone else edits the file” argument: you can easily see when someone’s used PHP, as it stays right there in the file, preprocessors don’t actually stay in the CSS file, so it’s possible another developer could edit the CSS file not knowing of this, and then get their changes overwritten. As I work exclusively with design agencies and other freelancers, this would certainly happen daily to me. 4) PHP is a completely separate scripting language from HTML. It doesn’t change the way HTML works or looks, it interactives with it. Conversely, preprocessors can’t stand on their own and fundamentally change the way CSS was meant to work and act.

    I honestly took a good look at preprocessors and just saw so much wrong with them (of course this is my personal opinion). Too much code bloat (i.e. it uses -webkit- rules that could’ve been dropped ages ago), it requires more steps from coding to deployment and there are too many potential issues when working with other developers.

  30. 030 // Simon White // 02.23.2012 // 3:06 AM

    You could write CSS in PHP, using loops and variable substitution to make sure a colour code is defined in one place and reused where necessary. The same is true of many other cases where a preprocessor makes sense. You can even configure Apache/Nginx to call PHP to process .php.css files through the PHP libs.

    Preprocessors are part of a niche of tools that are useful for certain types of people. Usually those with a specific dev workflow in mind, possibly needing to build stuff to deploy to production, possibly using CSV/SVN/git, and wanting to maintain a single file which centralises definitions of colours, margins and stuff.

    PHP is a preprocessor too, but it’s interpreted. You could, no doubt, cause SASS or LESS CSS to be interpreted / or at least compiled and cached at runtime (taking a performance hit)…

    I certainly hope that SASS/LESS output CSS files have comments at the top explaining that they are automatically generated.

  31. 031 // Graeme Blackwood // 02.23.2012 // 3:11 AM

    I do have similar concerns to Amber – and have worked on SASS files that are absolutely enormous compared to what could be done with a well-written CSS file. The arguments about maintainability start to break down when you have that much code to wade through, variables and mix-ins or not!

    A deep understanding of CSS and an Object Oriented CSS approach should be in place before moving to preprocessors. Also I’d say it is wise to think holistically about ongoing maintenance / skill sets when using SASS, as Amber rightly points out.

  32. 032 // Simon White // 02.23.2012 // 5:38 AM

    Having looked into it a bit more, SASS rather looks like it’s solving a problem I don’t have…

  33. 033 // Jeff Croft // 02.23.2012 // 8:23 AM

    Hey Amber-

    A few responses:

    1. Sure it does. PHP is a compiler just like Sass/Less is. PHP runs on the command line, or as part of a webserver configuration, just like Sass/Less does. Exactly the same thing.

    2. PHP is compiled on the fly, as a page is requested. This is exactly how I set up Sass, too.

    3. I save on my server files that end in .sass. They’re easily identifiable from standard CSS files. I do not save in my repository standard CSS files. CSS files are only generated on the fly, as the page is requested, exactly like PHP (they are then cached, which can be done with PHP, as well).

    4. Sass was based on a completely separate scripting language from CSS, too. It’s Haml, which has many applications, not just Sass/CSS preprocessing.

    Totally cool if CSS preprocessors are not for you, Amber, but they are a big topic in front-end web development right now, and I think it’s important to at least understand them accurately!

  34. 034 // Jeff Croft // 02.23.2012 // 8:27 AM

    I do have similar concerns to Amber – and have worked on sass files that are absolutely enormous compared to what could be done with a well-written css file.

    This is a fair concern, because if you write Sass like you write CSS, you will end up creating bloated CSS. If you learn Sass properly, and take advantage of features such as the @extend directive, you can actually make much smaller CSS files than are typically written by front-end developers.

    In other words: this isn’t a fault of the tool, it’s a fault of lousy development using it. You can write bad HTML, PHP, Python, and Ruby code, too — that doesn’t make the languages bad.

  35. 035 // Amber Weinberg // 02.23.2012 // 8:27 AM

    Do you upload the SASS/LESS files along with the rest of the web files? Again, my major sticking point is when another dev comes along and needs to edit the CSS - or ends up editing the actual CSS and gets their changes overwritten.

    From what I understand (and I could be wrong). You can two files the preprocessor and the CSS file and only the CSS file gets uploaded - resulting in potential confusion and overwriting of CSS. This doesn’t happen in PHP :P

  36. 036 // Jeff Croft // 02.23.2012 // 8:28 AM

    Having looked into it a bit more, sass rather looks like it’s solving a problem I don’t have…

    That was exactly my reaction to Sass for a few years, too. But eventually, I saw the utility in it. If you don’t right now, no big deal. You know the tool exist should you ever feel a need for it. Until then, happily write CSS the old-fashioned way. Nothing wrong with that at all!

  37. 037 // Jeff Croft // 02.23.2012 // 8:37 AM

    Do you upload the sass/less files along with the rest of the web files?

    Yes, absolutely. Another dev would never see regular CSS files, as they are not stored in the project folder. They are created on the fly and stored in a temporary CACHE directory (the CSS for this site is here: http://jeffcroft.com/static/CACH). Another dev would only the see the .sass file in both the version control repository and on the server, were they to SSH/FTP in.

    You can two files the preprocessor and the css file and only the css file gets uploaded - resulting in potential confusion and overwriting of css.

    Yes, you can break your Sass code up into multiple files. I do this (like type.sass, layout.sass, etc.). Makes for no single file that is particularly long and confusing, and keeps each file dedicated to a specific purpose. I like this, but it’s obviously optional. If you do it, Sass then concatenates them into a single file (to reduce HTTP requests to your server). Again, with my setup, a developer never sees the resulting CSS file, only the .sass files that create it, so there is no confusion about which files to edit.