My first Twitter Bootstrap: What I liked and what I didn’t.
I’m working on an MVP for a great client right now. Although the two guys behind the app are really design-y by nature, their goal with this iteration is to produce a basic desktop version, get it in front of users, and see if it’s worth pursuing further. So on the front end, I felt like my obligation to this client was two-fold: do great work, but do it fast.
It was a great opportunity to finally give Bootstrap a try.
Created by Mark Otto and Jacob Thornton at Twitter, Bootstrap is a comprehensive front-end development framework that provides a foundation of markup/styles and javascript interactions for stuff you end up needing for nearly every project: reset or “normalize” CSS; CSS for grid layouts, pleasing typography, and common navigation patterns; and javascript plugins for drop downs, tooltips, accordions … the list goes on. Poking around Bootstrap for the first time, I was amazed by how much it encompassed; I couldn’t wait to give it a whirl.
Nevertheless, I still had mixed feelings about building on someone’s framework — most, to be completely honest, related to slight ego and control issues around my style sheets. CSS is my specialty; it’s my main area of expertise and my greatest professional pleasure. For the past three years, I’ve been constantly tweaking and updating my own personal, uh, “ultimate package” (I’d stop short of calling it a real framework) I use to start projects. I know the styles like the back of my hand by now, which makes for fast development and easy debugging.
My relationship to javascript, however, isn’t quite as cozy. Like many other front-end developers I’ve met who arrived in their jobs via the world of design, I find writing javascript rewarding but also fairly time consuming—I usually end up doing a fair bit of non-billable work double- and triple-checking my code. (And on a side note, one thing I love about working at 12 Spokes is having “real” javascript developers critique my work. I feel like I’m learning a ton and shedding a lot of bad habits I developed as a result of being mostly self-taught.) A speedy MVP project, however, is neither the time nor the place for poring over front-end code or reveling in teachable moments. And what made Bootstrap extra appealing was the prospect of having “good enough for Twitter” javascript plugins at my disposal.
So how’s it worked out so far? In a word (or two): damn well. Bootstrap’s javascript/jQuery plugins were everything and more I’d hoped they’d be. Without a doubt, they saved me time during development: I found them easy to style and hard to “break” (two drop downs in the same div? No problemo.) One major bonus surprise was the built-in icon set from Glyphicons. I didn’t always use their icons in the final iteration, but for quick prototyping, they were very handy. As for the CSS, it’s super well-written, and the default styles are really attractive jumping-off points for your own visual customizations.
Two main observations I’ve made so far during the project:
Bootstrap is more visually prescriptive than I thought it would be
This is by design: As its name suggests, Bootstrap is perhaps best suited to developers who want to bring their ideas to fruition without needing to learn the intricacies of CSS or request the help of a designer/front-end developer. The design of our app was 100% custom, however; and I found that unless you want your app to scream, “I was built with Bootstrap!!!”, you’ve got to do a fair bit of overwriting.
And during my efforts to overwrite Bootstrap’s default styles, there were occasions I found the framework overly prescriptive. The biggest culprit was typography. For some reason, the authors set font-family, font-size and line-height defaults for elements like paragraphs, instead of just adding those styles to, say, the body, and letting them cascade down (and thus be easily overwritten). So if you create a new style for a container where you want, say, a different font and color, what should be this …
.new-box { background: red; color: white; font-size: small; line-height: 1.5; font-family: 'Comic Sans MS' } |
… turns into this:
.new-box { background: red; color: white; font-family: 'Comic Sans MS' font-size: small; line-height: 1.5; } .new-box p { color: white; font-family: 'Comic Sans MS' line-height: 1.5; font-size: 11px; } |
Avoid the Gemset
If the Bootstrap authors read the above, they’d be well within their rights to say, “Whatever, dude. If you don’t like our type styles, don’t use ‘em”. And one thing I love about Bootstrap is that it’s super customizable. The authors make it easy to only download the components you need. However, we’re a Ruby on Rails shop, so importing Bootstrap via a Gemset seemed like the natural way to go when we were setting things up. What I didn’t realize (and please let me know if I’m wrong here, world) is that when you import Bootstrap via Gemset, there’s no way to a) remove the CSS and javascript files you don’t need to load, or b) directly edit the Bootstrap styles. So what this leads to is unnecessary code getting loaded and a lot of overwriting Bootstrap defaults downwind in your own style sheet (instead of just editing the original styles). Before this app goes to production—and when we know exactly which Bootstrap components we’ll need to include—I’m going to ask Ethan to remove the Gemset, and I’ll create a custom download of the framework and use that instead.
Overall, though, Bootstrap is a major achievement in the world of front-end development and an incredibly generous gift to the industry from Twitter. I’m not sure I’m going to use its style sheets again (as someone who’s very comfortable with CSS, I just don’t think I’m its target audience there). The javascript plug-ins, however, will go right into my toolbox, and will definitely see the light of day on future projects.