or: How I Learned to Stop Using Twitter Bootstrap and Love LESS
Recently, we’ve started a pretty large UI overhaul, with fresh design work, heading in a slightly new direction, we were going to try to build something more cohesive across our projects. It was a flat design, going along with the trends, and we found the Flat UI theme built on bootstrap which matched a lot of our design. It seemed like a clear win.
When work began, I devoted some time to getting up to speed on what the current best practices were in the CSS world. I knew we had built up some cruft, and I wanted to clean it up along the way. I found OOCSS and SMACSS and decided to give it a deeper look. I watched some presentations and read the SMACSS book, and it all clicked pretty well. Many of the ideas I was familiar with, such as the technique of using multiple classes to refine styles, but I hadn’t really gone through the level of structural rigor that OOCSS and SMACSS prescribe. It made sense to me, though, so I wanted to use it during our overhaul in conjunction with Bootstrap, which didn’t seem to conflict too much…
Well, long story short, after really digging in and trying to make it all work – to make the app work the way I needed it to, and look the way I needed it to – I found that the number of overrides I was making became much more than the value proposition of Bootstrap to begin with. Combined with the Flat UI theme, I was writing overrides of overrides. I had two sets of variables and mixins, plus my own. I was dropping entire chunks of functionality like grids and forms because they were doing more harm than good. In the end, I ultimately used some code from Bootstrap and the Flat UI theme, but I condensed it all without overrides, and really just used it as a scaffolding for the final design.
So what’s the conclusion here? Should people avoid Bootstrap? Would I do it over again differently? This is my final takeaway:
- I’m glad Bootstrap got me into using LESS (judiciously).
- Bootstrap helped me figure out a good way of organizing my LESS files.
- Bootstrap has some good ideas about breaking down some of the fundamental components of a page and figuring out what those pieces are. What the vocabulary is. A lot of that I kept even if the css, classnames, and even html changed.
- I’m a snob and I think the dropdown and tooltip widgets (the only two I even tried using) are kind of crap. They work fine in prototyping, but have fundamental flaws.
- Bootstrap makes tradeoffs to have nicer looking html. We take a different approach to get nice view code, and don’t need to make those tradeoffs.
- Finally, I realize that not all apps or websites are like Octane. Other people may have no time or talent for design or implementation of custom CSS, in which case, Bootstrap is a pretty good foundation. It also works pretty well for just prototyping or scaffolding.
Before I made the final decision to remove our dependency on Bootstrap, I looked around to see what others were saying. There’s a lot of praise for Bootstrap out there. Given that my ideals had shifted to OOCSS/SMACSS, I was curious about that intersection. I got my answer here. To pull some choice quotes:
“Yeah, my initial impression has been that design is too tightly coupled to structure. You can’t easily reskin w out ripping out or overwriting their styles.”
That was from Nicole Sullivan, creator of OOCSS and well respected authority of good CSS.
“I’ve used it for 3 projects now. At first I loved it, but now I think that I live only a few aspects of it – the mixins, icons and buttons.
It is an amazing project, but I actually prefer the lightness of the OOCSS framework.
While you can customize things in bootstrap, you ant take it too far before things start to break.
In the end, what it’s taught me about LESS is what I appreciate the most. I’m building a LOOCSS project :-p”
That was from another person in the thread, and it really echoed my own experience.
I’ve got more thoughts and experiences on OOCSS and SMACSS, and where we’re going with it, but I’ll just leave that for another post.