Grow your CSS skills. Land your dream job.

Does anyone NOT use a preprocessor?

  • # May 23, 2013 at 11:31 am

    I don’t nest anything besides media queries as can heavily add to the specificity.

    If you guys haven’t already, perhaps you should read (and make use of the methods on a project before making up your mind) an article by Nicolas Gallgher – [About HTML semantics and front-end architecture](http://nicolasgallagher.com/about-html-semantics-front-end-architecture/)

    # May 23, 2013 at 12:00 pm

    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.

    # May 23, 2013 at 1:58 pm

    I build custom skins/themes for a CMS called [mojoPortal](http://www.mojoportal.com/ “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](http://alphapixels.com/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. ;)

    # May 23, 2013 at 2:10 pm

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

    # May 23, 2013 at 3:49 pm

    I was in the, “I don’t really have the time to learn a new syntax right now, I’ll get around to it someday,” camp until recently, when a fellow front-end developer came to me for advice on preprocessors because he assumed I’d be using one. We got to talking about it, discussing which language would be better to pick up: Sass; Less; Stylus; etc.

    I settled on Sass, and he settled on Less, and I started really digging in, bought CodeKit (partly because if I spend money on an app, I’m sure as hell going to get my money’s worth out of it, so there’s motivation to learn the language), and instead of just tinkering a bit with it as I had been, I jumped right in and built my next work project using Sass.

    It fully halved my development time. What I found most useful were the nesting features and the color functions, combined with variables. I could finally use math in my stylesheets! I spent a half-hour setting up a “_variables.scss“ and added all of our institutions brand colors, then used the lighten and darken functions to set light and dark versions of each color, assigned a couple of measurements like “$gutter“, “$outerwidth“ and “$innerwidth“ (I found it awesome to be able to say “$innerwidth: $outerwidth – $gutter*2;“, for example), and that alone made a major impact on development time, plus gives me the ability to use it in future projects verbatim.

    I designed the project in the browser, so when it came time for revisions, all I had to do was edit a variable or two. Different color on hover, the customer would like it to be a darker blue? No problem, I could just change “$blue“ to “$darkblue“. Oh, the page needs more whitespace between elements? I can change “$gutter“ and everything slides into place perfectly. Not to mention gradients, border-radius and all the other little shortcuts like the parent selector.

    After using it on that first project, I can’t imagine not using it. I’ve gotten my coworker interested, he’s been playing around with it and going through my scss files to learn how I’m doing things. It’s just so much more efficient!

    NIX
    # May 23, 2013 at 4:03 pm

    @KeithPickering there are a lot of good reasons to use a preprocessor. @JoshBlackwood just listed TONS!

    However, if you don’t like them, don’t use them. It’s as simple as that. Don’t use anything because you feel like you “should” be using it. Or because someone else uses it and it works for them.

    Every web dev I know uses Dreamweaver. Not I. I just never cared for it. And you know what? That’s cool. I don’t care for Xbox, iPhones, Pepsi or The Beatles either. Does that make them “bad?” Of course not!

    As long as you turn out quality work, it matters not how you did it. As long as you enjoy the process and code with passion, that’s all that will ever matter.

    # May 23, 2013 at 6:28 pm

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

    Amen to that!

    # May 25, 2013 at 2:31 pm

    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).

    @KeithPickering: 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.

    # May 25, 2013 at 3:44 pm

    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 9 posts - 31 through 39 (of 39 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".