Twitter Bootstrap and the rise of total front-end frameworks

Originally Published On AppFog

August 4, 2013

Share +

It’s no secret that there’s lots and lots going on in back-end web development these days. As an example, debates surrounding node and asynchronicity, to give just one example, have reached a fever pitch and have occasionally felt more like philosophical arguments than technical arguments.

The same has been true for debates between “thick” frameworks like Rails and Django versus “thin” frameworks like Sinatra, Flask, and Express. On top of these issues, we’re also witnessing an explosion of creativity in the world of full-stack frameworks (Padrino for Sinatra, Tower.js for node, etc.). (More on this very soon, so be sure to hit a subscribe link on the right)

But what has surprised me recently is that similar developments are afoot in the world of front-end development. The shining example par excellence: Twitter Bootstrap.

Bootstrap was essentially a big, juicy bone thrown to the web development community by Mark Otto and the folks in the design department at Twitter. The purpose is to allow third-party developers to easily lend some much-needed aesthetic consistency to the world of Twitter-related web apps, which now number in the hundreds of thousands (see this article by Drew Heatley, which gives a figure of a million, which I didn’t believe until I found out that Twitter agrees).

For many developers, front-end development can be a somewhat haphazard affair, a mixture of HTML, CSS, and JavaScript built from scratch. Sure, for many projects, this works just fine. But when your app begins to become hyper-multifaceted, stretching across dozens (if not hundreds or even thousands) of views, tables, div elements, etc., then the idea of piggy-backing on a total design framework built by someone else starts to be appealing. This is especially true considering that Bootstrap comes with all kinds of specifications for event-driven JavaScript (like mouse clicks, hovers, and things of that sort, things that can surely end up being a real bear).

So, up until a few days ago, it was difficult for me to understand why so many CSS generators have emerged over the last few years. I had done some basic design-related things with CSS and found that to be one of the simpler things in learning development. I thought: why spend time learning these generators? Why not just write your own native CSS?

I aired my question to the Twitter universe and got a response from my distinguished colleague Joe Moon saying that I needed to bear in mind that some projects involve dozens of people working just on the front end alone.

That’s when the purpose behind things like Bootstrap really became clear to me: the goal is to tie together all the loose strands of front-end development into the same kind of centralized logic that you would insist upon having in the back end.

You wouldn’t want your back end to be a loose amalgamation of data models, database connectivity, and REST architecture, right? You want the whole thing to be airtight, especially in an era when poor aesthetic presentation––not to mention discrepancies in how sites appear across browsers and devices––can absolutely stifle a site’s chances of success.

Generators like SASS and LESS (which Bootstrap uses) enable you to do things like using variable names to lend consistency and transparency to CSS. Example: If I’m using a particular shade of blue (say, hex code #37C5E5) throughout my app, I can label it @blue at the beginning of my SASS file and then call up that color again and again.

The benefit of this is clear: if a whole team of developers is using and modifying the same stylesheet, then #37C5E5 can be terribly unwieldy (unless, of course, said developers have an uncanny ability to decipher hex color codes!). On the other hand, it’s immediately clear what is meant by @blue, and this could mean avoiding unnecessary headaches in large projects.

Bootstrap is essentially the embodiment this principle of transparency writ large, and extended beyond stylesheets into all of the elements that dictate sites’ appearance to the end user.

The one potential drawback to Bootstrap that I can imagine is that some might be irked by the drive to uniformity that drove its creation. Just look at Pinterest (there’s even a Tumblr account devoted to sites built using Bootstrap). The creeping Bootstrapification (my neologism for the day) of large swathes of the internet is a very real possibility, if not an already-present reality.

But you know what, who cares? Bootstrap is aesthetically sleek and fairly easy to use for something that packs as much punch as it does.

Plus, competitors to Bootstrap have already begun to emerge, which should apply a brake to the Bootstrapification of web design. Zurb Foundation, for example, offers an equally comprehensive design logic, and one can only expect that there is much, much more on the way.

In the end, from my perspective, frameworks like Bootstrap are a highly preferable alternative to (a) sites that look bad and/or lack coherent design logic, and to (b) sites that look good and have a coherent design logic but took hundreds of unnecessary man hours to build.