The Carrot Blog

It's no secret that the redesign of carrot.is is built on top of roots, a framework that I've been working on both at carrot and on my own time for nearly a year at this point. In this post, I want to discuss the decision to use roots, as well as some of the backstory and the most important features we took advantage of in order to get carrot.is operating smoothly.

I started working on roots at Carrot more than a year ago because I was fed up with writing the same css patterns over and over. As part of working at an agency, developers are exposed to a wide variety of different work in different styles that we run through very quickly, so we can't create a UI library, or code the css for a page once then recycle. Every project has entirely different requirements, and must be coded from scratch. In this circumstance, the only way to speed things up is to abstract higher level patterns we see when writing css, because anything too specific could not be consistent across all projects. Things like transforming lists to be inline, writing gradients, darkening a button on hover, setting the width and height on an element - these are all things that could be abbreviated.

Using sass, I started writing a small library that created abberviations for a bunch of these common patterns. Initially, I coupled it with stasis for building smaller static sites, made a gem for rails, and found that it saved us tons of time and made writing css a lot easier. After using this early prototype for a while, I started wanting more, both out of the css library and the static site builder. I wanted the power to read values off a parent element and set them dynamically from a mixin. I wanted the webpage to reload every time I made a change to a file. I wanted a cleaner, simpler project structure. So the process of building roots began.

The first version was shipped a few months ago, and got generally good reception, which was really exciting. Since I have been using roots, I have fallen more and more for static sites. They are so incredibly fast and straightforward, and more dynamic content can easily be loaded in with javascript.

I wanted the new carrot site to be static, but the fact remained that there would be a lot of content that changed frequently on the site, and eventually we would want other people to be able to change it. This led to the development of dynamic content in roots. Objects like staff members, press posts, capabilities, etc are all collections of custom objects that can grow and shrink. They can be treated somewhat like blog posts, except they don't only have to have words, or be ordered by date, and they can have any number of custom properties. This is what I call dynamic content, and it's a way of organizing dynamic collections of objects that share a common parent. Once this feature was added to roots, it seemed feasible that it could fit with the carrot site.

While we worked on the website, Tony was finishing off a really excellent API for all our carrot staff information. To integrate this into the site would usually mean hitting the api with an ajax call then building a huge string of html manually inside the javascript in order to render each staff member. But luckily, we had just built precompiled templates into roots, which meant it would be easy for us to write the templates in our usual jade, and have them render seamlessly from javascript.

Throughout the process of building the new carrot site, it seems like we squeezed every feature we could out of roots. It certainly helped to have had built roots in-house, so we knew if anything needed fixing or an additional feature was required, no panic was necessary. But now that the site is live, it proves to us that roots is entirely ready for tackling large production apps. I'd encourage you to give it a try for your next site. Roots is free and open source, there are a number of brand new tutorials up, and we will be open-sourcing a number of components that went into building the site as well over the next couple weeks as well.