Strapless
On Friday, Kelly and I were having a conversation over lunch about the ubiquity of Bootstrap. It’s a topic we’ve been kvetching about for the the last few years—we’ve grown tired of seeing the same site everywhere we look.
It’s not that we have any issues with Bootstrap specifically. It’s a solid framework for rapidly prototyping an idea before deciding if it’s got legs. It’s also a great tool to learn from when considering your own pattern library. That said, we don’t think it should be used in the way it so often is: as the entirety of your front end design with only a teensiest amount of theming applied.
The reasons we aren’t big Bootstrap fans are manifold. Steve Fisher, Yesenia Perez-Cruz, Samantha Warren and I hashed out a bunch of them in our SXSW panel “The Real Responsive Process?”. Here are a few of the highlights:
- Bootstrap doesn’t solve your problems. Design is problem solving. The design decisions made by the creators/maintainers of Bootstrap solve their problems, not yours. You may share some of those problems—a need for responsive layouts, for example—but not others. You need a system that is tailored to solve your problems and only you (and your team) know what those problems are. Have you ever tried on an article of clothing that’s “one size fits all”? How well did it fit your body type? Unless you are absolutely average in all respects, probably not all that well. Solve your problems with your own Bootstrap-esque pattern library.
- Bootstrap offers more than you’ll need. Bootstrap contains a lot of components and design patterns. It was created to address a wide array of project needs (“one size fits all”, see above). As such, there’s a lot of code in there. The defaults with some basic theming put you at a minimum of around 200KB for the CSS, JavaScript, and fonts (and that doesn’t include jQuery, which is also required). Customizing your Bootstrap build can help, but if you’re gonna use Bootstrap in production, you need to ruthlessly rip out anything you aren’t using. That takes time. And then you need to maintain your customized version of Bootstrap, making upgrading to new versions of the framework painful.
- Differentiating yourself from you competition is harder. Bootstrap sites have a very common look to them. You can easily pick them out of a lineup and they are especially prolific within the startup space. If you’re trying to separate your company from the pack, having a site that looks just like every other startup (including your competition) is probably not a great idea. Spend some time (and, yes, money) creating a design that matches your brand and reflects who you are.
I’m not saying these things because I’m a Bootstrap hater. I’m not, I just think it’s a crutch for a lot of people and it’s led to an era of bland, look-alike design on the web I’d love to see us transcend.
In my conversation with Kelly, I jokingly said it would be funny to create a browser extension that removed Bootstrap’s CSS and JavaScript from any page that included it. Something subversive along the lines of Eric Meyer’s hilariously destructive table layout and font demolishing user stylesheet or Richard Harrington’s “disrupt” to “bullshit” converter. On Friday I decided to see what I could throw together in 15 minutes and I dubbed the result “Strapless”. Using Crossrider, I converted some simple JavaScript into an extension for Chrome (no longer available) and Firefox (no longer available). I didn’t bother with Safari as I couldn’t justify spending $99 to add a prank extension to their catalog. I have a version for Internet Explorer, but the installer is failing, which I suspect is an issue with Crossrider.
Enjoy!
Comments
Note: These are comments exported from my old blog. Going forward, replies to my posts are only possible via webmentions.Mike
hehe, great! Just today had a discussion with a new co-worker who wants to use it (we currently don't). I think like with all frameworks you keep running at walls sooner or later. Happened with Foundation which we used for a few projects some years ago, Bootstrap would be the same I reckon. Maybe it is my old age but I still like to write vanilla CSS and even JS (although still relying on jQuery for most projects but for some not even that anymore). Not saying I start from scratch and have my tried and tested "starter kit" stuff but nothing like a "framework".
I think we all end up with a set of patterns we use repeatedly on project after project. It doesn’t make sense to reinvent the wheel if the wheel is what you need. But if what you need is a frisbee and you look at the wheel and say “well, they’re both round”, you’re probably gonna hurt a small child :-)
#2 is solvable with an intelligent build pipeline and is a problem with pretty much anything that has a year or two under the belt because frontend code rots too easily. I don't think #3 is a problem unless you're **designing** of bootstrap. We still get a lot of benefits from common patterns even when we don't use common widgets as much.
The main reason (#4) why we will at some point stop using bootstrap as heavily we have in the past is that it's pretty awkward to use with components. The awkwardness will get even larger once CSS modules becomes more common place.
Completely agree on #2, though you’d be surprised how many sites just include it all. In terms of #3, in my experience, one of the most common uses is to throw together a site using Bootstrap as the foundation for the design (or the entire design in most cases). The "designer" might apply some colors using the themer, but that’s usually about it. And yes, I agree on extensibility.
use basscss and be happy
Never heard of it. Looks simple enough. Or you could just roll your own :-)
The extra point to make is that, if you're intending to do anything other than light theming, Bootstrap quickly becomes a confusing hindrance. Like many frameworks, Bootstrap makes common idioms easier, but ends up making anything more ambitious more difficult. Extending Bootstrap components is extremely confusing.
Amen to that. It’s true of any system or framework or programming language. Great ones are malleable, but all have a perspective. Some are more rigid than others. Rigidity can be a godsend in certain situations, but if you need to do something that doesn’t fit with the system, you’re gonna fight it every step of the way. In times like those, it’s sometimes best to look for a system that can do what you want rather than frustrating yourself by trying to force the one you’re using to do something it wasn’t designed to.
Good points, and I agree with the essence of the argument ... and yet this conversation pre-dates Bootstrap and I still don't feel there's a good answer to the tooling and upkeep question: http://phillipadsmith.com/2...
Or put another way, how can smaller publishers be expected to meet the needs of their users -- across a dizzying array of devices -- when using their own custom-built CSS/JS framework?
Using the jQuery argument: by using jQuery, those publishers get the benefits of the whole jQuery open-source community's efforts to make the library fast, small, and widely compatible.
How will they reach that speed, depth of compatibility, or future proofing if they roll their own?
Three cents.
I wrote some thoughts about this very thing in “The Bootstrap Trap” http://johnpolacek.com/2013...
At the time (2 years ago) it was pretty controversial, but it seems like more and more people are coming around to this way of thinking about front end frameworks.
All fine, heard this argument before, nothing new here.
So tell me, what is your alternative? A practical alternative, that is. What do you recommend apart from writing the whole thing from scratch?
That would make for far more interesting reading than "Bootstrap makes everything look the same if you don't customize it". Yeah, I knew that already.
Since when is “writing the whole thing from scratch” not a practical alternative? We’ve been doing it for decades and it’s the approach I’ve personally used on every project I’ve ever done—dozens upon dozens of sites, big and small. It’s really not a big deal.
Decades ago websites were simple, no need for responsive or whatever. Stuff is getting more complicated every day. Yes I also don't like the size of Bootstrap and its uniform look. Okay fine, give me alternatives then, more lightweight frameworks which are easier to customize (yeah they exist). Reinventing the wheel and writing everything from scratch every time doesn't make sense and is a waste of time and money especially for the smaller company or solo dev.
With a “team” of one (that’s me), I put together a fully-responsive framework, pattern library, and 35 representative screens using it for a major client—you’ve heard of them, but I can’t name them—in about three weeks, spending about 4-5 hours a day, five days a week on it. It used a lot of advanced HTML5 stuff, included JavaScript validation, and had a bunch of other “hi fi” features. Two of us later tested it against 1,400 different devices and, with a few tweaks here and there for older devices like Blackberry 4 and Openwave, we were good to go. It’s not hard to build from scratch, even as a solo person.
For prototyping, internal tools, and the like I have no problems with cutting corners and saving time by going with Bootstrap, but when building a public-facing site, I think a custom pattern library is worth the investment.
I’m also not saying that you shouldn’t re-use code. Go for it. I do it all the time. Heck, take some of the bits you like from Bootstrap. Take others from jQuery. As long as the license allows it, go nuts! But use those as part of your unique design that is tailored to brand and (more importantly) the project’s needs.
Fair enough, point taken, I do believe it's feasible to assemble your own solution if you have some time and skills and use a few good tools like Sass, Compass or Bourbon/Neat, a CSS reset and a responsive grid system. It's more that people lack the knowledge to do so.
:-)
What about migrations, from Bootstrap 2 to 3 to 4? I assume that could be pretty painful. And grids! Sometimes, you need floats, other times, inline-block, or flexbox. There's seldom a one-size fits all grid, or even approach. Every project has different needs and solutions.
For a mid-large sized project, a styleguide (preferably living and linking to production CSS) will solve most issues and help maintenance in the long run. Many of us may also have boilerplate that evolves with each project we work on.
I personally avoid Bootstrap because I find it gets in the way and the overriding is counter-intuitive, beyond a point. But then again, I love working with CSS and know many folks really don't. Having said that, I know many people who find Bootstrap indispensable to their workflow.I've used bootstrap/foundation/similar frameworks and the topic of this article was my initial thought when working with all of them. "Dam there's alot here I dont need", "I mean it sorta solves my problems, but I'm overriding much of the default styles". It ended up being that i spent more time tweaking bootstrap than actually working. I switch to PostCSS and Gulp and use them as a tool to make my own little system. I work faster and get solve all my problems without having to deal with any of the extra stuff that comes with bootstrap.
We ran into this problem and wrote about it here: https://infinum.co/the-caps...
Our old website was in bootstrap, and over time turned out to be a problem. For custom websites, the only aspect of bootstrap that works is the grid system. Everything else is usually, well, custom.
Bootstrap is still a solid solution for:
- prototypes - where it's more important what the thing actually does, and to get it out fast
- an administrative interface for your backend, where it's not so important to be unique and utility is keyso how do you feel about Polymer and Google's idea to make all websites look the same? https://elements.polymer-pr...
{{ mention.author.name }}
Webmentions
Problems of using Bootstrap in your app:
aaron-gustafson.com/notebook/strap…
Likes
Shares