The Bootstrap Trap

The promise of Bootstrap is so appealing. A quick, easy way to get a web project up and running that just works, and works well.

It is a promise that comes with a trap.

If you’re trying to use a front end framework to offload all the brain-hurting, detail-obsessing, bug-crushing, browser-wrangling mental gymnastics of modern web development, then you are falling into the trap.

What happens when you build your website in Bootstrap 2.0, then Bootstrap 3.0 comes out? What happens when you have bugs? Is it a Bootstrap bug or your own implementation? Maybe it doesn’t work quite the way you need. How much of Bootstrap is a blackbox to you?

If you know your Front End Framework of Choice like the back of your hand, then maybe you’ve avoided the trap. Even so, I bet there are things about it you’d like to change.

Am I suggesting you or your team should consider rolling your own framework for every project? Yes, I’m absolutely suggesting that.

Maybe this sounds like a lot of work. It should also sound like a lot of fun. Just like there is no crying in baseball, there is no lazy in web development.

If you had to hire a great chef, would you hire one who knows how to heat up food, or one who makes all their dishes from scratch? If you want to prepare the best recipes, you need to understand the ingredients.

Dig in and cook up your own flavor of gourmet web deliciousness, but do so by standing on the shoulders of giants. Projects like Bootstrap and Foundation represent thousands and thousands of dev hours. They offer a free peek inside the minds of the best web teams in the world. The work they are doing is incredibly valuable!

Study frameworks. Pick the source code apart and figure out what you like. When starting a new project, always take a fresh look at what’s new on the front end scene.

Re-use from your past. Borrow from the new. Mix them together. Use tools to be efficient. Invent when inspiration strikes. Construct it all together in a way that makes exact sense for that particular project.

Research. Build. Learn. Repeat.

17 thoughts on “The Bootstrap Trap

    • My advice would be for the team to build from the ground up. Writing documentation is part of it. Think about how much better the team will understand code they have written themselves, specifically for the project they are on.

      • The team has turnover and different backgrounds.

        By starting with an off the shelf lib, they have external community support and docs.

        Starting from scratch blocks project, team, learning, etc. and creates waste of things community already figured out. Good luck to you.

        • Sounds like we will be disagreeing on this one, but I do love talking about this stuff.

          You have a valid point of view. Using one of these big frameworks gives your team a shared style and approach right out of the box, and is a nice onboarding shortcut. My point is that this comes at a cost.

          Lets say you started building your web project a year ago, when Bootstrap was on 2.1.1. Since then, it has gone through 4 releases and is now on 3.0. Is your team upgrading Bootstrap along the way? What if 3.0 went in a direction you didn’t like? Are you comfortable tying the fate of your project or business to something out of your team’s control?

          Does Bootstrap do everything you need? How much customization did you need to do?

          Eventually, you wind up in the same spot, where you have a custom build, but instead of a build based on the spec of your project, you are inheriting some amount of code that you do not need and will never use. Why not take the best of what you see in these frameworks, and build something fitted to what you are doing?

          It may be that the benefits of Bootstrap outweigh the concerns I’ve mentioned. Definitely room for debate.

          Personally though, I think if you have the right team with the right team leads, you can build a system that works just as well as any framework, is well documented, tailored exactly to the project, thoroughly understood, easier to maintain and, best of all, a big source of pride and learning for the devs who built it.

  1. > Maybe this sounds like a lot of work. It should also sound like a lot of fun. Just like there is no crying in baseball, there is no lazy in web development.

    Ah the dreaded appeal-to-baseball-analogies fallacy, my only weakness!

    > If you had to hire a great chef, would you hire one who knows how to heat up food, or one who makes all their dishes from scratch? If you want to prepare the best recipes, you need to understand the ingredients.

    Literally this exact argument with some words replaced can be used to argue that you should build your own backend framework for every project. (Go do a few code reviews for PHP projects, and tell me if this is a good idea.)

    Or that you should write your own DBMS instead of using Postgres.

    Or that you should use x86 assembly for everything.

    What’s that? You’re telling me that Bootstrap lets you minimize the amount of time you spend writing boilerplate, and debugging why an element just won’t fucking stay floated in IE8, and writing/downloading dropdown-menu elements? And that this allows you to greatly increase your productivity and spend time working on stuff you and your customers care about, instead of bullshit CSS issues?

    But but but cooking analogy!!

    • I’m all for Backend frameworks and JavaScript MVC Frameworks (for the right-sized project). CSS frameworks are different though.

      Not saying you shouldn’t use pieces of Bootstrap, or plugins, or code snippets you find elsewhere. I think it is better to get more granular when building out a site, and pick just the things you need. If a particular front end project suits your project really well, and you are a Bootstrap maestro, then it probably makes sense to use it.

      I just think people need to give it a little more thought. The issues you talk about Bootstrap avoiding, you are going to run into anyway. Devs need to know how that particular dropdown menu works and why elements aren’t floating, and not outsource all that knowledge to a framework. If you know all that stuff, then great.

      I worry though that some devs are missing out. We all have to start somewhere. Using Bootstrap to get a foundation is one approach, but the sooner devs can dive in deeper the better. We all have to deal with bullshit CSS issues, no matter what. Learn to love it! haha

    • You’re actually wrong here. The equivalent analogy to that comparison would be “THE CHEF HAS TO GROW HIS OWN WHEAT AND MAKE HIS OWN FLOUR.”

      Bootstrap and the like are toxic. They’re for lazy front end developers who don’t want to do the job.

      However, if you don’t have a front-end dev on your team, feel free to use one of these for prototyping, but make sure you hire a front-end dev who can write a style layer before you ship a real product.

  2. > What happens when you build your website in Bootstrap 2.0, then Bootsrap 3.0 comes out?

    Bootstrap 2.0 remains usable and perfectly fine for the existing site?

    > Is it a Bootstrap bug or your own implementation?

    Chances are it’s mine.

    > How much of Bootstrap is a blackbox to you?

    None, given that I have its source code and Firebug/Webkit Inspector.

    > Am I suggesting you or your team should roll your own framework for every project? Yes, I’m absolutely suggesting that.

    Says the guy using **both** Prototype.js and jQuery for his blog, not to mention WordPress itself.

    • I knew somebody would bust me on that, haha. There are more interesting things to work on than a blog, so I just used the default wordpress theme and made a couple tweaks. See what happens when you get lazy and just use a framework? If I would have rolled my own, it would have been better. ;)

      > Am I suggesting you or your team should roll your own framework for every project?

      I think I overstated it with this line. I should add the word ‘consider’.

      • > See what happens when you get lazy and just use a framework?

        A perfectly acceptable blog? As with blogs, there are usually more interesting things to work on than a framework.

  3. You’re getting ass-blasted, but I have to agree with everyone else. This is a very bad opinion piece.

    • Ass-blasted? Not really. Of course those commenting are the ones who disagree, that’s the nature of blogpost comments. If I had the opposite opinion, to always rely on front end frameworks and never roll your own, there’d be plenty of people who would disagree with that as well.

      And that’s a good thing. I like thinking and talking about this stuff. I am always open to other points of view. If I didn’t want to have people challenge my opinions and make me think harder about them, I wouldn’t have written the post or enabled comments.

  4. I have to agree with you, when we use Bootstrap in a project we are tied to that version (1.x, 2.x). That’s not a problem when we use Bootstrap’s default look, but when we try to extend it, the migration to a new version is a pain in the ass.

    Also, I’ve always thought that creating from scratch is the best and funniest thing, we have complete control over what we are doing and don’t have to deal with workarounds for others’ code. When we know well the options out there, it’s easy to create our own things using and reusing the experience of ourselves and others.

    I love your analogy about the chef. :)

  5. Bit late to the party but whatever. I totally agree with this. I set out trying to use bootstrap to build an enterprise web app; this turned out to be a bad idea. I was having to modify it so much I ended up writing my own CSS from scratch. This turned out to be much better.

    I can see how bootstrap is useful in certain circumstances though.

    • It is funny how when the post first came out, people were pretty harshly critical, but over time more and more people are agreeing. Again, Bootstrap and front end frameworks can be useful, but there is WAY too much hype on them to the point where devs and companies start using them without really appreciating what they are getting into. There is nothing wrong with choosing NOT to use a framework, and many times that is actually the right choice.