Wow I am incredibly impressed by this, great work to the DocumentCloud team! I can't wait to throw this into real-life use... it looks like everything I could ever want in a framework.
I too am a jQuery developer, but not your typical one. I tend to avoid slapping plugins together and write most of my own things from scratch, in my own pythonic classical style. I also tend to use the little jQuery helper methods and CSS selector tools purely as an interface to the DOM. The hard work is all done via classes, which drastically reduces the code that I write. I see other not-so-skilled jQuery script kiddies out there piecing together documents full of $('#blah') this and $('#bloo') that with little regard for chaining or simplifying things. I digress, as that is not the demographic for this wonderful library of code.
Here is an example of what kind of code I have been writing as of late: http://dpaste.de/pKOi/ -- as you can see, there is a small bit if boilerplate required and a 'var self = this' inside of each class method that is required. That's more for my own personal style actually, to help with preventing loss of 'this' scope down the road. Anyway... over time this code just sort of piles up and it would be nicer to 1) have a better way to define and organize it all, and 2) all of the great model/collection/validation stuff looks excellent! Evented programming is brilliant to, and the fact that a thousand pieces of code can all stay in sync thru events is just fantastic.
Key point of Backbone.js: This is for designing web apps, not just a web page. When you have multiples of the anything on a page, it's time to move to separating out your views from your models, and Backbone.js is perfect for this sort of transformation. Even better if you start with Backbone.js. And Backbone.js is a minimal set of functionality to get this done.
I am personally planning on integrating Backbone into NewsBlur, an RSS feed reader, which currently has an ad-hoc model system. Backbone would give it the ability to update stories and feeds without having to remember where all of the stories and feeds are on the page.
Anyway, Backbone takes a bit of getting used to, but it is fairly easy to read the annotated source to see exactly what's happening. And once you do learn the Backbone.js conventions, hard problems become much easier on the front-end.
This issue is very much considered. You absolutely don't use this to make a bunch of tiny little Ajax requests to load your application in pieces. Instead, you bootstrap all of the data you need for an initial load onto the page, and then populate the collections directly.
For saving, a single update often needs to be a single request, and the UI needs to know that the update has been applied successfully. If you need to do a bulk update, then use "set", not "save", and make a custom Ajax call for the bulk operation.
Finally, Backbone.sync is the lowest-common-denominator default REST request, which will work for many applications. You can and should override it if you have more specific needs -- using timeouts to aggregate many granular saves into a single HTTP request is a great idea for some applications...
I'm a little confused about what the best-case/ideal scenario is for this.
As an example, I am currently working on a project that has a basic profile page. So on the server side, I have my nice OO representation of a Profile object, complete with properly defined public and private variables, a slew of functions, and a save() function that validates saves the data to the database.
When I display that page to the client, I have a PHP view which takes the data from the model and then renders it. In the view, I do currently use jQote2 to do some basic client-side templating where appropriate (for example, displaying all of the friends of the profile's user).
Now, the Profile page features the ability to edit profile fields. There is jQuery involved here. Currently, I just have a function that is called when the "Save" button is clicked that gathers up all the various data from my input fields and whatnot, and sends that off as JSON to be saved on the PHP side of things.
I guess I'm just confused as to where this fits into the grand scheme of things. There's a part of me that certainly likes the idea of data binding and having smart re-rendering of parts of my pages based on when models change, but I'm just unclear on how this fits into my existing PHP MVC stuff.
So basically this is for those folks who are making real "web applications" -- meaning applications where a lot is happening on the client side, typically more of a "single URL/page", with dialog boxes and whatnot as opposed to a bunch of pages in the more traditional "web site" sense.
I have often considered trying out Cappuccino, but for some reason none of the websites I build end up being "web applications" in this sense. But I can't help but wonder if that's because they aren't, or if it's because I'm not thinking about them the right way.
It's outside the scope of this topic, but I can't help but ask: "How do you know when a website becomes a web application"? Is it the scope of the problem (trying to do "one thing", e.g. edit a photo, vs. presenting an entire web site full of information?) Or is it truly just a preference thing? I can only think that as projects like Node.js gain prominence, the lines will continue to be blurred...
"views with declarative event handling": Instead of creating a mess of nested jQuery "bind" or "delegate" calls, it's nice to just declare what elements in a view should be hooked up to specific callbacks:
"RESTful JSON interface": The persistence strategy for Backbone can be swapped out for something different (Websockets, Local Storage, CouchDB), but the default is to fire off a standard JSON Ajax call when you call "model.save()"...
It means that Backbone provides a way to cleanly separate your model/data from your presentation such that your model is concerned with synchronizing state with a server and the view is concerned with listening to changes in that model via data binding.
Totally! I can't wait to replace my own internal model classification stuff with this (or at least play around with it in that sense) to go along with jQuery. I've become accustomed to the jQuery way of handling the DOM so it's nice to see something agnostic to that. I'd rather avoid a one-size-fits-all js library to be honest ;)
I really like the approach here of extracting the core functionality of js mvc and data binding without the bloat of a huge framework. I plan on using this on a project soon. Well done jashkenas and co!
Yes. I recently discovered js-model while wrapping up the Backbone documentation. The two libraries are extremely similar, and share the same core idea, but with that said, here are some of the differences:
* js-model is explicitly inspired by Rails' ActiveRecord models, and a lot of these points fall out from that fact...
* Backbone sets up the prototype chain so that you can continue to extend (subclass) your Models, Collections, and Views.
* Backbone includes a richer set of enumerable functions, based on Underscore.js, so you get native performance in browsers that support them natively.
* js-model's validation and errors API mimics Rails' Errors object, which may or may not be what you want.
* Backbone includes Views, and js-model sticks to models.
Similar but it does seem to conflate the idea of a Model and a Collection. Also the instance changes API in js-model prefers an interface based around instance mutability instead of presenting the old and new value in a functional manner to the callback.
BackBone.js Models are also mutable. This is probably the only part of the design I would have handled differently at the cost of responsiveness in browsers with slower JS engines. In my experience it's too easy to accidentally corrupt the data which populates many UI components if you're passing mutable references around.
So if we were designing the Twitter front page with Backbone, we would have models like TrendingTopics, WhatYouDoing, NewMsgs and some more. They would be updating against the server using JSON, and calling some render code so they redraw themselves when there is new data.
If we didn't have Backbone, we would probably call a main JSON sync function repeatedly, and iterate on this new data updating the different parts of the page "manually".
There, Recommendations, Friends, Followers, and Memberships are the models, and render off the contents of that JSON. Of course, Twitter should really be bootstrapping all of those bits of JSON into the initial page load, instead of firing off six requests immediately...
However (and this is another conversation altogether), I don't think that you really want to structure your client-side application around faux-routes. Maintaining browser history with "hashchange" is important, but hardly the central aspect of a JS app. Usually you want to reserve history changes for special states that deserve to be bookmarked, not for every single action performed.
For the record, this is the little module that we use to record and listen for "hashchange" events:
Can you please expand on this? I don't get it: do you think something like newtwitter is badly designed because it uses faux-routes? If you don't have faux-routes then how can you easily insert links which will "go to page X" ?
Not at all -- hash-based URLs for Ajax applications are critical. They're just not something that you want to structure your entire application around, and Sammy is a framework that uses faux-URLs as the central abstraction.
All I'm saying is that you don't need to ape the server-side paradigm (one URL, one page) quite so closely. Use a module that gives you URL setting and tracking with "onhashchange", by all means, but you don't have to shoehorn your application into it.
Offline support is up to the developer -- there are many applications where the notion doesn't make sense: imagine an offline Google or and offline Twitter. But having nice logical models certainly helps organize an offline application.
The first thing you would do is override Backbone.sync to save your models to Local Storage instead of the server: