Apple Is Using Sass, And They’re Doing It Wrong — Le ministère de l'intégration

Sass gets new signs of recognition in the industry as more startups and major companies add the most famous CSS preprocessor to their toolbelt every day. Today, it is unlocking a gold achievement: “used by Apple”!

I discovered Apple rolled out a new design (codename Bento?) of the homepage of the Apple Store, and I always admired the passion they pour into their front-end code. As I couldn’t resist taking a look at this fresh CSS, I was happily surprised to see something quite familiar in a file named bento.css:

/* line 5, ../../sass/bento/bento.scss */

I thought to myself: Amazing! Apple is using Sass! And two seconds later: What the hell are those comments doing in a production stylesheet?

When a major organization uses your product.Hampton, is that how it feels?

Unfortunately, as I dug deeper, I discovered a few rookie mistakes that could have been avoided easily…

Sass Poop 1: Deploying Development Stylesheets In Production

Apple has an history of not minifying all of their stylesheets (especially in the Store). Thing is, they also did not disable Sass’ debug mode before deploying their code in production.

If you have a look at all of their new .css files, you’ll find CSS comments like this one:

/* line 22, ../../../sass/pages/lob/lob-support.scss */
.product-support > .box-content {…
}

The comment indicates where the rule in the output comes from in the Sass source. Although this debug information has nothing to do in production, it is a valuable piece of information if we want to know how Apple architects their Sass codebase. The file structure I could reconstitute goes something like this:

• sass/
  • bento/
    • _accessories.scss
    • _appletv.scss
    • _default-s-tiles.scss
    • _ipad.scss
    • _ipod.scss
    • _iphone.scss
    • _mac.scss
    • _ribbons.scss
    • bento.scss
  • pages/
    • lob/
    • jumpin/
  • pinwheel/
  • campaigns/
    • 2013/
  • _rs-base.scss
  • _buttons.scss

This nice directory and partials structure reflects very well their domain model, which is a good thing, but it also doesn’t encourage re-usability of components. Apple has been architecting their front-end like this for years so I guess this is working well for them (although I would recommend to think the front-end in reusable modules, not in single pages).

Back to the subject of asset minification: maybe the Apple Store build system does not feature a CSS minification task during the deployment of their Java application. It’s using ancient technology – WebObjects – which may have something to do with it. Or maybe the development team simply forgot to properly compile the stylesheets before pushing them on the repository.

What can they do to remove the line comments from the output? A first step would be to run this command before pushing to production:

sass --force --update sass:css

Or even better, having the build system minify the stylesheets automatically like this (in some situations it’s easier said than done…):

sass --force --style compressed --update sass:css

Sass Poop 2: Nesting Too Deeply

This is probably the easiest mistake to make. We all nest rules too deeply when we start using a preprocessor. I would expect a team of senior developers at Apple to be a little more clever than an average developer, but no: they did nest rules. Deep.

Pairing with a developer using Sass nested rules for the first time.

I found lots of very long selectors, evidence of their sin:

.bento {}
.bento .row {}
.bento .row .tiles {}
.bento .row .tiles.extra-large .info .tagline {}
.bento .row .tiles .ipads-xl-2013 .ipads-1of2 .info .installments {}

That’s 7 levels deep (sic.). On top of being quite inefficient and generating a large amount of code, these styles are completely un-reuseable.

As a reminder about nesting in Sass, please read The Inception Rule on The Sass Way.

Sass Poop 3: Unnecessary Vendor Prefixes

When using CSS3 mixins (bundled within Compass or Bourbon, which I believe they don’t use) or outdated automated CSS3 generators, the output is often bloated with unnecessary vendor prefixes, targeting older browsers that (almost) no one uses anymore.

For example, we can quite safely use the standard notation border-radius and box-shadow without vendor prefixes.

Box Shadow

In bento.css, we’ll find:

-webkit-box-shadow: -1px 0 0 0 #d2d2d2,-1px 0 0 0 #e6e6e6,1px 0 0 0 #d2d2d2,2px 0 0 0 #e6e6e6,0 -1px 0 0 #e8e8e8,0 2px 0 0 rgba(241,241,241,0.3),0 1px 0 0 #b1b1b1;
-moz-box-shadow: -1px 0 0 0 #d2d2d2,-1px 0 0 0 #e6e6e6,1px 0 0 0 #d2d2d2,2px 0 0 0 #e6e6e6,0 -1px 0 0 #e8e8e8,0 2px 0 0 rgba(241,241,241,0.3),0 1px 0 0 #b1b1b1;
box-shadow: -1px 0 0 0 #d2d2d2,-1px 0 0 0 #e6e6e6,1px 0 0 0 #d2d2d2,2px 0 0 0 #e6e6e6,0 -1px 0 0 #e8e8e8,0 2px 0 0 rgba(241,241,241,0.3),0 1px 0 0 #b1b1b1;

That’s a lot of code. Especially since the unprefixed notation of box-shadow is widely spread:

• Regarding the -webkit- prefix, maybe Apple wants to also serve an enhanced experience to their older devices (iOS <= 4.3)?
• But the -moz- prefix is really unnecessary, as Firefox 3.6 and lower are practically dead.

Border Radius

Some vendor prefixing may be needed for box-shadow (depending on their level of support), but what about border-radius? Does Apple’s browser support list actually include iOS 3.2 and Firefox <= 3.6?

-webkit-border-radius: 4px;
-moz-border-radius: 4px;
border-radius: 4px;

Could safely be changed in:

border-radius: 4px;

This would be a very small win in terms of page weight compared to the overall weight of their pages (~1 MB for the homepage), but it doesn’t make this less of a code smell.

Sass Doesn’t Create Bad Code. Bad Coders Do.

Roy Tomeij brilliantly covered that subject on The Sass Way:

Those who don’t see any use for pre-processors such as Sass often use the “bad code” argumentation. It creates too specific selectors due to nesting, huge sprites and they hate the way Sass enforces an architectural approach that doesn’t work. And it’s all true. If you’re a poor developer. You know, one who would handcraft too specific selectors, 15MB sprites and doesn’t know how to cleanly structure a project.

In other words: because the Apple Store front-end development team created smelly CSS code with Sass doesn’t mean Sass is a bad tool.

Apple, you inspired me in the past, especially the first time I was building the front-end of a “big” website. Your code is so much better than most Fortune 500 companies, which is why hundreds of developers (perhaps more) are viewing the source of Apple.com to understand how to build a scalable, robust and beautiful front-end architecture. Please, if you are going to use a preprocessor, use it responsibly. Thank you.