Web Platform

Bootstrapped up with nowhere to go

or: How I Learned to Stop Using Twitter Bootstrap and Love LESS

Octane (our product) has been around for a while – we’ve watched the trends in UI design, frameworks, and developer mindshare changing along the way. We’ve been from jQuery to YUI back to jQuery, with a brief consideration of Dojo along the way. At this point our codebase is mostly custom css and mostly custom javascript widgets, with some great third party libraries where they  met our standards and fit our needs exactly. I remember when Bootstrap first came out – it was fresh, and had a lot of good ideas. We were doing some new development work at the time in a separate part of the app – something which would be more public facing and could use a bit of a fresh start with new choices. We took a leap of faith on Bootstrap and followed it through 2.0, investing in LESS and integrating it into our build.

Recently, we’ve started a pretty large UI overhaul, with fresh design work, heading in a slightly new direction, we were going to try to build something more cohesive across our projects. It was a flat design, going along with the trends, and we found the Flat UI theme built on bootstrap which matched a lot of our design. It seemed like a clear win.

When work began, I devoted some time to getting up to speed on what the current best practices were in the CSS world. I knew we had built up some cruft, and I wanted to clean it up along the way. I found OOCSS and SMACSS and decided to give it a deeper look. I watched some presentations and read the SMACSS book, and it all clicked pretty well. Many of the ideas I was familiar with, such as the technique of using multiple classes to refine styles, but I hadn’t really gone through the level of structural rigor that OOCSS and SMACSS prescribe. It made sense to me, though, so I wanted to use it during our overhaul in conjunction with Bootstrap, which didn’t seem to conflict too much…

Well, long story short, after really digging in and trying to make it all work – to make the app work the way I needed it to, and look the way I needed it to – I found that the number of overrides I was making became much more than the value proposition of Bootstrap to begin with. Combined with the Flat UI theme, I was writing overrides of overrides. I had two sets of variables and mixins, plus my own. I was dropping entire chunks of functionality like grids and forms because they were doing more harm than good. In the end, I ultimately used some code from Bootstrap and the Flat UI theme, but I condensed it all without overrides, and really just used it as a scaffolding for the final design.

So what’s the conclusion here? Should people avoid Bootstrap? Would I do it over again differently? This is my final takeaway:

  • I’m glad Bootstrap got me into using LESS (judiciously).
  • Bootstrap helped me figure out a good way of organizing my LESS files.
  • Bootstrap has some good ideas about breaking down some of the fundamental components of a page and figuring out what those pieces are. What the vocabulary is. A lot of that I kept even if the css, classnames, and even html changed.
  • I’m a snob and I think the dropdown and tooltip widgets (the only two I even tried using) are kind of crap. They work fine in prototyping, but have fundamental flaws.
  • Bootstrap makes tradeoffs to have nicer looking html. We take a different approach to get nice view code, and don’t need to make those tradeoffs.
  • Finally, I realize that not all apps or websites are like Octane. Other people may have no time or talent for design or implementation of custom CSS, in which case, Bootstrap is a pretty good foundation. It also works pretty well for just prototyping or scaffolding.

Before I made the final decision to remove our dependency on Bootstrap, I looked around to see what others were saying. There’s a lot of praise for Bootstrap out there. Given that my ideals had shifted to OOCSS/SMACSS, I was curious about that intersection. I got my answer here. To pull some choice quotes:

“Yeah, my initial impression has been that design is too tightly coupled to structure. You can’t easily reskin w out ripping out or overwriting their styles.”

That was from Nicole Sullivan, creator of OOCSS and well respected authority of good CSS.

“I’ve used it for 3 projects now. At first I loved it, but now I think that I live only a few aspects of it – the mixins, icons and buttons.

It is an amazing project, but I actually prefer the lightness of the OOCSS framework.

While you can customize things in bootstrap, you ant take it too far before things start to break.

In the end, what it’s taught me about LESS is what I appreciate the most. I’m building a LOOCSS project :-p”

That was from another person in the thread, and it really echoed my own experience.

I’ve got more thoughts and experiences on OOCSS and SMACSS, and where we’re going with it, but I’ll just leave that for another post.

Web Platform

You’ve got to think for yourselves.

You are all individuals.

I hate when technical debates turn into religious wars. Today’s war on tap? Progressive enhancement.

For anyone who hasn’t heard the ruckus, here’s a quick summary:

  • Progressive Enhancement (PE) became a term in 2003 and by 2008 became a best practice. It was a mantra chanted repeatedly, the same way CSS over tables was pounded into the minds of every web developer. Here’s a nice history/overview.
  • Within the past couple of years, as browsers have gotten better, single-page applications have gained a lot of traction, completely abandoning the page request model and rendering all html client-side.
  • Many proponents of PE, noticing the trend, have written/presented about why it is still important.
  • On August 27th 2013, a tumblr called Sigh, JavaScript was launched “reminding” people that PE is still important by posting images of sites that don’t work without JavaScript.
  • On September 2, 2013, Tom Dale (from ember.js) posted an article declaring PE “dead”. Despite the article’s controversial and hyperbolic title, it was (IMHO) actually fairly balanced and well reasoned throughout.
  • Chaos ensued on twitter and the rest of the web.

There have been some other summary posts trying to provide their own insight. Here’s mine:

I think the information presented by both sides is far more valuable than the conclusions they reach. They both have compelling arguments, and they both have good examples to support their case, but as I hope we’ve all learned time and again, you should never use dogma in place of actual thought. If you look at the data and arguments presented, I think you can actually come away with valuable guidelines when making decisions, but despite opposing conclusions, I think the guidelines compliment each other well as long as you keep context in mind.

If you have content that you want deep linkable, especially something as small as a tweet, you damn well better be able to load the page fast. What is the fastest way to do that? Serving the html for initial page load is pretty damn good at it. This is probably not just tweets, but news articles, blogs, recipes, etc. However, even if you go that route, remember that you’re making an argument from a position of efficiency/good user experience. And guess what, there’s a million other things that go along with that. What are you doing about ads? What about number of http requests, etc. Serving html and enhancing is just one tool in the arsenal for faster web apps. I will also go out on a limb and say that it’s not really the original point of PE.

The efficiency argument has another flaw I haven’t seen get much attention too – if you’re going to delay rendering until after JavaScript runs to prevent the dreaded FOUC, then in terms of efficiency, the argument is basically dead right there, at least for the cases where the progressive enhancement actually has to update the DOM before rendering. In both cases the browser has to wait until all of the JavaScript is loaded and executed before rendering anything. Sure it will work without JS turned on, but that is a different argument than the efficiency one.

So what about the other argument for PE? What about no JavaScript? PE started as a movement because of the potential lack of JavaScript by the client – which (as they always push home) also means google! This was the PE argument that Tom Dale was mostly railing against in his post. He posits that the userbase with JavaScript turned on is high enough that if you want to use 100% JavaScript, that’s ok, especially if you don’t care about google. I found his argument logical and sound. The web platform has grown up a little. JavaScript can be expected for a wide enough audience, that you can now make the case for ignoring the few with it turned off. It may not be for everyone, but it is an extremely valid choice – one which can be made more often. It is the choice that we made for Octane.

The way I see it, one of the most powerful features of the web platform is how flexible it is. Some kind of html rendering is available on almost every electronic device or platform with a screen. That is a virtue of the web, not a contract. The logic that all software available online has to be usable from all possible devices is clearly false. Not all software is made to work that way, and not all software that can be made to work that way is. So where is the line? And what exactly is the boogie man we are attempting to fight off with PE that it should be “ingrained in the DNA of anyone who works on the web“. Is it a morality argument or simply a business one? As “Sigh, JavaScript” demonstrates (unintentionally), there are clearly many successful businesses with websites that don’t work without JS. As for morality, with the exception of resources such as government websites, I have trouble finding the moral argument.

Is PE dead? No. Is it necessary for all projects that can do it? No. In some projects, is it a requirement? Yes. For the rest, it is an optimizaion. It is like choosing to create a native app for blackberry or windows 8. It is a competitive advantage to be able to reach users in more places. In some cases, it could be hugely important to some of your users. Ultimately, though, the goal is to make the best product you can, and you will always have to make hard choices about the best way to do that. It will always be a balance. Add a new feature or make the product faster? Fix a bug or improve documentation? Improve the UI or support IE7? These aren’t dichotomies, they are priorities. The amazing thing about the web is that with enough time, you might be able to do it all, but how you get there is up to you.