Comments on: Don’t Limit Your Backbone Apps To Backbone Constructs

By: Louis Chatriot

Louis Chatriot — Fri, 13 Apr 2012 09:36:00 +0000

I totally agree with this, but I think you can take it a step further. It is true for any framework, sometimes what you want to do just doesn’t fit. It happened to me a few years ago with GRails, when the validation system was not too good. After spending some time trying to make it work, I finally rewrote it to fit my needs.

By: Riley Strong

Riley Strong — Wed, 07 Dec 2011 16:32:00 +0000

Thanks for the post – this kind of validates what I’ve been doing with Backbone. Because our application has many independent pages, I extended “Backbone.View” to make “PageView” which loads resources, rigs up events, calls in regular views, and renders the foundation of the page. It does all the things of a regular View… and then some.

Do you think that makes sense?

By: Marco Rogers

Marco Rogers — Wed, 31 Aug 2011 18:26:00 +0000

There’s no *right* way to develop anything (though there are usually several wrong ways). The right way is the way you understand and that works best for your requirements. What I got from this post is that you should try to recognize false constraints, like using backbone constructs everywhere. And you should try to break out of that mindset if it leads you to a simpler or more flexible architecture.

By: Derick Bailey

Derick Bailey — Wed, 31 Aug 2011 18:07:00 +0000

ok, i missed your original question in that reply… there are not necessarily any “right” or “wrong” ways to build a backbone app. backbone is a very flexible system and you can build apps in many different ways. each of the different approaches that are possible have pros and cons, and fit better or worse to a given scenario.

i tried to show how the appview fit the scenario of the simple to-do list, and also show that it is not the only way to build an app launcher object.

By: Derick Bailey

Derick Bailey — Wed, 31 Aug 2011 18:05:00 +0000

there’s not necessarily anything wrong with the to-do list. i’m even defending the AppView from that app in my post… the problem is not the to-do list or how it’s built. the problem is assuming the to-do list represents the one-true-way to build backbone apps.

the to-do list is a very small, very simple app. it doesn’t need much in terms of infrastructure. it doesn’t need an event-driven architecture. it doesn’t need to always keep every last detail cleanly separated from other bits.

if you’re learning and/or building a very small, very simple app, then follow along with the to-do app’s example. the most important thing to learn from this example is not _how_ or _what_ it does, but _why_ it does things the way it does.

my post is trying to shed a little light on why, and help people understand the scope of this sample app, so that they can see where their own apps and larger apps should diverge from that sample.

hope that helps clear things up

By: Randy

Randy — Wed, 31 Aug 2011 17:36:00 +0000

So, I am going to play the Backbone.js newb card here (because that’s the only card in my hand).

What exactly *is* the right way to develop Backbone.js apps if the todo example is not the correct way? There is something very pragmatic and practical with having an example app to work from. For example, Rails scaffolding was how a lot of people learned Rails.

By: Stephen Belanger

Stephen Belanger — Wed, 31 Aug 2011 17:12:00 +0000

Great advice! I’ve seen far too many backbone apps that abuse the Backbone constructs and equally as many that don’t use the event system as much as they should.