(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.
