This article was written for entry level Front-end Developers and all the front-end enthusiasts that want to know a bit more about the subject. The purpose is to present some of the daily tools I use to build web interfaces and inspire self-critic minds to challenge themselves on each new project.
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 article it will be already outdated.
Know your stack
- 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 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 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!
For me the choice on what to use for front-end development was obvious: Bower. It was build 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, lets us deal with the decision on which versions to install or not and helps 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:
- Switch CSS
- CSS Cacheer
- DT CSS
- CSS PP2
- Hat (Less)
- Nib (Stylus)
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’s 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 allow 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 get’s 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:
- 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.
Just for fun, check out the complete list of CSS Frameworks out there: Twitter Bootstrap, Zurb Foundation, Skeleton, Semantic UI, Uikit, 99lime HTML Kickstart, Kube, Flaminwork, G5 Framework, Easy Framework, Blueprint, YAML, BlueTrip, YUI CSS, Elements, 52Framework, elastiCSS, Boilerplate, Emastic, Malo, Zebra, Baseline, Lovely CSS Framework, xCSS, FEM CSS Framework, Helium, Knacss, Groundwork CSS, Gumby, Seelva, Tuktuk, Maple, Fluidable, Ink, Kickoff, Cascade framework, Metro UI CSS 2.0, Jeet, Responsive Boilerplate, topcoat, Pure by Yahoo!, HTML5 Boilerplate, Sproutcore, Bootmetro, Ivory, Kickstart by Everything.io, Zimit, Google Web Starter Kit, Base Framework, Sassaparilla, Initializr, Amazium, Ske.
Damn, I’m tired!
Now that we’re all set to start, let’s wrap it up and produce some badass frontend code that will make our customers proud!