Recently, I’ve started using GroundworkCSS to implement responsive design on a personal project.  Simply put, it’s been an absolute pleasure to use.  Not only is Groundwork highly flexible, but it also feels remarkably lightweight in comparison to something like Bootstrap.

There’s a few challenges, however.  The Groundwork website has quite a few live demos, but there’s very little text to explain exactly what’s going on.  There’s also not much of a community to glean knowledge from.  While teaching myself how to use the framework, I’ve had to spend a lot of time in the Chrome web inspector reverse-engineering the live examples and then experimenting.

As an example, one of the more difficult pieces when initially working with Groundwork is figuring out how things will stack on top of each other when your layout shrinks. The default behavior is simple, and reasonably intuitive. Elements will be stacked top-to-bottom in the order that they’re declared in markup.  Here’s an example:

<div class='row'>
  <div id="left_thing" class="three fifths"></div>
  <div id="right_thing" class="two fifths"></div>
</div>

When rendered in desktop mode, the ‘left_thing’ will show up on the left and take up three fifths of the viewport, while the ‘right_thing’ takes up the rest.  When the viewport shrinks for mobile, then the left_thing gets stacked on top.  Simple enough.

However, what if you want the right_thing to render to the right in desktop mode but stack on top of the left_thing on mobile devices?  That’s when it starts to get tricky.

In order to get the “right_thing” to stack on top, it has to be declared first in the markup, like so:

<div class='row'>
  <div id="right_thing" class="two fifths"></div>
  <div id="left_thing" class="three fifths"></div>
</div>

However, this screws up the ordering in desktop mode!  Fortunately, there’s a fix.

It turns out that Groundwork will allow you to shift around the relative ordering of your declared elements.  So, if you want to swap the “right_thing’ and “left_thing” into their proper places for desktop browsers, we’ll need to add some more classes.

<div class='row'>
  <div id="right_thing" class="two fifths right-three></div>
  <div id="left_thing" class="three fifths left-two"></div>
</div>

Note that the “right_thing” needed to be nudged over for the number of columns that “left_thing” was taking up, and we had to do a similar dance for “left_thing”.   It turns out that Groundwork behaves quite differently from the standard CSS box model, and shifting an element using the “right-xxx” or “left-xxx” directives does NOT cause anything else to automatically move.  Much like CSS relative positioning, you’ll have to shift the other elements yourself to get the effect you want.  Be careful, or you’ll get overlapping elements or breaks that you don’t want.

You can also omit columns or skip columns to create negative space.  For example, here’s two equal sized columns with 20% margins on the sides.

<div class='row'>
  <div id="right_thing" class="one fourth skip-one"></div>
  <div id="left_thing" class="one fourth"></div>
</div>

Note that we didn’t account for the fourth (and rightmost) column in the markup.  Since we declared “fourth” in one of the row elements, Groundwork will automagically create four columns, no matter how few we provide elements for.

There’s some other tricky bits, but figuring out the nuances of column stacking has been by far my biggest hurdle.  After getting that sorted, it’s been pretty smooth sailing. Overall, I’m impressed by the power and simplicity of Groundwork, and would strongly recommend anyone who’s interested in a responsive grid system to give it a shot.

(Note: For most of this article, feel free to mentally substitute Ember, Angular, or your JS framework of choice for Backbone. Backbone’s just the popular one right now.)

At Pivotal Labs we do a lot of web-based projects.  Usually, it’s a pretty easy choice to use Rails for the back-end.  Not only is it a battle-tested framework, but we’ve developed a lot of expertise over the years.  However, many times there’s a question when we start building the front-end:

“Backbone or standard Rails?”

I’ll say right now that there’s no “right” answer here.  However, here’s a few things to consider that might help you make a decision.

1. Do you need SEO?

If your project needs any kind of SEO, or for content to be crawlable/scrapable, do NOT start with a single-page Javascript app.  While Google supposedly crawls using JS, it’s certainly not perfect.  Every other crawler or scraper out there will fail hard.  To overcome this, I’ve heard rumors of people rendering the JavaScript server-side, but that seems like an extraordinary effort for questionable gains.

2. Is your project really an API?

On the flip side, one nice thing about using a single page app for your front end is that it forces you to develop a robust API.  Even more importantly, it practically guarantees a clean separation between your front-end and back-end.  If you know you’ll eventually need to build a number of different native clients, or if offering a public API is part of the core product, then starting with a Backbone app makes a lot of sense.

3. Do you control the back end?

Sometimes, we don’t have the benefit of controlling the whole stack. Either there’s a legacy back-end, or you’re consuming somebody else’s API.  Sometimes you could build a Rails app that makes API calls on the backend, but usually it’s much cleaner to just go with Backbone and let the browser consume the APIs directly.

4.  How comfortable is your team with rolling your own technology?

Rails is fairly mature, and has huge amounts of community support.  For most problems that you’ll encounter, there’s an abundance of gems, sample code, blog posts, Stack Overflow answers, etc.  Much of the time, building a Rails app is mostly a matter of translating business needs into a pastiche of pre-established patterns and tools.

On the other side, Backbone provides a very thin layer of structure and a limited toolkit.  Every Backbone project ends up “rolling their own framework”, and building up their own patterns for view lifecycles, session management, authentication and authorization, and a hundred other things.  While this gives you a lot of fine grained-control, it means there’s a lot more decisions to make (and probably more code to write).  A team that’s not comfortable with that might want to think twice.

Some larger frameworks like Ember and Angular help with this somewhat.  However, there isn’t anything in the JS landscape that’s even close to the maturity and breadth of Rails.

While this isn’t a comprehensive list by any stretch, it’s a few of the top things that I’ve had to consider in the past.  There’s also an interesting list of non-factors, but that’s a topic for another blog post.