Using SASS?

I was wondering how many of you use SASS and how you went about learning it. I finished going to school for web development and have a great understanding of css, but didn't learn anything about pre-processors like that...

 

That's a Good Thing. Pre-processors, css foundations &c. only add a layer of abstraction and complexity, not to mention an obscene degree of bloat.

Anyone who would use that stuff isn't knowledgeable enough to be using it. Anyone with any degree of clue knows SASS et al are a waste of bits.

CSS is a fairly simple declarative presentation language, just as html is a simple declarative structural markup language; neither needs any help to do what they are eminently designed to do.

cheers,

gary

 

I'm just wondering how much faster developing with one is... as it's always been the speed issue that's mentioned during interviews and discussions. Does anyone here use it in a professional capacity?

 

When using that crap, the motto may be, "I don't know where we are or where we're going, but we're making good time."

There are only two reasons I can think of for using SASS; you don't know css well enough and need the crutch, or your employer requires it so he can hire lower paid help.

Personally, I'm for using it. Then I get called to fix the problems caused by incompetents using crap ideas in a crap application.

 

Well.
SASS, or SCSS have some benefits. Whether or not those are worth it, is another thing alltogether.
First off, you can use variables. Hence, you only need to declare stuff once, and then reuse that throughout the code. Colors, specific sizes etc. can be easily declared (and chanced) in one place. Whether or not this is something that you find useful is of course up to you.
Second, you can declare specific "sub-functions" which you can pull into other declarations - so you can create specific sets of rules which you can then pull into a specific declaration as well. Can be useful.
Third, you can declare stuff without redeclaring preceding elements/IDs/classes - so, say you have a standard set of rules for an UL element. Then you can alter that by adding IDs, classes or other distinguishing features within that declaration, something like this:

ul {
  //regules rules goes here
  &#specific_ID {
   //rules for this goes here
  }
}

Code (markup):

Again, might be useful, might not. However, this is one of the main creators of bloat, since it takes ALL the preceding elements, IDs and classes and adds them per rule when you build the actual CSS-file.
Last, you can use comments within the CSS-file just as you would any other code-file (it won't be parsed and output to the actual built CSS-file)

Personally, I like SCSS, not because I don't know how to use CSS properly, but because it provides a way to condense complicated rules, and keep repeated code in one place. Granted, it sometimes needs a bit of a clean-up after a while, since one has a tendency to add too much - however, currently I tend to land on about 10-15% more code in a CSS-file built via SCSS, than just plain CSS - and I usually spend less time actually building the CSS-file.

However, do you really need it? Unless you're using some sort of server-side setup which allow you to use the actual SCSS/SASS-file, without pre-rendering it (basically Ruby in some incarnation), you might not really benefit that much, to be honest.

 

To me, LESS/SASS/SCSS/whatever are just as big a bunch of ignorant halfwit nonsense as frameworks. They are at BEST a crutch for the inept who probably shouldn't be making websites in the first place, at WORST actively encourage creating more code and then being DUPED into thinking that more work is "easier".

Variables just means people have shitty naming schemes or don't know what ^H does. Mixins means people don't know how to use selectors properly... About the only useful thing they do is explode out the various proprietary browser prefix asshattery (that NEVER should have existed in the first damned place) that at this point the only ones you REALLY need to worry about is -webkit as Safari continues to age like milk.

As others have said, the only reason you could see a legitimate benefit from using them would be a complete and utter lack of understanding how to write CSS properly; to that I'd add that an equal lack of understanding of HTML is likely also a cause since CSS is only as good as the markup it is applied to.

Typically the "benefits" people claim only really happen if you are DUMB ENOUGH to be using broken ignorant rubbish like OOCSS style presentational classes, don't know how to use selectors properly, and on the whole needlessly overcomplicate the simplest of things!

Which is why I've NEVER seen a project using LESS/SASS/SCSS/whatever it's being called this week that wasn't as much if not more code BEFORE compilation as I'd use in the CSS, typically applied to two to three times the necessary markup. It's part of why you'll all the time see so called "experts" vomiting up 60k of markup and 300k of CSS to do the job of 12k of markup and 32k or less CSS. Realistically speaking there is NO legitimate excuse for an entire CMS or forum software to be using more than ~48k of CSS in one file per media target (which with most people ONLY designing for screen, that's ONE file) apart from utter and complete developer ignorance and ineptitude.

... and then just like with the "I cans haz intarnets?" bekaptah nimrod BS known as frameworks, people magically claim that writing twice the markup, more CSS, that produces more code and relies on more code to even function, WHILE introducing extra layers of abstraction that makes it harder to maintain, diagnose or sustain... IS all somehow magically "easier".

Pretty much just like with the mouth-breathing asshattery that is "Frameworks", if "preprocessors" don't set off your bullshit alarm, it's time to replace the battery.

 

saas is wonderful programming where you can change them with effective mind and there are more option and better interactivity than css
so go for saas and you can learn them saas from various resources and tutorials like w3schools and tutorials point

 

You'll also find a lot of the people who praise it usually have gibberish "Engrish moist goodry" posts of "feel good" buzzwords that don't tell you a single blasted useful thing. They then point at outdated webrot sites that are either disastrously out of date, or promote terrifyingly bad development practices.

Typically such sites and the works of such posters reeking badly of "WCAG, what's that?" while at it since again, most people who praise this type of sleazy nube-predating scam bait BS do so out of utter and complete ignorance of HTML, CSS, JavaScript, Emissive colourspace, accessibility, user experience, or any of the dozens of other things that should be understood before being allowed to flap their gums on the topic.

 

It is very simple if you use that kind of crap you end up with bloat, accessibility issues, usability issues, and non-standards compliant code. Garbage in; garbage out. Using it is perfectly alright if you do not care about tainting your reputation as a professional. A special point is about variables. There is a group within W3C that has tried multiple times to add variable to the CSS standard and keep failing because it is just about the stupidest thing you can do to turn CSS to the same ind of mess that juery turned simple scripting into.

See This editorial I wrote about the stupidity of add variables

Please let Gary know who you do this crap for so he can follow up and make a little extra $$$.

 

While adding variables to the CSS-standard (I assume directly in the CSS-code) might be very stupid, it has little to nothing to do with SASS/SCSS - you add/use variables in the SASS/SCSS-file, which is then made into a regular CSS-file, with regular CSS. The benefit of using variables while creating the SCSS-file is that you don't have to remember exact colors or specifics, you can just keep a short list of variables with fairly obvious names - usually easier to remember $main-text-color than rgba(45,78,60,0.7); (yes, I know the example is bad, I didn't even check the color).

Another thing which is actually an okay feature is that if you do something that doesn't parse correctly in a SASS/SCSS-file, it won't build properly, and you'll get an error-message - makes it easy to find and eliminate errors that could elsewise go unnoticed until someone goes to do something very specific on the site.

 

I have no issues with declaring color CONSTANTs as meta data in introductory comments. Then if you change colors a simple search and replace does the job with a few key-strokes. An error message due to a broken build is no real benefit. Running the file through a CSS validator (which you should be doing regularly anyway) obviates that increased, unneeded complexity and the second level of opportunity for WAD bugs.

cheers,

gary

 

Which again just reeks of not knowing how to use ^H in a modern editor... or failing to understand how to group selectors... or failing to understand how to leverage inheritance... or, well.... that pretty much says it, failing to understand how to use an editor OR CSS properly.

Which apart from the stray typo, if your CSS is "so complex" you need that functionality, there's probably something wrong with the CSS, or the HTML... or both!

You know, things like classed sandbags for nothing, redundant bandwidth wasting title attributes, pointless redundancies like the rubbish NAV tag, bizzaro nesting and redundant application of style, those sorts of things.