Why we use Twitter Bootstrap

Bootstrap is another buzzword just like HTML5CSS3 & Node.js & DHTML (if any of you even remember DHTML) & it undoubtedly has managed to grab the developer community’s attention like no other front end framework by far for various reasons. Now, I will admit that it gets you going in no time, minimizing the developer’s pain (although in a quick & dirty way), but I will not be discussing how great it is. Rather, I wish to constructively criticize it’s usage by the community & why it’s not always wise to use it.

Messy markup

DOM is messy as it is. The worse you could do is bloat it up with truckload of CSS classes by specifying them in the markup. Bootstrap comes with a gigantic list of CSS classes that can be plugged into markup to perform specific actions. Even though they are big help, it can considerably slow down DOM operations when it comes to matching every single class (selector) applied. Looking for every CSS rule up & down the DOM has always proven to be a very expensive operation. Rather than bloating your markup with such classes, it’s always a good idea to write a specific block of styles targeted for doing one thing & one thing only.

Non-supported HTML attributes

Bootstrap uses several nonsupported HTML attributes such as placeholderrequiredaria attributes groupdata attributes group & so on. Support for these newly introduced attributes (except for aria attributes) is surprisingly low & bootstrap takes no responsibility in providing graceful degradation options (at least not that I know of). Aria attributes are widely supported but, when used irresponsibly, they can cause a lot of grief to the accessibility scope of your application/website. Read up on them here. Placeholder attributes are becoming popular among the developer community for the wrong reasons. Optimistically, there are various polyfill scripts lying around to achieve where placeholder fails (Sorry, I will not explain why placeholder is used). Quite honestly, as a framework vendor, bootstrap must provide a fallback support option. Well, all the more reason to avoid bootstrap for JavaScript components.

Javascript components

There are 2 components that I particularly dislike. Tooltip & Modal. Let’s look at Tooltip first. Shortcomings of Tooltip
  • Since CSS3 transitions are still not supported by all browsers, this component shamelessly breaks in IE7/8 & Opera mini.
  • It uses data-attributes for local title storage which IE9+ (Yes IE 10 too!) do not support & yet again, no fallback!
Modal comes with some predefined transitions & luckily they degrade gracefully in older browsers but this component fails to live up to a couple of very common expectations. Lets discuss them. Shortcomings of Modal
  • When launched modal is not always in the center of the browser window vertically as well as horizontally. It is positioned in CSS & left as well as top values are static. Centering it could have easily been handled using minimal JavaScript code. I’d say, using it is a lose-lose situation as it doesn’t satisfy minimum expectations.

A few messy parts worth mentioning

I am thoroughly convinced that Bootstrap is not for me & probably managed to get you onboard with me, even though that’s not really the objective of this article. There’s a couple of clumsy parts of bootstrap that I am not happy about & i.e. foundation CSS bloated with !important rules & LESS adaption over SASS. I’ll go over each in detail.

1. !important should never be used NO MATTER WHAT!

If you have studied CSS specificity, every CSS rule comprises of selectors & has specific value as a whole & in order for me to override it, all I have to do is come up with a stronger rule with bigger value than the existing. It’s no rocket science. If you religiously know specificity inside out, you will never have to use !important rule. Bootstrap foundation CSS is full of such rules & developer ends up writing even more & then it’s all downhill from there as you may have guessed. In my opinion, Bootstrap is not setting a good example among aspiring Front end developers.

2. LESS over SASS

In a preprocessor era, it comes as no surprise that bootstrap uses it too but their choice of Preprocessor is LESS & I might have an idea why. Bootstrap creators are apparently friends with LESS creator & it seemed wise therefore to prefer LESS over SASS regardless of following reasons:

  • LESS development has almost stopped since Alexis has no time to maintain it.
  • Less lacks when it comes to caching .less files.
  • No. of open issues on LESS is far bigger comparatively.
  • SASS uses COMPASS for CSS3 syntax that results in less code unlike LESS
I wish I had more time to elaborate more along the lines of the hurdles bootstrap creates while in troubleshooting phase. Quick fixes during troubleshooting can really turn your application upside down & result in taking unreasonably too long.

Share this post