Wednesday 11 June 2014

Ever felt like you suck at handling CSS?

I am a back-end developer at heart. I have a passion for APIs, console applications and libraries. Every time I hung around frontend engineers, I felt like I suck big time. All those fancy and complicated tools, and they still keep on top of everything. I hate worrying about whether the files are in the right place, whether the CDN has the newest asset, etc. I like order, and I hate sucking at things.


Recently I've wondered down the path of doing some full-stack web development again, and this time I wanted to do it right! I didn't want to suck at it! Fortunately, I have the amazing opportunity to work with @designhorf, so it's not only about my worries anymore. He's doing all the magic in CSS and HTML land, but I didn't want him to have to care about anything else apart from creating and implementing awesome design.

Here are a list of things I never ever wanted to touch manually:
  • browser support in CSS files
  • static analyzing CSS, JS and SCSS files
  • rendering CSS from SCSS files
  • minifying CSS, JS and SVG files
  • invalidating CDN caches
  • deactivating CDN URLs in CSS files when working locally
... and the list goes.

I promise I will write detailed blogposts about things we've discovered, but not just yet. We're too busy creating Tailored Tunes.

The only thing I have time for now is an unordered list of some things to look at if you too worry about these:

  • Compass for SCSS. It gives a ton of shorthands, so you don't have to worry about browser compatibility too much anymore.
  • Grunt.js that automates everything for you
  • npmjs to manage grunt plugins
  • The Guardian frontend project sets an amazing example how to use Grunt. Take a good look at all the loadNpmTasks(...) lines. Those are all grunt plugins. Most have decent documentation, just look them up and see if you need them or not.
  • Use the fact that Heroku (and most environments you deploy to) can execute Grunt! We're using an apache+php, so we put the generated css files into git to avoid needing ruby on production boxes for the sake of compiling assets.
  • Finally, here is an excerpt of the Grunt tasks we're using
Remember: Developer experience is just as important as end user experience!

So what's our current workflow with this setup?


Whenever we're doing things, we're running grunt watch on a terminal in the background. That detects changes in files, and applies tasks that are needed to get that change into the assets the site actually uses.

We have a git pre-commit hook, that runs grunt before each commit, and adds all the generated CSS files to the payload, so that we don't have to remember to add them manually.

Upon deploy, our custom heroku buildpack runs grunt deploy to minify things, hash things and enhance URLs.

What are the benefits?


We've been using these tools for a while now, and I can say the following: I feel like my asset handling doesn't suck anymore!

Every bit is automated and version controlled. The only thing we have to worry about now is to come up with a product and a UI that people will love using, as much as we love creating it!

So that's about it for now. If you have any questions, please feel free to ask them, and we'll try to explain and show everything we can. We'll be blogging a lot about this on Tailored Tunes's yet to be born developer blog.

No comments :

Post a Comment

Note: only a member of this blog may post a comment.