Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Backbone.js and its API confusion

I've recently started using Backbone.js. I like the architecture, in terms of features it's almost exactly what I need...

... However I found the following caveats:

  • For Collections get means something different than for Models. There is no set. Attributes should be accessed in a regular way. I find it rather inconsistent. It's easy to confuse models and collections sometimes. Is there anything that can be done to overcome this?
  • Assigning initial values inside Model.extend doesn't always work. For example assigning url will not override the default behaviour. This can only be achieved through a call to set() method. Again very error prone.
  • I still don't know whether it's required to use get/set inside initialize() call.
  • I don't understand why I can't just call _.bindAll(this) inside initialize() and I have to list specific function names to be bound like this: _.bindAll(this, firstFunc, secondFunc, ...). This is not very DRY.

I would like to know: what are the best practices regarding the mentioned situations? What do you do to make the framework more consistent - any monkey patching? Am I doing anything wrong / against the convention?

I'd be grateful for any good real world examples. I did find this: http://documentcloud.github.com/backbone/docs/todos.html and http://liquidmedia.ca/blog/2011/01/backbone-js-part-1/ and those don't address any of the mentioned problems. In fact they just present the simplest ideas and absolutely no border cases, so anything more complicated could be useful.

EDIT:

Ok, and there is one more fundamental think I don't understand:

  • Am I ever allowed to place additional attributes on extension like this: var SomeModel = Backbone.Model.extend({ myattribute: myvalue }) ?
    • If so, then why don't subsequent calls to new SomeModel().get("myattribute") work ?
  • What exactly is this inside initialize() ? Is it model class or model instance ?

EDIT(2):

Well, I found this: http://maccman.github.com/spine/. It looks like Backbone.js 2.0, shares a similar name too :). Haven't tested it yet, which might be a bit of a show stopper, as the library is very recent. However from the docs side of things it looks very promissing. It gets rid of most of the problems that I found, it simplifies the API, it even gets rid of the dependency on underscore.js which for a library is a good thing. I'll post my further findings here.

like image 830
julx Avatar asked Apr 27 '11 01:04

julx


People also ask

Is Backbone JS still used?

Backbone. Backbone has been around for a long time, but it's still under steady and regular development. It's a good choice if you want a flexible JavaScript framework with a simple model for representing data and getting it into views.

Is Backbone JS frontend or backend?

Front-End MVC frameworks (Backbone, Angular, etc) all rely on a backend service to provide the data that, say Backbone, would then use as its model. You could have an entire MVC pattern on the backend that accepts requests and spits out some JSON for a frontend MVC framework to use.

How does Backbone JS work?

Backbone. js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.

What is backbone JS comparable to?

Vue. js, React, AngularJS, Angular 2, and Ember. js are the most popular alternatives and competitors to Backbone. js.


1 Answers

Ok, I think I can say it quite confidently now: Backbone is dead, long live Spine.

Spine isn't exactly a fork of Backbone. It is however very similar and clearly inspired by some of the design decisions. It could be said that the author tried to retain as much as it was possible the original backbone API, getting rid of everything unnecessary or illogical. I find it also easier to extend. The list of changes includes among other things:

  • Getting rid of the dreaded Collections. "class methods" are used instead,
  • Getting most out of js prototypical nature (i.e. no get/set is needed). Attributes are accessed directly. An explicit call to save() is required in order to trigger an event.
  • Views and Controllers are now merged into new type of Controllers together whose purpose is to respond to DOM events and bind to model events.
  • The name :)

I find those design decisions coherent and sensible.

like image 185
julx Avatar answered Oct 03 '22 08:10

julx