The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums CSS Does anyone NOT use a preprocessor?

  • This topic is empty.
Viewing 15 posts - 16 through 30 (of 30 total)
  • Author
  • #136136

    I *have* to assume he’s trolling since this is from his own blog:

    > Using the SASS mixin has definitely increased my overall workflow speed which is probably the greatest benefit.


    > Hopefully you are using SublimeText as a text editor

    [Link to post]( “”)

    Why would you make me get so angry when you believe differently, @scottnix!?


    Doc I think we got punked.


    Lol, sorry. I thought it was totally obvious I was kidding around. I got inspired from the example excuses people give at the end of the TXJS video Chris posted. :x


    @AlenAbdula Yeah man, i prefer not to use a preprocessor simply because i honestly haven’t given it the time and with my workflow, a preprocessor isn’t really needed. I figure one of these days i will give it a gander. In no way am i saying these things aren’t good for workflows, i just work with a lot of .NET and Java. I guess this weekend i will give one a try, who knows, maybe it will change the way i write css lol..

    Jozsef K.

    To tell you the truth, I prefer 2 preprocessing methods:
    1. the shortcut coding(zen coding plugin)
    2. drag-and-drop html tags/css properties/custom predefined structures/codes from left to right, that will generate code for you, this way you can have an html and css skeleton in 5 minutes


    Maybe I’m just weird, I dunno. I just prefer to be in complete control of my CSS. If I wanted to save a ton of time, I’d be using Weebly or something. Web design is an art, and I don’t feel the need for shortcuts.


    Cool dude.

    []( “”)


    Just saying: I was totally sceptical of how it would help until I used it. Within a day of using SCSS I could see how much easier it would make my life.

    Using variables for global colours then allowing you to lighten / darken the color by a % (lighten($primaryRed, 10%);) – this exports as a new hex colour, px to em conversion, setting a variable for global padding which I will use maths to adapt if I need to – (padding: $padding / 2 )

    Everything feels more in control, as opposed to out of control as someone above suggested.


    > IMO, just using preprocessing for nesting is beneficial. – @AlenAbdula

    That’s the sole reason I started using SCSS. The realization of it’s full power came later.


    The main reason why I use SASS is simply because it saves me time by using nesting when styling forms and lists. Another good reason is that because of that nesting, I feel I can group things together easier.

    However, I have not yet reached a point where I couldn’t/wouldn’t do any site without SASS. It’s helpful, but not essential to me.


    I build custom skins/themes for a CMS called [mojoPortal]( “mojoPortal”) where there are 40+ modules/features that have to be themed for each skin, the bad part is the development of most of the modules are done from a back end development point of view, so many times similar things (such as buttons) will have different classes/markup. Preprocessors have made the job MUCH easier for me and the my clients both. I’ve built a custom LESS framework (I am currently writing a SASS framework for it though) for every feature but have them all using the same variables so when something needs changed I only have to do it once.

    When it comes to control over CSS, like Chris said in his video, Preprocessors only output what you tell them to output. So you have just the same amount of control, you just have more options to cut back on the physical work. It’s kinda like driving a car, when you turn the steering wheel it turns a shaft in the steering column, which turns the gears in the steering box, which pushes a shaft, which turns the wheels right or left. You don’t hear anyone saying “I like being in complete control of my car, so I get out and turn the wheels by hand whenever I need to go around a corner”, that would just be insane. xD

    While we’re talking about Preprocessors, there’s is an awesome tool I’ve been using that people who use Windows and can’t use Codekit should all go check out. It’s called [Prepros]( “Prepros”). It does LESS, SASS, MD, COFFEE SCRIPT, HAML and many others. It even has a live browser refresh app for Chrome (and one for Firefox?). For people new to Preprocessors, all they have to do is download, install, drag a folder in for their project, and then get building. Super simple. ;)


    <<< Just noticed that multiple people have talked about Prepros on other threads. lol Ah well, good advertisement. xD


    As long as you enjoy the process and code with passion, that’s all that will ever matter.

    Amen to that!


    Once I found the WP-LESS plugin for WordPress, as well as gotten used to the different features of LESS overall, I made the move and never went back.

    For me, the nested selectors worked like a charm. I do take the “overqualified selectors” into consideration as I work. My rule for that is as follows…

    1) NEVER nest an #id selector…

    .element { #id {} }

    1b) UNLESS it is to add upper-level definition (which brings in the self-reference character of ‘&’)

    #id { body.class & {} }

    which would appear in the fully rendered CSS as…

    body.class #id {}

    Is it bad for me to rely on a pre-processor for my CSS work? That depends. I still know how to code non-pre-processed CSS (and most of my LESS code is still normal CSS, just with additional features), and I could create code snippets to speed up development, but for my personal workflow, I find LESS mixins to be far more beneficial for speed in development, plus I use them more often then I used code snippets.

    Also, with mixins, i feel that I am extending CSS to add features that dont come with it standard. Being able to shift around colors with features like lighten, darken, hue, saturate, desaturate, fadein and fadeout helps me greatly, especially with variables.

    Add to that the fact that my development software of choice (Coda 2 on the Mac) has in-built support for LESS, as well as variable name auto-complete, streamlines my whole development process.

    My suggestion is to NOT use it because you think you *should*, but instead use it if something in it will help your workflow overall. If you dont feel that it will help your workflow, dont use it. Thats why I picked LESS over SASS.

    LESS just felt more usable to me than SASS, even though I haven’t used all of the features that LESS has to offer. Example: I haven’t found a good use for Guards, Iteration loops, or javascript evaluation in my projects yet, but I know that when I do find a good use for them, I will start finding good uses in more places.

    Then there is CoffeeScript, the LESS/SASS-like pre-processors for JavaScript. This one is just something that I am not ready to dive into, but it is there in case I do find a use-case.

    Same thing happened to me with JQuery when I first learned about it. I was in the process of trying to use Scriptaculous, but was having difficulties getting it to work the way I wanted it to. Then I jumped into JQuery and have used it ever since, to different extents, and am still learning new tricks every time I use it.

    Its almost like the idea of CSS Reset sheets. For people who like them, they use them in nearly all of their projects. For those that dont, they dont. People who use LESS, myself included, may find that creating a personal mixin library can help greatly for different projects, as they can just move it from project to project, adjusting things in it as needed.

    Some people like to reinvent the wheel (nothing wrong with that, since better wheels can mean better performance overall, as well as a direct knowledge as to what may or may not be working properly), whereas other like to have a pre-made framework to speed things along.

    Another example: I also do electronics work from time to time with the Arduino microcontroller. I can either build my own (which I have done) and just use the inputs/outputs I need (this would be equivalent to coding with CSS), or I could use the premade boards (UNO, Mega, etc) to do my work if I am not in the mood to solder anything for a project (this would be similar to using LESS).

    : you mentioned you dont feel the need for shortcuts. Keep in mind that CSS has built-in shortcuts/shorthand for different elements. padding, padding-left, padding-right, etc. This may be over-simplified and not relevant, but I personally consider LESS to be an extension on that idea. I dont want LESS to do the hard work for me, I just want it to get the tedious work away from me. We have so many vendor-specific CSS options/properties that it becomes time-consuming for me to make sure I covered all of my bases when coding. The ability to bundle all of the vendor-prefixed versions of, say, border-radius (more relevant a few years ago than it is now), and then just work with a single ‘.border-radius(5px)’ line in the rest of my code saves me countless hours (overall) of having to debug issues. It also makes it more uniform, as I dont have to search for the 1 instance where I forgot to put in the -moz version of the property, or the one property I spelled it ‘boarder’ instead of ‘border’ (which can be even harder to spot when it is smashed in between 3 or 4 other vendor-prefixed lines of code). Since the mixin just duplicates it across all of the selectors that make use of it, it reduces the number of places I have to look.

    But again, it is all up to the individual and personal preference.


    bah, now I am all paranoid about CSS specificity and OVER-specificity. I do have methods, like I stated above with the #id selector comment, to help reduce specificity, but LESS and other pre-processors still add too much specificity at times. I could go with the idea of using classes over IDs, but then I get into the area of possibly having to over-complicate my HTML code with class definitions on a lot of elements. Add to that, we dont just have ID and class, but tag-names as well. for me, at the moment, its more about “what feels like it fits better for the situation”

    as of right now, my selector optimization with LESS is to break out any hierarchal/nested ID selectors so they are at the top level of the LESS document. This way #sidebar is not nested inside of #page-content, which is in turn not nested inside of #page-wrap. However, as said before, there are times where I need an element above the #sidebar to provide an extra level of specificity depending on the page in question (so #sidebar and body#pageClass #sidebar would provide a different visual appearance).

    as with all programming/scripting/markup/defining/bacon, once you learn something that you realize will help in the long run, it stays with you into the future.

    “the more you learn, the more you realize there is to learn” – Benny Hill… misquoting Socrates :D

Viewing 15 posts - 16 through 30 (of 30 total)
  • The forum ‘CSS’ is closed to new topics and replies.