A Front-End Developer’s Tookit
I started my career in web development as a front-end guy, writing an incredible amount of HTML and CSS day in and day out. Now a number of years later, I find myself getting back on that horse, tackling the thorny issues of website layout as a consultant.
I never really stopped doing front-end work, but while I was out sharpening my other programming skills, there were some new developments that I quickly had to acquaint myself with:
- Three (or four, depending on your support level) concurrent versions of Internet Explorer
- HTML5 and CSS3 support in what are now commonly used browsers
- A sudden emergence of mobile browsers
- The philosophy of responsive design
The funny thing about front-end development is that I’ve never found it to be particularly difficult in the sense that it requires a great deal of abstract thinking or problem solving skills, but it does however require enormous amounts of detail work. The process of writing application on the back-end is so complex, we’ve developed incredibly mature tools to let us split the logic up into pieces and modules so we can focus on one problem at a time. But when writing HTML and CSS, we’re typically forced to work on everything at once, and keep the entire layout system in our heads. Websites have only gotten more complex, and trying to keep track of a thousand different elements, their children, class and ID names, etc can be an exhausting mental tax.
Front-end developers historically haven’t had the same set of sophisticated tools that their back-end brethren have been using for decades. When putting together a comprehensive set of website templates, we’re typically faced with the same problems again and again:
Long, poorly organized files.
I know most people have a system, but is there any real good rule of thumb for organizing a CSS file? Alphabetically? By order of element appearance? By display module? Split it up into text and block styles? How do you organize descendant selectors, overrides or shared classes? It’s not easy, and I always find myself simply falling back on my text-editors find command to get where I need to be.
Code repetition.
Lots of it, especially when writing static HTML. Creating a dozen site templates? That means pasting the site header and footer a dozen times. Have fun updating each one when making a small change to HTML. If you’re smart, you’ve been concatenating files together with PHP. But what about 2-step layout or partial rendering? Wouldn’t that be nice?
Really complicated defaults.
How long does it take you to zero-out your browser styles so you can start writing actual site code? Are you taking HTML5 elements into account now? Did you remember to add all your meta tags, set the charset=utf8, force the latest IE rendering engine, and import that latest version of jQuery from Google’s CDN?
Or do you just do what I typically do and open up the last project you worked on to copy and past all that into the new file?
Complete lack of programmatic logic.
If it wasn’t for javascript, I’d lose any sense of what real programming was like when writing front-end code. Admit it, CSS is a pretty boring language to work in. And how often do you find yourself going back to photoshop, or scrolling to the top of your document to get the hex value of a color? Do you see the words Arial, Helvetica, sans-serif float by when you close your eyes?
Face it, doing front-end development of even remote complexity can be a boaring and mentally exhausting exercise in repetition and inanity.
There’s hope.
Introducing Things With Prototypes
It would be unfair to the development community to state that there hasn’t been much progress made in the past few years. In fact, there have some pretty amazing tools under development for years. But it seems to me that only in the past year (or two), things have really picked up steam and these tools have matured to the point where I’m comfortable integrating them into an everyday tool chain.
So I present Things With Prototypes, a collection of tools, frameworks and technologies to help any front-end developer get their work done faster and better. These aren’t technologies I created myself, I’ve just bundled them up into a neat little package you can user over and over again for each new project.
Prerequisites
I won’t go into setup instructions here, but you will need to have Ruby installed on your system to use it, and will possibly need VirtualBox as well if you plan to use a virtual machine as a development environment.
What’s included?
Things With Prototypes brings together the following tools to work together in harmony:
Sinatra
Sinatra is a Ruby-based framework that’s really, really simple. Its main purpose here to to handle url routing and page rendering. It will allow you easily call partial html files, execute a 2-step layout and build helper functions to reduce the amount of repetitive code and DRY up your templates.
HAML
This is one of those love-it-or-hate it technologies, but if you find yourself typing too many angle brackets in a day, you’re gonna love HAML.
You know how HTML looks like this?
<div id=‘main’>
<ul class=‘my-list'>
<li>This is an item in my list</li>
</ul>
</div>
The same HTML written in HAML looks like this:
#main
%ul.my-list
%li This is an item in my list
In essence, HAML is a white-space sensitive language that compiles down to HTML. It will save you a lot of typing.
SASS / SCSS
SASS is cousin to HAML, but seems to be a bit more popular among the development community. It’s essentially the missing link for CSS. It comes in two different language flavors: one is HAML-like and whitespace sensitive, and the other looks a lot more like traditional CSS. Which one to use is a personal presence. But both syntaxes provide the following benefits:
- Nested selectors, no more typing the same selector prefix over and over again
- Inherit styles from one selector to another
- Variables. Honest to god variables.
- Mixins, or pre-defined blocks of styles that can be included inline
- Conditionals, loops and functions. Yea, you heard me.
Sass is great. It takes some getting used to, but it makes plain ol’ CSS look just silly by comparison.
Compass
Compass is a CSS3 framework built on top of SASS. It provides an extra layer of awesome, including pre-defined modules, helper functions and integration with the Blueprint layout framework (if you’re into that sort of thing). It’s very extensible too, allowing you to build your own front-end swiss army knife.
HTML5 Boilerplate
Boilerplate is probably my favorite piece in the tool chain. I’ve always been a bit hesitant about frameworks like the 960 Grid System or Blueprint, as they often force you to adopt a specific markup or layout structure. However, Boilerplate is different. It’s a set of CSS and HTML defaults designed to give you the best possible starting point for creating a site that will work rock-solidly across all browsers and devices.
If you want to start safely writing in HTML5 today, look no further than the Boilerplate.
Middleman
Confession: When I originally put together Things With Prototypes, I wrote the Sinatra, Compass and server integration myself. It worked pretty well, but then I discovered that Middleman did all that and more.
But primarily, we use Middleman as a static site compiler. When you’re ready to deliver files you client, you can issue a single command to take your entire application and compile down to plain HTML and CSS. Couldn’t be simpler.
Not an Immediate Panacea
Okay, so if you’ve never used a Ruby framework before, using this package will feel pretty overwhelming. But I encourage any developer who likes learning new stuff to check it out. There’s some pretty wicked-powerful tools in here that could really revolutionize the way you build websites.