I went to SASSConf (my first SASS Conference!) in October 2014 and had a blast. The conference — organized by @itsmisscs and @Snugug and supported by a team of volunteers — had probably the most robust agenda in a conference I'd seen for a while.

SASSConf took place at convenient time for me — right when I was just getting into the meat of refactoring some CSS into SCSS for a larger redesign project at work.

The first day of the conference was set aside for scheduled speaker talks, the second day was set aside for two back-to-back workshops (you could choose from one of two during the morning and afternoon), and the third day was set aside for an un-conference. A lot of care was put into everything from speaker accommodations and food to technical learning opportunities. Oh — and the after-party on Friday encompassed a karoake and open bar that took place on a boat. A boat.

Before I get into more beautiful boat pictures, though, let me recap my main three technical takeaways from the conference:

1. What's the point? Don't Repeat Yourself. (DRY)
Instead of writing straight CSS in a single file for a single component, organize your CSS into different files based on meaning (e.g. the names of your partials can be _buttons.scss, _colors.scss, _layout.scss), and use variables and nesting to keep the CSS organized nicely. Doing this helps get rid of repetitive styles.

I also learned that people were actually using different versions of SASS — i.e. there was "rubysass" versus "libsass." Libsass is a little behind rubysass in its development, but still comes with some advanced features such as maps and lists. There are also a ton of supplementary tools that some SASS developers use such as Compass, Bourbon (a mixin library), grunt.js, gulp.js, etc.

However, my takeaway was that it wasn't important to go out and use every SASS feature or accompanying tool available. You should use SASS in a way that makes sense for your project, keeping in mind that it's supposed to _help _you write CSS more cleanly and follow the DRY way of thinking.

2. Mobile first!

I asked some conference-goers — including @jina, a co-organizer for one of the workshops — what their opinion was of using max-width vs. min-width media queries, and basically got a unanimous response in favor of mobile first. Min-width media queries it is, then.

In mobile first, you're developing for mobile devices from the start — making sure your website looks great on phones and tablets — before adding CSS styles that change the layout of the page as you stretch the page. Basically, one of the advantages of "mobile first" is that you don't need to specify a breakpoint size to target mobile devices only.

(Side note: I'm super glad I hopped on the mobile-first train, since I ended up suggesting it to my coworker, and we made a decision to go with it, and it made every part of the redesign project a lot easier.)

A couple of other tips I picked up re: writing CSS for the responsive web:

• Use ems instead of pixels (http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/). This might give you problems with IE8, but there are great libraries out there that help fix problems. UPDATE: Thanks Ana Tudor for pointing out that this issue isn’t really an issue anymore! The CloudFour blog post was published in 2012.
• Use modernizr, a javascript library that will do a quick check for what things are supported.
• https://github.com/jina/refactoring/blob/master/examples/named-media-queries.scss has a a great example of a media query mixin.

$bp-tiny: 300px;
$bp-small: 500px;
$bp-medium: 600px;
$bp-large: 800px;
$bp-larger: 1000px;
$bp-full: 1200px;`

@mixin breakpoint($media) {
@if $media == bp-tiny {
@media only screen and (min-width: $bp-tiny) {
@content;
}
}
@else if $media == bp-small {
// small and medium are 1px smaller than their previous variable
@media only screen and (min-width: $bp-small - 1) {
@content;
}
}
@else if $media == bp-medium {
@media only screen and (min-width: $bp-medium - 1) {
@content;
}
}
@else if $media == bp-large {
@media only screen and (min-width: $bp-large - 1) {
@content;
}
}
@else if $media == bp-larger {
@media only screen and (min-width: $bp-larger - 1) {
@content;
}
}
@else if $media == bp-full {
@media only screen and (min-width: $bp-full - 1) {
@content;
}
}
}

For a quick demo on use cases, this is what the CSS class .sidebar using the breakpoint mixin looks like when compiled: http://sassmeister.com/gist/ea430284384722b8f850

3. Your style guides should be "living."
My takeaways:

• "Static (un-automated) documentation is a lie waiting to happen. Live style guides are great." – anonymous.
• Basically, the argument for "living style guides" (style guides that developers don't manually have to update, because it updates automatically with CSS commits) is that style guides are fluid and will change. The design will change.
• Meetup.com has an example of a robust style guide: github.com/meetup/meetup-swatches
• https://github.com/hagenburger/livingstyleguide-workshop is a ruby gem that lets you easily create a style guide from your existing SCSS files using YAML/Markdown-type syntax.
• KSS is another popular live style guide creation tool.
• With style guides, adoption can sometimes be hard. You need to convince developers to use it and maintain it.
  HELPFUL REFERENCE LINKS
  http://www.anthonydispezio.com/sassconf2014
• Lots of great examples of advanced uses of SASS — with links to SassMeister, the JSFiddle-equivalent for CSS.

https://github.com/jina/refactoring/

• Lots of great examples from this repo. The media query mixin above is inspired by one of the code examples here.

Only ~100 people attended the conference. Although this was a relatively small conference, it was clear that SASS was getting more and more widely used. According to a javascript developer I talked to, last year at CSSDevConf over half the talks were about SASS.

OTHER NOTES I JOTTED DOWN

• Mathematicians have done very cool animations using pure CSS keyframes/SASS.
• Hampton (@hcatlin) is the creator of SASS and is mostly working on upgrading libsass (https://github.com/sass/libsass) to the same level as RubySASS (https://rubygems.org/gems/sass), which has a few more advanced features.
• More advanced features include: SASS lets you iterate over numbers, lists, and maps. You can also use @for, @each, and @while.
• "Pairing between a designer and a developer is awesome because you're learning from each other." – @jina (I say this from experience: I totally agree!)

MORE PHOTOS FROM SASSConf 2014

I won a book in a random lottery on the third day (unconference-style)!

Goodie bags for the attendees.

Speakers on the first day.

Guess where the conference was hosted — at Scholastic Inc.! The last time I'd been in the building was 10 years ago, when I'd won a writing award for a short story as a teenager.

Beautiful SASSMeister projected on a screen.

Between decks on the boat. Filtered.

Is that the Manhattan Bridge?