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.
That one is supposedly inspired by base2: http://code.google.com/p/base2/source/browse/trunk/lib/src/b...
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.
N+1 across the internet will suck.
I assume it's early days, but please consider this issue. It's killed a bunch of otherwise interesting libraries.
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...
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()"...
Hope that helps a little.
For anyone unclear about REST, try this: http://tomayko.com/writings/rest-to-my-wife
Edit: It looks like it's taken straight from the source (http://github.com/documentcloud/backbone/blob/master/backbon...) using Docco: http://jashkenas.github.com/docco/
IDE support is still kind of lightweight, but there are several options out there: http://haxe.org/com/ide
I use Geany, because I only really need context-sensitivity, highlighting, and search+replace.
* 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.
Backbone looks like it forms a much more cohesive package though, which is nice.
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.
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".
Is that it?
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:
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.
Todo = Backbone.Model.extend
@get("status") is "done"
@set status: if @done() then "active" else "done"
Isn't this the kind of thing that coffee would be aimed at?
The first thing you would do is override Backbone.sync to save your models to Local Storage instead of the server:
But if you are doing something public facing, you can get it indexed by Google with a little elbow grease:
"New Twitter" takes this approach.