We have a new product we’re apparently looking to spin off here at work, and as part of that conversation, someone threw out the words “Twitter Bootstrap“. For those of you not familiar with Bootstrap, it’s a predefined set of (both stylistic and javascript) visual components and layout scaffolding that makes it fairly quick and easy to prototype websites, and is pretty snazzy in appearance to my developer’s eye, though you might hear differently from designers. They can be a fairly opinionated bunch 😀

So, we have our own internal boilerplate scaffolding that has been designed and engineered in-house, to provide us with a consistent, approved stylistic language we can use when putting together our current product suite. We don’t have any intention of changing the stylistic language itself, but at some point, people started wondering if it would be easier to incorporate Bootstrap as a base layer for us to build upon. That way, we would automatically inherit this base set of visual components and widgets, and from there, we could override whatever we need to override in order to adhere to our own approved style guidelines, and anything that didn’t have a specific definition as part of those style guidelines could simply fall through to the Bootstrap default, thereby giving our designers and front-end engineers a more robust layout boilerplate to work from.

This all seems well and good in theory, though my initial concern was for the added bloat of having an entire base layer of CSS rules that we would then be adding another layer on top of in order to apply our own styles, and the potential overhead on the browser of both the file size and the rendering engine having to do extra lifting for what could end up being a large number of unused rules. This becomes particularly important when you factor in things like mobile devices, which we’re increasingly seeing a need to provide product interfaces for, but after spending nearly 3 hours debating the subject the other day, I think the alternative could end up being a lot more of a maintenance nightmare.

The alternative suggestion (from me) was that we examine the differences between the 2 offerings (our own internal scaffolding product, and Bootstrap), and figure out which features, components, etc. they provide that we don’t, and then do a more surgical implementation alongside our existing offering. This would have the benefit of maintaining the existing markup semantics that our products are currently expected to conform to, while still allowing us to consume Bootstrap components and layout philosophies. The onus would be on the Platform team to revisit Bootstrap with each release, figure out the new additions and modifications, and then augment our own internal offering to reflect those, all the while maintaining consistent markup semantics for our own consumers.

If we make the move to Bootstrap, it will mean that our internal boilerplate layout will need to be modified by the Platform team to conform to Bootstrap’s markup semantics, as well as all of the jQuery UI widgets we currently publish (most of which have no equivalent under Bootstrap’s Javascript components), and in addition, each of our product teams will then need to take some time to convert the markup semantics of their individual products over to conform to Bootstrap. However, after the initial pain of that conversion process, we get new updates from the Bootstrap community very cheaply, by simply replacing our base layer and making sure our overrides still look as they should.

So the conversation now becomes “Which of these pain points are the lesser of the 2?”. Do we, as the Platform team, take on the responsibility of surgically implementing Bootstrap concepts and leave the products with a consistent interface to implement our internal scaffolding? It would centralize and shrink the number of people affected, but would be a recurring maintenance task with every new Bootstrap release. Or, do we bite the bullet and have all of the products convert their markup to Bootstrap’s semantic structure, and once that’s done, minimize the pain of future Bootstrap upgrades? It would mean the added overhead of the Bootstrap library, and the affected pool of people and products would be much larger during the initial conversion process, but probably more short-lived in the long run.

I can see pros and cons to both approaches. Has anybody out there made this move at their own companies in recent history and have praise and/or regrets about the path they took? Can anybody think of any options we haven’t considered yet? If so, please feel free to drop me a note in the comments section 🙂