Every developer has their preferred ways of working, they like to do things in a specific way or using a specific app. It might be something simple like whether they use 2-space tabs or 4-space tabs. It might be a greater thing like whether they prefer Ruby or PHP or Java. Or it might be to do with how they work with two of the building blocks of the web, JavaScript and CSS.

Two tweets from @anthonyshort popped up in my timeline in the last hour, the contents got me thinking. The first tweet:

Learning that there was a lot I didn’t know about JavaScript thanks to jQuery. Starting to not like jQuery

The second tweet:

Ergh, normal CSS sucks balls after using Sass so much.

Anthony is a friend and good guy (which aside from the fact that he knows what he’s talking about is why I follow him), and I’ve definitely got nothing against the tweets above (even if they are basically the opposite of my current views), but I think the topic is something worth discussing, as both are more than valid points. Feel free to provide your own sensible views in the comments at the bottom of this article.

“Raw” JavaScript vs. jQuery

I’m a jQuery lover, I make no attempt to hide this fact. I lover that it (for the most part) lives upto its “write less, do more” tag line. It’s not perfect, but no JavaScript framework is, and it gets better with each update. I’ve used many other JS frameworks in the past few years such as prototype, mootools, scriptaculous, YUI. While they all have their ‘good’ points, jQuery has (for me) more ‘good’ points than the rest.

Something like YUI (which I currently use at work, and am desperate to get rid of) is packed with “stuff”, 98% of it you’ll never need or use. Its heavy, somewhat bloated (you don’t have to include all the individual components in the framework, but even the components themselves are probably larger than they need to be). For the most part it has pretty good cross-browser compatibility, which was the primary reason for it being our ‘chosen’ framework at the time. But after working with it for close to 4 years the love/hate relationship with YUI is about 90% hate to 10% love.

An example why I prefer jQuery over YUI. Our current YUI-based menu scripts (which admittedly aren’t fantastic, but they get the job done) are long, the implementation of the YUI code is a couple of hundred lines, then you’ve got to include 4 or 5 separate YUI components just to get the thing working - the menu component alone is a 600-700 line js file. I recently replicated the functionality using jQuery, it was about 15 lines plus the jQuery framework, and it took me only about 15 minutes to create form scratch.

A couple of quick examples, the same thing in ‘raw’ JS, jQuery and YUI, first ‘raw’:

document.getElementByName('myElement');

jQuery:

$('#myElement');

YUI:

YAHOO.util.Dom.get('myElement');

In a world where I build things in the browser, usually without planning or thinking them through fully first, being able to prototype these things ridiculously quickly using jQuery is awesome.

However. I still find that I return to just writing ‘raw’ JavaScript on occasion. I don’t necessarily see the point in including a framework if the ‘raw’ JavaScript itself is only going to be a handful of lines. Code for the scenario, jQuery when its needed, no jQuery when its not.

Knowing how JavaScript works, and being able to write it without the aid of something like jQuery will make your code better when you are using jQuery. If that makes sense. Its my view that if you have an understanding what that simple jQuery function (ie. the complex bit that you don’t need to write) is doing in the background, then you will get more out of jQuery (or whichever framework you are using).

“Raw” CSS vs. Sass

Now I can’t really provide any great thoughts on Sass, because I don’t use it, have never even tried it, maybe I should? Maybe the enjoyment I get out of writing ‘raw’ CSS is unnatural and wrong? Maybe I’m weird because I prefer to code css properties by hand (not using auto-complete functions).

I can see why people like it though the idea of nested selectors, variables, inheritance, mixins etc are all nice. I guess the “issue”, whether rational or not you can decide for yourself, I have with things like Sass is that I don’t want to have to compile my stylesheet in order to use it. Yes, I understand that Sass will mointor the .scss file and update the compiled .css file as needed, but doesn’t that make debugging a bitch?

For example, you write a style with variables, nested bits, mixins etc using Sass, then you load the page which uses the compiled css file only to find that the style isn’t behaving quite right. the first thing I would do is open Firebug or Web Inspector and try and work out what has gone wrong. With ‘raw’ css, I’d see exactly what selector and/or property is wrong, go back to the file fix it, reload and done.

But with Sass is it more difficult to track down and fix issues this way because the selector/property that Firebug or Web Inspector report won’t actually exist in your Sass file, and instead you’ll need to track down which bit of Sass is actually the cause of the issue? I’m well aware that its probably a silly argument, but that’s how I see it, and its the reason I’ve never used Sass.

Some of the examples on the Sass site don’t do much to convince me that I *should* be using it, for example:

.fakeshadow {
  border: {
    style: solid;
    left: {
      width: 4px;
      color: #888;
    }
    right: {
      width: 2px;
      color: #ccc;
    }
  }

why is the Sass style above any better or easier to write than this css style:

.fakeshadow {
  border-left: 4px solid #888;
  border-right: 2px solid #ccc;
}

Its a very basic example, and I know Sass does much, much more complex things, but in this specific case I don’t see the point in it.

I also see mixins, such as one that ‘simplifies’ the rounded-border syntax, as causing the same potential ‘knowledge’ issues for CSS that jQuery does for JavaScript. Especially if you didn’t write the mixin yourself. For example if you have a “round-corners” mixins that you use, but you didn’t write that mixin (so you don’t know what syntax it spits out the other side when compiled), and you just know that to make something round you use @include rounded(left, 8px);, the what happens when you get to a situation where you’re working on something that isn’t using Sass and needs rounded corners except you’re never learnt the correct syntax to be able to write it? Especially when the syntax is not the same across all browsers?

I’m not saying that these mixins are bad, or that people shouldn’t use them, but like I said about JavaScript above, if you’re going to use them you should have enough basic understanding of what they actually do so that, if need be, you can write the same styles without the aid of Sass.

Plenty of people have the view that Sass make css more awesome, powerful and easier - I’m not here to say they’re wrong - but for me, someone who several hours every day writing ‘raw’ css it just looks like it complicates things more than is necessary.

Conclusion

The more I think about this the weirder it seems. You would think that those those who like JavaScript frameworks like jQuery because they make life easier would be the same people who use things like Sass because they, apparently, also make life easier. And yes, it might very well be the case with a lot of people, what’s your preference?