Why Should We Care?
It’s a crazy world out there. We’re long gone from the time where a simple HTML document and some lines of CSS would do the job. Technology is evolving faster than the speed of light and most likely by the time I finish writing this tip, it will be already outdated.
Back in the day, if we wanted to put something online fast and cheap, the choice was obvious: PHP, some lines of (sometimes inline!) JavaScript and CSS and we all lived to see another day. Well, those days are long gone. With the highly competitive world we live in, choosing the right technology stack represents the difference between survival or burn down the startup initial funding without too much to show for it.
Know Your Stack
With this tip, I’ll approach in very simple terms the CSS related software stack of our daily front-end craft (JavaScript frameworks and JS Unit testing will be part of one of my next articles) with a general analysis to what defines the following concepts and its tools:
- CSS Pre-processors
- CSS Authoring
- CSS Reset and Normalize
- Grid Systems
- CSS Frameworks
- Package Managers
First Things First: How and Where to Start?
Let me start by saying what I consider the most important of everything in software development: don’t over engineer. If the tool exists, it doesn't mean that you have to use it or even know how to. Sometimes, the most effective solutions are the simplest ones. It's ok if you don't want to use frameworks, it's also ok if you decide to do a web app with some other language that's not Ruby on Rails!
Package Managers
With that out of my chest, let’s start by talking a bit about Package Managers. In case this is the first time you’re reading about it, a package manager's purpose is to deal with assets used to build an application. This means that it installs, upgrades, removes and manages dependencies of those assets. Practical examples are npm and bower that can be used to manage JavaScript modules like browserify, grunt, bower, gulp, etc. as well as the front-end components like grid systems, CSS frameworks, JS frameworks, etc. Both take care of the hassle of downloading and keep all our front-end components updated, a manual task not too long ago.
For me, the choice on what to use for front-end development was obvious: Bower. It was built and optimized for front-end needs since day one by removing from the equation the npm nested dependency tree. It keeps only one version for each package, let us deal with the decision on which versions to install or not and help keeping the page load to a minimum.
However, I'm not saying bower replaces npm since the ideal setup is a combination of the two. npm does a great job managing node.js modules and setting up developer tools like Grunt, Gulp and of course, Bower itself!
CSS Pre-processing and Authoring
CSS Pre-processors are programs that process our set of instructions and translate it into browser-ready CSS.
The most widely used today are Sass, Less and Stylus. I'll not go into too much detail in comparing the three because it would be like comparing different brands of beer. Even though they're all beer, the taste is different. I personally prefer Sass for the following reasons:
- Syntax: variables and mixins are more intuitive to write, for those of you used to the notation of scripting languages
- Loops: Less only allows a very not intuitive and inefficient way of self-referencing recursion to simulate loops
- Conditions: Less also makes you cry here by forcing you to write guarded mixins for logic comparisons for example
Last but not least, using Sass gives me the ability to benefit from the power of Compass, an authoring framework that extends Sass with a lot of very useful mixins and other tools that automate and help to maintain our .scss files. A few examples are generating border-radius, box-shadow, image urls, etc. For a full list on the helpers, read the documentation here.
Besides the helpers, Compass allows us also to run a few handy command-line tools like watching for changes in scss files, generating sprites and one of my favourites for monitoring frontend performance and complexity: compass stats that give us statistic information on our scss and css files by providing the file sizes, number of css selectors, properties, mixins, etc. If you want to dig in further, take a look to the remaining tools with an open mind:
Pre-processors:
- Less
- Stylus
- Turbine
- Switch CSS
- CSS Cacheer
- DT CSS
- CSS PP2
CSS Authoring:
Reset or Normalize?
To take out of the way the browser defaults and make our user interfaces look as similar as possible across all browsers, we can choose from one of the tools below:
- Eric Meyer’s “Reset CSS” 2.0
- HTML5 Doctor CSS Reset
- Yahoo! (YUI 3) Reset CSS
- Universal Selector ‘*’ Reset
- Normalize.css 1.0
Resets are around for quite some time and their main goal is to remove all built-in browser styling, giving the developer the ability to style everything from scratch, including things like headers and paragraphs. On the other hand, normalize targets consistency over styling. It aims to keep the defaults while making them look as close as possible between different browsers. We are then supposed to add only the additional styling we need, on top of what the browser already provides.
Between the two approaches, I personally prefer Normalize since it has a wider scope than the resets specially for HTML5 and mobile browsers, it doesn't strip down all the visual defaults of the HTML elements and essentially because it's much more documented than any of the resets.
Another way to look into this matter is to ask yourself: do I have a design team that will provide me all the web design specifications? Am I able to do it? If the answer is yes, maybe you should consider only the reset approach or use nothing at all since you'll end up changing everything either way. No design? No specs? Then probably you should accept the browser help an leave a few stones unturned regarding the final looks of your website. Whatever your choice is, make sure you:
- Strip down all the comments included on both normalize and resets
- Minify the entire file
- Include it in your main stylesheet
So you can avoid unnecessary and conversion killer extra network time and we can all live happily ever after!
Frameworks and Grid Systems
This is probably the area where more lines were written by the front-end development community in the last years. My last count of all the Google searchable frontend frameworks gave me more than 53 different results as well as 30 standalone grid systems. The possible combinations to choose from it is a pretty huge number so we've to make sure the right choice is made to scale our project.
When talking about Frontend Frameworks, I take the opposite approach as with CSS Resets. Either I use a very minimal framework that really can save development time and scales or I take the DIY approach and start with a small grid system to lay down my own styling set.
The biggest and most famous Frameworks like Twitter Bootstrap and Zurb Foundation are great for a quick prototype or a backend tool that doesn't require a special care about the User Interface or even in the case you have a very small / unexperienced team that will mostly add already existing modules and plugins on top of those frameworks.
The major advantage of small tools over this fat frameworks is the modularity and focus on abstractions. Instead of enforcing how elements should look, it gives us the flexibility to speed up development and allows to test new features faster.
What worked for me:
- Inuit: Provides a set of powerful tools that let you assume control of all the design elements on your website/application, without any loss on the essential helpers and modules.
- 960 Grid System: Although this grid system has been around since ever, it still gets the work done for simple and small websites, mostly with it's fluid version.
- Unsemantic: Can be seen as the successor of 960gs with the main advantage of being entirely based on percentages
- Susy: brought to us by Eric M Suzanne, one of the core developers of Compass, it's a very easy to use and agile tool that gets out of our way and provides a very short and intuitive syntax as well as a great number of SASS helpers that allow us freedom and flexibility to set up our own framework.
What didn't worked for me:
- Foundation: I followed Foundation development very closely since I'm a big fan of Zurb's work but after using it with a couple of projects, the JavaScript conflicts started to appear once I had the need to move away from what the framework provides. On a more personal design taste, I also never used any of the UI elements provided by default without some serious customization. Another reason is that in general foundation styling is a lot more verbose than for example Twitter Bootstrap, making the page look a bit messy.
- Bootstrap: Although is has a great tool-set and clearly pushes back Foundation on this one, Bootstrap went with LESS pre-processor which is a big no go for all the reasons I pointed out above.
Damn, I'm tired!
