9 ms·

Announcing Backbone.js 1.0

396 points by jashkenas 14y ago

troygoode 14y ago
The change log for 1.0 can be found here: http://backbonejs.org/#changelog http://backbonejs.org/#changelog 1.0.0 — March 20, 2013 * Renamed Collection's "update" to set, for parallelism with the similar model.set(), and contrast with reset. It's now the default updating mechanism after a fetch. If you'd like to continue using "reset", pass {reset: true}. * Your route handlers will now receive their URL parameters pre-decoded. * Added listenToOnce as the analogue of once. * Added the findWhere method to Collections, similar to where. * Added the keys, values, pairs, invert, pick, and omit Underscore.js methods to Backbone Models. * The routes in a Router's route map may now be function literals, instead of references to methods, if you like. * url and urlRoot properties may now be passed as options when instantiating a new Model. Congratulations to Jeremy and everyone else who made this milestone possible. We've come a long way in the JS community over the last few years since SproutCore & Cappuccino were all the rage - Backbone has undeniably been a huge part of the progress we've seen.
- jashkenas 14y ago
  SproutCore and Cappuccino have also undeniably been a huge part of the progress we've seen ;) To expand on your helpful paste, for the detail-oriented among you, the full list of changes and diff is available here: https://github.com/documentcloud/backbone/compare/0.9.10...1.0.0 https://github.com/documentcloud/backbone/compare/0.9.10...1...
  - camus 14y ago
    Cappucino is great , its problem is that it is just not debuggable for now , but maybe one day when it gets source maps. Otherwise it is a great framework. Backbone is great because it is minimal , you can start small then grow with it , like sinatra ,etc .... i like that approach.
bruth 14y ago
Many thanks to the whole team of contributors for making a very useful and concise library to build upon. Many frameworks take the "batteries included" approach.. and for JavaScript, I feel that can be a bit overkill since each web app has it's own set of requirements. Backbone has proven to provide _just enough_ for structuring web apps and has clearly been useful in a wide variety of projects [1]. [1]: http://backbonejs.org/#examples http://backbonejs.org/#examples
- DomBlack 14y ago
  I agree completely. I've started using Backbone for the models and validation. Although I would like to see reactive fields built in; that said I've written an extension to Backbone.Model which gives me that (just ugly syntax)
  - pavel_lishin 14y ago
    Have you released the extension anywhere?
    - DomBlack 14y ago
      No, it was for a work project.
- welder 14y ago
  An updated Todo App Example using AMD (RequireJS): http://ahamlett.com/Backbone.localStorage http://ahamlett.com/Backbone.localStorage
RobertHoudin 14y ago
For anyone who might be interested, my housemate published a book of Backbone tutorials. You can download it for free from http://backbonetutorials.com/ http://backbonetutorials.com/
MatthewPhillips 14y ago
> Support for HTTP PATCH requests, sending only the changed state of your model to the server, instead of the full representation. This feels a little off to me. The nice thing about Backbone vs. other frameworks is that it's not overly opinionated, you can structure your backend any way you want, so I'm not sure why Backbone has an opinion of what http methods save() uses. PUT as a default makes sense but it should be able to support POST, PATCH, GET, CHANGETHETHING or anything else, as browsers now support arbitrary method strings in XHR. Perhaps an override some where?
- peregrine 14y ago
  http://tools.ietf.org/html/rfc5789 http://tools.ietf.org/html/rfc5789 HTTP PUT is for in place entire entity updates. HTTP PATCH is for partial updates. This isn't some opinion these guys came up with. It's HTTP standards. Also if you don't like what save does. Write your own Backbone.sync and be done with it. Still super flexible.
  - MatthewPhillips 14y ago
    Fair enough, I agree with the spec here, but we know that in the wild many companies don't conform to HTTP.
    - jmorton 14y ago
      For what it's worth... "PATCH is going to be the primary method for updates in Rails 4.0." http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/ http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-... That's not intended to be a counterpoint. In the wild, many companies don't use Rails. :)
      - k3n 14y ago
        It doesn't matter what Rails decides to do if your HTTP server doesn't support it. With that said, it looks like many do already support it (from the same article you linked): Apache, nginx, Phusion Passenger, Unicorn, Thin, and WEBrick.
frankblizzard 14y ago
Both of our apps did not work anymore after the update. Does Renamed Collection's "update" to set, for parallelism with the similar model.set(), and contrast with reset. It's now the default updating mechanism after a fetch. If you'd like to continue using "reset", pass {reset: true}. mean that now collections don't fire the 'reset' event anymore? Should we use collection.on('set', ...) instead? Because I think there are a lot of apps in the wild relying on the collection.on('reset', ...) syntax out there as this is seen in most of the tutorials.
- jashkenas 14y ago
  Not quite -- the default has changed. It means you should call: collection.fetch({reset: true}) ... and everything should continue to work as it did before. That said, this isn't the best forum for debugging help -- you'll probably have faster responses asking on IRC.
  - frankblizzard 14y ago
    ok thanks for clarification. and for backbone in general ;)
  - zeckalpha 14y ago
    This helped me, too. Thanks!
jscheel 14y ago
Many congrats and thanks to Jeremy and the other contributors. Backbone's opinion-less approach has been so great for our startup, even if it took me a solid 3 months before I really understood why it was so great. Seriously, coming from working on super-opinionated backend frameworks meant a lot of unlearning when I started using Backbone in October of 2011. Keep up the awesome work!
- dtjohnnymonkey 14y ago
  Congrats Jeremy and team! I picked up Backbone a couple of years ago (around 0.6). It is balanced at the perfect level of abstraction for me. There have been a ton of frameworks coming up over the last few years but none of them beat Backbone for me. Thanks for all your work and if there some place I can throw some $USD your way or a charity you prefer, please let us know.
arrowgunz 14y ago
One thing I really like about Backbone is their excellent documentation. That's the kind of documentation an OpenSource project needs.
camus 14y ago
Great , news ! Backbone was the first framework i used to create rich web apps. What's great is that it is both usefull for LOB apps and more specific apps like Games , Complex editors , etc ...
Cthulhu_ 14y ago
When I first worked with Backbone.js almost a year and a half ago, honestly, me and my team hardly had any clue what we were doing; the documentation was probably just as good as it is today, but it just didn't click with us, it seems. We did finish our application at the time (a six-screen monitoring application, think a lot of tables and some graphs), but it didn't feel "nice". A year ago we started our second project, and it made a lot more sense. It's a pretty big project, we've got ~10.000 LOC of Javascript, most of which is Backbone views/models/routers, some Handlebars helpers. The project has, based on our filenaming conventions, 18 routers, 68 views, and probably around 75+ models. Using Require.js we keep the codebase clean and organized, and using some custom functions (a close function, most importantly) we stop it from being a memory hog. I like Backbone. The major competitor is Angular, but it's more high-level; Backbone itself is just a thin layer on top of vanilla JS, jquery and underscore, really, but that's what gives it its power. Looking forward to upgrading to 1.0. The change in reset behavior will cost us some work, but it sounds like it's doable.
- danso 14y ago
  Even though the Backbone API has been solid for a very long time, here's hoping the psychological effect of reaching "1.0" continues to spur opinionated abstractions that sit on top of Backbone.
- kreek 14y ago
  Not to rain on Backbone's parade, but I am easily twice as productive in angular.js. The learning curve is a bit steeper but once you mastered you end up with (IMO) a cleaner more maintainable app.
  - film42 14y ago
    I think angular offers some amazing features, but it's very opinionated in how you use it. My experience with angular has left me feeling less like a javascript wrangler and more like an angular wrangler. I mean no disrespect to the framework, because it is amazing, but, it's just different.
  - mrchess 14y ago
Q_the_Novice 14y ago
Backbone.js has made me a better JavaScript programmer, thank you Jeremy and everyone else that has contributed to this wonderful project.
- anonfunction 14y ago
  I credit backbone with a lot of my success as a front end developer as well. Even though I moved on from the project, the ideas and design decisions have stayed with me.
dnajd 14y ago
Why are the backbone.js controllers called 'views' and the views called 'templates'?
- knowtheory 14y ago
  Views are not controllers. Views are more akin to presenters, or viewmodels. You are right that what is traditionally considered a "view" in the rails parlance is a template to backbone. fwiw, Routers used to be called Controllers.
  - dnajd 14y ago
    Looking at the definition of controllers here: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93cont... how are backbone.js 'views' not controllers? Or does this logic belong in the Route.js file? I am clearly confused. FYI.. rails didn't invent mvc; it was invented in the 70's for smalltalk.
    - kalms 14y ago
      I think we all know that by now. Backbone doesn't subscribe to neither MVC or MVP. It takes what it needs and does away with the rest. Either you like that or you don't, but that doesn't make it wrong.
- mambodog 14y ago
  Sounds like Django's "MTV" naming of those concepts: http://www.djangobook.com/en/2.0/chapter05.html#the-mtv-or-mvc-development-pattern http://www.djangobook.com/en/2.0/chapter05.html#the-mtv-or-m...
  - re_todd 14y ago
    Yeah, I've started learning Django this week, and one of the first confusing questions I asked myself is "why are there so many templates?". Then I realized a template in Django is like a normal view in Rails or other frameworks.
VeejayRampay 14y ago
Great! Will use (eventually)... Congrats and thanks to Mr Ashkenas.
civilian 14y ago
I just got thrown onto a Backbone w/ Coffee-script project at work. This book has been pretty helpful for getting up to speed: https://www.scriptybooks.com/books/backbone-coffeescript/ https://www.scriptybooks.com/books/backbone-coffeescript/ and this boilerplate code: https://github.com/quartzmo/backbone-coffeescript-boilerplate https://github.com/quartzmo/backbone-coffeescript-boilerplat... (which I just added `*.coffee` sourceMapping to!)
nijiko 14y ago
Cannot wait for this to die off.
pulledpork 14y ago
Seems like great timing with the ember conversation on the front page too. Isn't ember a offshoot of backbone?
- xaritas 14y ago
  No. Ember is a fork (conceptually, at least; I'm not sure about common code) of SproutCore: http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/ http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor... Ember was Amber for about 2 days but changed due to a naming collision with another project. I really read too much Hacker News.
dsyph3r 14y ago
Of all the JS libraries/frameworks I've used Backbone.js is the one I always come back to. Great to see the 1.0 release. Keep up the great work
anonfunction 14y ago
I always liked Backbone, using it exclusively before switching to ember.js as of recently. I wonder why the authors waited more than 2 years to reach 1.0?
steveax 14y ago
Congrats to Jeremy and all the contributors. Thanks for all the hard work and diligent attention to details!
wnsnw 14y ago
Does this mean breaking changes will now go through a deprecation process?
- jashkenas 14y ago
  That's a very good question. Depending on the severity of the change, and the popularity of the feature being changed, we'll probably start to explicitly deprecate some things. One (potential) example might be the use of `{silent: true}` to prevent events from being fired. But that said, the nature of a "breaking change" in Backbone is much less severe than in most open-source libraries. All released versions are published on GitHub, and you can use any version you see fit at any time. In addition, because the codebase is so compact, broken into atomic functions, and thoroughly commented -- it's really easy to patch to suit your own needs, should you find something you need to change without waiting for us to push a new release. I haven't heard of anyone having a problem yet with a feature that was changed, where one of the above approaches didn't work out.
  - wnsnw 14y ago
    The suggested options, if I comprehend you properly, are A) Stick with the version you originally programmed against and B) Analyze the overall diff between versions if upgrading. New features/improvements provide an incentive to not choose Option A. With regard to Option B: Although Backbone may be compact and easy to comprehend, the code calling it is much larger. Analyzing Backbone's changes and factoring in all code that calls it is a difficult and error prone process - laregly due to the dynamic nature of the language and lack of tooling for refactoring. Two changes that bit us from 0.9.2->0.9.10 were model.set no longer accepting a model and, instead, requiring model.attributes (not a big deal, as it threw an exception and was immediately noticeable). The second issue, with collection.fetch, was a silent failure (I forget the exact issue, but the solution was providing two options, perhaps reset/update/add). Neither of these were documented in the changelogs. It's not so much an issue of patching these breaking changes as it is knowing about them. Perhaps the ultimate issue here is our lack of adequate testing.
- deleted 14y ago
  [deleted]
trungonnews 14y ago
It will be awesome if we can couple Backbone with NodeJs to build SEO friendly web apps like Yahoo Mojito.
anonfunction 14y ago
Here's a great example of the RESTfulness backbone provides: http://duganchen.ca/backbone-js-and-restful-web-services/ http://duganchen.ca/backbone-js-and-restful-web-services/

396 points by jashkenas 14y ago

The change log for 1.0 can be found here: http://backbonejs.org/#changelog http://backbonejs.org/#changelog 1.0.0 — March 20, 2013 * Renamed Collection's "update" to set, for parallelism with the similar model.set(), and contrast with reset. It's now the default updating mechanism after a fetch. If you'd like to continue using "reset", pass {reset: true}. * Your route handlers will now receive their URL parameters pre-decoded. * Added listenToOnce as the analogue of once. * Added the findWhere method to Collections, similar to where. * Added the keys, values, pairs, invert, pick, and omit Underscore.js methods to Backbone Models. * The routes in a Router's route map may now be function literals, instead of references to methods, if you like. * url and urlRoot properties may now be passed as options when instantiating a new Model. Congratulations to Jeremy and everyone else who made this milestone possible. We've come a long way in the JS community over the last few years since SproutCore & Cappuccino were all the rage - Backbone has undeniably been a huge part of the progress we've seen.

jashkenas 14y ago
SproutCore and Cappuccino have also undeniably been a huge part of the progress we've seen ;) To expand on your helpful paste, for the detail-oriented among you, the full list of changes and diff is available here: https://github.com/documentcloud/backbone/compare/0.9.10...1.0.0 https://github.com/documentcloud/backbone/compare/0.9.10...1...
- camus 14y ago
  Cappucino is great , its problem is that it is just not debuggable for now , but maybe one day when it gets source maps. Otherwise it is a great framework. Backbone is great because it is minimal , you can start small then grow with it , like sinatra ,etc .... i like that approach.

bruth 14y ago

Many thanks to the whole team of contributors for making a very useful and concise library to build upon. Many frameworks take the "batteries included" approach.. and for JavaScript, I feel that can be a bit overkill since each web app has it's own set of requirements. Backbone has proven to provide _just enough_ for structuring web apps and has clearly been useful in a wide variety of projects [1]. [1]: http://backbonejs.org/#examples http://backbonejs.org/#examples

DomBlack 14y ago
I agree completely. I've started using Backbone for the models and validation. Although I would like to see reactive fields built in; that said I've written an extension to Backbone.Model which gives me that (just ugly syntax)
- pavel_lishin 14y ago
  Have you released the extension anywhere?
  - DomBlack 14y ago
    No, it was for a work project.
welder 14y ago
An updated Todo App Example using AMD (RequireJS): http://ahamlett.com/Backbone.localStorage http://ahamlett.com/Backbone.localStorage

RobertHoudin 14y ago

For anyone who might be interested, my housemate published a book of Backbone tutorials. You can download it for free from http://backbonetutorials.com/ http://backbonetutorials.com/

MatthewPhillips 14y ago

> Support for HTTP PATCH requests, sending only the changed state of your model to the server, instead of the full representation. This feels a little off to me. The nice thing about Backbone vs. other frameworks is that it's not overly opinionated, you can structure your backend any way you want, so I'm not sure why Backbone has an opinion of what http methods save() uses. PUT as a default makes sense but it should be able to support POST, PATCH, GET, CHANGETHETHING or anything else, as browsers now support arbitrary method strings in XHR. Perhaps an override some where?

peregrine 14y ago
http://tools.ietf.org/html/rfc5789 http://tools.ietf.org/html/rfc5789 HTTP PUT is for in place entire entity updates. HTTP PATCH is for partial updates. This isn't some opinion these guys came up with. It's HTTP standards. Also if you don't like what save does. Write your own Backbone.sync and be done with it. Still super flexible.
- MatthewPhillips 14y ago
  Fair enough, I agree with the spec here, but we know that in the wild many companies don't conform to HTTP.
  - jmorton 14y ago
    For what it's worth... "PATCH is going to be the primary method for updates in Rails 4.0." http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/ http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-... That's not intended to be a counterpoint. In the wild, many companies don't use Rails. :)
    - k3n 14y ago
      It doesn't matter what Rails decides to do if your HTTP server doesn't support it. With that said, it looks like many do already support it (from the same article you linked): Apache, nginx, Phusion Passenger, Unicorn, Thin, and WEBrick.

frankblizzard 14y ago

Both of our apps did not work anymore after the update. Does Renamed Collection's "update" to set, for parallelism with the similar model.set(), and contrast with reset. It's now the default updating mechanism after a fetch. If you'd like to continue using "reset", pass {reset: true}. mean that now collections don't fire the 'reset' event anymore? Should we use collection.on('set', ...) instead? Because I think there are a lot of apps in the wild relying on the collection.on('reset', ...) syntax out there as this is seen in most of the tutorials.

jashkenas 14y ago
Not quite -- the default has changed. It means you should call: collection.fetch({reset: true}) ... and everything should continue to work as it did before. That said, this isn't the best forum for debugging help -- you'll probably have faster responses asking on IRC.
- frankblizzard 14y ago
  ok thanks for clarification. and for backbone in general ;)
- zeckalpha 14y ago
  This helped me, too. Thanks!

jscheel 14y ago

Many congrats and thanks to Jeremy and the other contributors. Backbone's opinion-less approach has been so great for our startup, even if it took me a solid 3 months before I really understood why it was so great. Seriously, coming from working on super-opinionated backend frameworks meant a lot of unlearning when I started using Backbone in October of 2011. Keep up the awesome work!

dtjohnnymonkey 14y ago
Congrats Jeremy and team! I picked up Backbone a couple of years ago (around 0.6). It is balanced at the perfect level of abstraction for me. There have been a ton of frameworks coming up over the last few years but none of them beat Backbone for me. Thanks for all your work and if there some place I can throw some $USD your way or a charity you prefer, please let us know.

arrowgunz 14y ago

One thing I really like about Backbone is their excellent documentation. That's the kind of documentation an OpenSource project needs.

camus 14y ago

Great , news ! Backbone was the first framework i used to create rich web apps. What's great is that it is both usefull for LOB apps and more specific apps like Games , Complex editors , etc ...

Cthulhu_ 14y ago

When I first worked with Backbone.js almost a year and a half ago, honestly, me and my team hardly had any clue what we were doing; the documentation was probably just as good as it is today, but it just didn't click with us, it seems. We did finish our application at the time (a six-screen monitoring application, think a lot of tables and some graphs), but it didn't feel "nice". A year ago we started our second project, and it made a lot more sense. It's a pretty big project, we've got ~10.000 LOC of Javascript, most of which is Backbone views/models/routers, some Handlebars helpers. The project has, based on our filenaming conventions, 18 routers, 68 views, and probably around 75+ models. Using Require.js we keep the codebase clean and organized, and using some custom functions (a close function, most importantly) we stop it from being a memory hog. I like Backbone. The major competitor is Angular, but it's more high-level; Backbone itself is just a thin layer on top of vanilla JS, jquery and underscore, really, but that's what gives it its power. Looking forward to upgrading to 1.0. The change in reset behavior will cost us some work, but it sounds like it's doable.

danso 14y ago
Even though the Backbone API has been solid for a very long time, here's hoping the psychological effect of reaching "1.0" continues to spur opinionated abstractions that sit on top of Backbone.
kreek 14y ago
Not to rain on Backbone's parade, but I am easily twice as productive in angular.js. The learning curve is a bit steeper but once you mastered you end up with (IMO) a cleaner more maintainable app.
- film42 14y ago
  I think angular offers some amazing features, but it's very opinionated in how you use it. My experience with angular has left me feeling less like a javascript wrangler and more like an angular wrangler. I mean no disrespect to the framework, because it is amazing, but, it's just different.
- mrchess 14y ago

Q_the_Novice 14y ago

Backbone.js has made me a better JavaScript programmer, thank you Jeremy and everyone else that has contributed to this wonderful project.

anonfunction 14y ago
I credit backbone with a lot of my success as a front end developer as well. Even though I moved on from the project, the ideas and design decisions have stayed with me.

dnajd 14y ago

Why are the backbone.js controllers called 'views' and the views called 'templates'?

knowtheory 14y ago
Views are not controllers. Views are more akin to presenters, or viewmodels. You are right that what is traditionally considered a "view" in the rails parlance is a template to backbone. fwiw, Routers used to be called Controllers.
- dnajd 14y ago
  Looking at the definition of controllers here: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93cont... how are backbone.js 'views' not controllers? Or does this logic belong in the Route.js file? I am clearly confused. FYI.. rails didn't invent mvc; it was invented in the 70's for smalltalk.
  - kalms 14y ago
    I think we all know that by now. Backbone doesn't subscribe to neither MVC or MVP. It takes what it needs and does away with the rest. Either you like that or you don't, but that doesn't make it wrong.
mambodog 14y ago
Sounds like Django's "MTV" naming of those concepts: http://www.djangobook.com/en/2.0/chapter05.html#the-mtv-or-mvc-development-pattern http://www.djangobook.com/en/2.0/chapter05.html#the-mtv-or-m...
- re_todd 14y ago
  Yeah, I've started learning Django this week, and one of the first confusing questions I asked myself is "why are there so many templates?". Then I realized a template in Django is like a normal view in Rails or other frameworks.

VeejayRampay 14y ago

Great! Will use (eventually)... Congrats and thanks to Mr Ashkenas.

civilian 14y ago

I just got thrown onto a Backbone w/ Coffee-script project at work. This book has been pretty helpful for getting up to speed: https://www.scriptybooks.com/books/backbone-coffeescript/ https://www.scriptybooks.com/books/backbone-coffeescript/ and this boilerplate code: https://github.com/quartzmo/backbone-coffeescript-boilerplate https://github.com/quartzmo/backbone-coffeescript-boilerplat... (which I just added `*.coffee` sourceMapping to!)

nijiko 14y ago

Cannot wait for this to die off.

pulledpork 14y ago

Seems like great timing with the ember conversation on the front page too. Isn't ember a offshoot of backbone?

xaritas 14y ago
No. Ember is a fork (conceptually, at least; I'm not sure about common code) of SproutCore: http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/ http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor... Ember was Amber for about 2 days but changed due to a naming collision with another project. I really read too much Hacker News.

dsyph3r 14y ago

Of all the JS libraries/frameworks I've used Backbone.js is the one I always come back to. Great to see the 1.0 release. Keep up the great work

anonfunction 14y ago

I always liked Backbone, using it exclusively before switching to ember.js as of recently. I wonder why the authors waited more than 2 years to reach 1.0?

steveax 14y ago

Congrats to Jeremy and all the contributors. Thanks for all the hard work and diligent attention to details!

wnsnw 14y ago

Does this mean breaking changes will now go through a deprecation process?

jashkenas 14y ago
That's a very good question. Depending on the severity of the change, and the popularity of the feature being changed, we'll probably start to explicitly deprecate some things. One (potential) example might be the use of `{silent: true}` to prevent events from being fired. But that said, the nature of a "breaking change" in Backbone is much less severe than in most open-source libraries. All released versions are published on GitHub, and you can use any version you see fit at any time. In addition, because the codebase is so compact, broken into atomic functions, and thoroughly commented -- it's really easy to patch to suit your own needs, should you find something you need to change without waiting for us to push a new release. I haven't heard of anyone having a problem yet with a feature that was changed, where one of the above approaches didn't work out.
- wnsnw 14y ago
  The suggested options, if I comprehend you properly, are A) Stick with the version you originally programmed against and B) Analyze the overall diff between versions if upgrading. New features/improvements provide an incentive to not choose Option A. With regard to Option B: Although Backbone may be compact and easy to comprehend, the code calling it is much larger. Analyzing Backbone's changes and factoring in all code that calls it is a difficult and error prone process - laregly due to the dynamic nature of the language and lack of tooling for refactoring. Two changes that bit us from 0.9.2->0.9.10 were model.set no longer accepting a model and, instead, requiring model.attributes (not a big deal, as it threw an exception and was immediately noticeable). The second issue, with collection.fetch, was a silent failure (I forget the exact issue, but the solution was providing two options, perhaps reset/update/add). Neither of these were documented in the changelogs. It's not so much an issue of patching these breaking changes as it is knowing about them. Perhaps the ultimate issue here is our lack of adequate testing.
deleted 14y ago
[deleted]

trungonnews 14y ago

It will be awesome if we can couple Backbone with NodeJs to build SEO friendly web apps like Yahoo Mojito.

anonfunction 14y ago

Here's a great example of the RESTfulness backbone provides: http://duganchen.ca/backbone-js-and-restful-web-services/ http://duganchen.ca/backbone-js-and-restful-web-services/