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.
Incredibly low activation energy, Incredibly high speed of iteration
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.
Complete and accessible documentation that anyone can understand
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.
Redundancy in the naming of classes is a quality of CSS not Bootstrap
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.
Hasn’t the world moved on from Bootstrap?
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.
Top comments (12)
Bootstrap, like Rails and Java, is unfashionable but battle-hardened.
Allow me an anecdote. In the early 00s, I was a software dev in Boston. The housing market was HOT. Software developers were buying run down houses, writing code all day, and then trying to renovate their lemon houses at night, in hopes of flipping them for big $$$$. How did that work out? They spent a year living with leaky ceilings and asbestos dust, then hiring contractors to finish the job as their girlfriends walked out the door.
What’s the point? You can’t do it all. Figure out where you will innovate, and use the boring, obvious choice for everything else.
Viva Rails, viva Bootstrap, viva SQL, viva Toyota Camry. Viva Stuff That Works.
Indeed! These choices appear difficult at first but one or two steps in often bring the realization that you don't actually want to do it all. Save that valuable time. Make a habit of force concentration. Viva Stuff That Works! (this might be a sticker)
Always, but with the caveat that you shouldn't back yourself in a corner. As "Pragmatic" Dave says, when faced with a choice, use the one that's easier to change later on.
Bootstrap is a no brainer. It's easy to get it up and running, it works, but it's also easy to migrate away from should you need to.
Any monolithic framework isn't. As it encompasses a number of backend + frontend functionalities, Rails isn't easy to migrate away from, particularly with the over reliance on gems that may (or may not) become unsupported as time goes by.
Get it up and running without reinventing the wheel is critical in those first steps towards an MVP, but later on every project will confront the demons it created, usually in terms of security and maintainability.
To your point about Bootstrap being easy to migrate away from -- it certainly is. My team encourages people who feel so motivated to write Bootstrap out if they can provide a better way, with a reference implementation in the code and solid docs in a
styles.mdfile that travels with the repo. At this point, the biggest thing we have replaced is the layout system. We use a purpose-built modification offlexboxfor page layout.This is a beautiful comment. Also, 👋 from MA.
I'm using Bootstrap on my new projects. I'll let everyone else chase the shiny new thing
Tailwind is good stuff!
Nice one. Good luck getting it off the ground 🚀
Bootstrap is a blessing and there are a lot of great themes built around its almost de facto standard syntax.
The only thing that made me start using tailwind instead, is that you can tell that a website is using bootstrap easily, unless you put enough energy and time to customize it.
There are definitely limitations to what it does out of the box, but hunt around, people have addressed just about every conceivable use case on Stack Overflow and elsewhere. Good luck!