1. Apple Is Using Sass, And They’re Doing It Wrong

    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?

    Update 2013.05.30: Good news! The online Apple Store team updated their stylesheets to turn the development mode off (line comments do not appear in their production stylsheets anymore).

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

    Apple is using Sass!
    Hampton, is that how it feels?

    Update 2013.05.24: Apparently, this is how Hampton (the creator of Sass) feels indeed…

    Hampton Catlin
    "OMG OMG OMG" — Hampton Catlin

    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/
          • lob-support.scss
        • jumpin/
          • lp-jumpin.scss
      • pinwheel/
        • pinwheel.scss
      • campaigns/
        • 2013/
          • fathers-day.scss
      • _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.

    It's a trap!
    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.

    Thanks Apple!


  1. inaudiblediscussion reblogged this from kaelig and added:
    Reblog Chowder: A multi-step guide to avoid bad SASS code. A nice and quick read. Practically isn’t dead. Having worked...
  2. misspork reblogged this from kaelig
  3. maerys reblogged this from kaelig
  4. slsdesigns reblogged this from kaelig
  5. davidvenin reblogged this from kaelig
  6. petercoffin reblogged this from kaelig and added:
    I am a reaction gif in this article…
  7. shake4me reblogged this from kaelig
  8. angolive reblogged this from kaelig
  9. brickfactoryhq reblogged this from kaelig
  10. danknisley reblogged this from kaelig
  11. wpbasti reblogged this from kaelig
  12. cad911 reblogged this from kaelig
  13. sjoerdly reblogged this from kaelig and added:
    Very Comprehensive article on how Apple is using SASS on their homepage, and what we can learn from their mistakes.
  14. didikw reblogged this from kaelig and added:
    Things to point out before using Sass.
  15. robby reblogged this from kaelig and added:
    A nice list of best practices when using SASS.
  16. character-in-progress reblogged this from kaelig
  17. frontendpe reblogged this from kaelig and added:
    Interesante artículo con buenas prácticas para el uso de SASS y por que Apple lo está usando mal.