dont-use-sass

View Github Repository Open presentation in a new window

iamcarrico

See all presentation from iamcarrico

dont-use-sass

0 0

dont-use-sass

On Github iamcarrico / dont-use-sass

#dontUseSass

Don't Use

SRSLY...

Hello! And welcome to my speaker notes. I have attempted to add in what my thoughts are, and some of the words that would be said during the talk. Also, below is the list of articles that spurred this talk. https://github.com/Compass/compass/issues/1789 http://alistapart.com/column/what-will-save-us-from-the-dark-side-of-pre-processors https://github.com/sass/sass/issues/1019 http://www.sitepoint.com/avoid-sass-extend/ http://www.sitepoint.com/sass-extend-nobody-told-you/ https://github.com/HugoGiraudel/sass-guidelines/issues/28

Ian Carrico

Web Performance Artist, Vox Media

What is this?

  • What is wrong with Sass?
  • Why did I stop using it?
  • How can post-processors save us all?

@extend causes bloat

What is wrong with it?

  • Long selector chains
  • "Invisible" in how it operates
  • Can't use within media queries
  • Not flexible
Hugo Giraudel's article (http://www.sitepoint.com/avoid-sass-extend/) goes into depth at what is wrong about over-using the @extend directive. It can allow for many selectors to all be used for a single rule (see: clearfix). It also acts in an invisible sort of way, without a logical way of knowing where a selector will be placed when you extend things. This causes some rules to be extending without you wanting them to be. Mostly though, it is 100% inflexible, not allowing for input to change the output. Some samples that I use: http://sassmeister.com/gist/e3f8e6eb925eea301a1a http://sassmeister.com/gist/ffebe27d8f8f8c43aa6d http://sassmeister.com/gist/6fc782abeb1f3722e4b4 http://sassmeister.com/gist/6080e0c363526d40c1f6 http://sassmeister.com/gist/05f5bfb5275ddcd5d2f0 http://sassmeister.com/gist/258528c84bde2fdad2da

@mixin causes bloat

Huh?

  • Flexible, but repeats output
  • Repeats output
  • Repeats
The worst part of mixins is that they repeat themselves. Over and over. In fact, they repeat what they are doing again. Even worse: they repeat themselves to drive a point home.

Ruby Sass is Slow

Compile times are long

What more needs to be said here? A 'fast' project is 4s, but that can go up considerably. Why do we need a website to be under 1000ms but our preprocessor takes 5x longer than infinity. This causes all of our developers to cry out simultaneously in wails of pure pain. Also, yes— there is an XKCD for this. It is kind of awesome, but does not really apply to us. Because I think my boss won't understand that I have enough time to sword-fight with designers in 10s. https://xkcd.com/303/

LibSass is not feature complete

Current stats are available

There really isn't much more to say here. Even though LibSass is roughy 10,000x faster than ruby-sass, I can't use maps in it yet. And that is by far the most important thing for my sanity.

Can Post-processors save us from ourselves?

There is hope on the horizon— post-processors. Already many of us use one of them, autoprefixer, and forget that what is being billed right now as "post-processors" are really just preprocessors with a different title... these youthful pieces of software are going to come and take over the world of design like nobody's business.

Okay, what is this actually about?

The internet is obsessed with things being "over"

I see articles all the time from personal blogs to A List Apart describing the next big thing. Usually this is coupled with the death of another type of software. Although I will read many of them to see what the frustrations people are having, or what features people are looking for— I always take them with a grain of salt.

Sass is mature

There are few choices in the creating of the Sass language that did not evoke a lot of consideration. Nothing was taken lightly, and especially the more advanced features were carefully considered as they were being created. This has led to an incredibly stable and mature language.

The community makes it

A piece of software is only as good as the people that make it, and we hae the best people. And you are the best people. Across the globe, from Hampton to Natalie to Chris E. to all the amazing conference organizers, the meetup organizers, the open source contributors, to the people who submit bugs on my issue queues, all of us have worked together to create an amazing, open, diverse community.