Just over a month ago Twitter released Bootstrap, a “sleek, intuitive, and powerful front-end framework for faster and easier web development”. It offers the front end developer an easy and fast way to build web applications using clean semantic HTML and CSS.

We’ve been trying out Bootstrap to develop a new client web application. I’m not sure yet whether we can call ourselves “early adopters”. As I’m sure Twitter themselves would admit, there is some room for improvement and their regular updates reflect that. As with any third party toolkit it requires a thorough workout in a real development environment to discover what the real benefits and drawbacks are. I’d say overall the experience has been good and we have been putting it through its paces within an agile development process.

We are always looking for ways to simplify web interfaces, to make them easier to use, develop and extend in the future. Bootstrap provides many of the essential ingredients of a web application interface: grid, layouts, typography, tables, forms, navigation, alerts and popovers. It is built with Less, an easy-to-use pre-processor that provides more power and flexibility than standard CSS. If you’re a fan of Less this will delight you but for our first evaluation of Bootstrap we opted for the compiled version of the CSS.

 

Here’s a summary of our experience thus far:

This is a great aid to rapid development. With Bootstrap’s HTML and CSS code providing the initial building blocks, you can quickly get from prototype to a polished application interface. Functionality can easily be integrated, especially if you’re using a web development framework like Django, and very quickly you can enter into an iterative process of building and testing the user experience through workflows and interactions, alongside testing functionality. Front end engineers and backend developers start to work much more closely together, which is just what you want if you’re engaged in agile development.

 

Customisation

Applying the application’s own unique style or brand can be done independently without affecting the progress of the build. You have various options when working with the Bootstrap CSS. You can either link to a hosted version or download a copy to your own development environment. Personally, I prefer the the latter approach. I recommend also that you create an override CSS rather than edit the Bootstrap stylesheet. That way, you can update the Bootstrap CSS whenever you want to without having to re-apply your overrides. One word of caution: give your application a thorough check over when you’ve downloaded the latest Bootstrap release. I’ve had a few (albeit minor) adjustments to make to my override styles. Basically, if you treat it as a re-skinning exercise, you shouldn’t go far wrong and this is especially useful for white label products.

When creating style overrides, I usually start off quite enthusiastically as I marvel at how easily I can transform an interface with just a handful of styles. However, there quickly comes a point when you’re having to override quite a lot of the original stylesheet if you want a very different look and feel for your application. This is where you have to assess the pay-off. Is time saved on early rapid development worth the extra effort of lengthy overrides in the final application stylesheet? It really depends how much of Bootstrap’s default styling you can live with. I think they’ve done a pretty good job of creating a nice, clean look and feel, but it won’t fit everyone’s brand requirements, and in these cases more effort will required to develop the necessary style overrides.

 

Best practices

Of course as you start using 3rd party code you inevitably end up adapting it slightly and this goes for the HTML as well. In my experience I’ve been able to work very well with the Bootstrap HTML, it’s nice lean code, semantic and easy to adapt.

Bootstrap does encourage best practice when it comes to design and layout by providing a good, flexible grid system. It has a slight advantage over previously developed grid systems, such as 960 Grid, as you have the option to chose a fixed width or fluid layout. It’s a shame that Bootstrap haven’t yet provided a layout option for those of us who are embracing ‘responsive design’ – there are good toolkits out there that do just this, for example 1140 CSS Grid.

Bootstrap works on the principle of “progressive enhancement” – designing for future support of CSS3 without compromising on old browsers or relying on too many hacks or browser-specific styling. Having said that, Bootstrap does use numerous vendor-prefixed styling properties which will be hidden from you if, like me, you use Firebug to investigate and develop style overrides. Take care when overriding styles that you have included all of Bootstrap’s vendor-prefixed properties, not just the ones you can see in Firebug.

Bootstrap applies a significant amount of styling to generic HTML tags such as tables and lists. This unnecessarily increases the amount of style overrides required. The good news is that the Bootstrap development team have realised that this isn’t a great idea and are revisiting it in V2. Hopefully, in the future they’ll stick to style classes so that styling can be more targeted.

 

Would we use Bootstrap again?

Yes, we would. Overall the time saved during early development significantly outweighed the time spent overriding the Bootstrap default styles later on, as we began to apply brand-specific styling.

 

Is there anything I’d do differently next time round?

Not really. Each new project brings its own needs and challenges. If we can build rapidly and test the user experience early we will always end up with a better product.

Follow the conversation around Bootstrap on Twitter.