I don’t remember how or when I first encountered Bootstrap, but I do remember a late night in 2012 during which I ripped all the Blueprint CSS out of my company's product and replaced it with Bootstrap. The company was an early-stage startup, the product was a SaaS application, and Boostrap was a completely new thing. The next morning at standup I took some extra time and walked my team through what I had done. I got applause. Literally. People clapped. That was a first for me.
Needless to say, in 2021 the applause has died down when it comes to choosing Bootstrap. The introduction of Bootstrap for early product development must now be accompanied by a thoughtful argument. Many developers (especially the kind that join early-stage startups) now regard Bootstrap as the Toyota Camry of front end frameworks, and jQuery as the dead-dinosaur-fueled combustion engine under the hood. I am here to tell you that this battle-hardened framework makes more sense now than it ever has for early product development.
BLOAT seems to be the major category of concern. Doesn’t Bootstrap have performance issues? What about all those verbose, extraneous class names?
The concern is justified, but there are some very particular things you need when building the first iterations of a web UI that Bootstrap is particularly well suited for.
Bootstrap is available on-demand, usable in seconds, and there is no faster way to get a web app UI up and running with a complete, documented design system.
As Kevin Gilpin, founder of multiple successful startups points out in this post in the early-stage startup game ‘speed’ is measured in how quickly, and cost-effectively you achieve goals. When it comes to building web UI this translates to getting the UI live and iterating on layout, control selection, and user flow until you have something people want to use.
If you are successful at shipping product, providing value, and retaining users, there may be a point when shaving milliseconds off your load time matters. It won’t be on day one, and if you are doing it right, the thing straining your app’s performance is directly related to your core innovation, not serving commodity UI.
Bootstrap controls are well documented, both in their official documentation and across the various support communities. This is a benefit that scales out to every member of your extended development team and enables the UI implementation to scale.
As soon as your app has two developers working on it, or two similar but different views, or two modes, or two of anything really, you need a system for maintaining consistency across the visual and interaction design.
Creating and maintaining reference implementations for UI controls is extraordinarily expensive in terms of developer time, and easily falls out of step with product direction. Having those resources pre-baked frees up developers and designers to focus on higher-order problems and keeps the UI development process agile.
Corollary: If it’s not in the Bootstrap docs, reconsider your control selection.
Good CSS class naming conventions are logical, intuitive, concise, maintainable, accurate, and have decipherable relationships to other class names. But their MOST important quality is making the object they describe look and act as intended. Being DRY is not high on the list of concerns, especially during the rapid prototyping and early product development cycles. This can make developers that do not live on the front end bristle when they see things like...
class=”btn btn-primary btn-lg”
In the back of their mind, they know there are ways to identify and scope elements that do not require this naive style of tagging and inheritance.
The ugly truth is that about one minute after the need to write CSS arises, the need for a class naming convention arises. About five minutes after that the decision gets made that adding a few extra characters is a small price to pay to get an object to look and act the way you want it to. It is a very short drive from there to a place where
btn btn-primary btn-lg looks downright tiny.
No, not yet. Bootstrap is a mature platform with wide adoption. It is a part of many applications running in production. As you can probably tell, I find it to be ideally suited for 0-1 front-end development for web applications.
There is a practical derivation of this question, however, which is "Should Bootstrap be on my resume?" The short answer to that is “no.” Bootstrap experience doesn’t belong on a resume and it never has. It’s like putting "Google Docs skillz" instead of "copywriting." CSS is the line item you want.
Okay, I’m cutting myself off here...
I guess I had a lot to say about Bootstrap. More than I thought. Comment below or hit me up on Twitter if you want keep going. I could easily do a part two.