One of the patterns looks like it requires more processing power than necessary. The rendering of a template should be fast, since you will likely be doing it many times on a page.
ContactView = Backbone.View.extend({
template: function() {
var template = _.template($("#template-contact").html());
return template.apply(this, arguments);
},
render: function() {
// This is a dictionary object of the attributes of the models.
// => { name: "Jason", email: "j.smith@gmail.com" }
var dict = this.model.toJSON();
// Pass this object onto the template function.
// This returns an HTML string.
var html = this.template(dict);
// Append the result to the view's element.
$(this.el).append(html);
// ...
}
})
Note that the template is already on the page and has to be serialized by jQuery with the `_.template($("#template-contact").html());` line. It would be faster to already have the template in a JavaScript string, ready to be interpolated with your values.
Otherwise, for every view you will be fetching the template from the DOM. The difference in implementation would be from this:
<div id="template-contact">Mail me at <%= email %></div>
to this:
<script>var templateContact = "Mail me at <%= email %>"</script>
It's a bit more work, but it reduces the amount of work that has to happen just to render one of many templates.
Nice... I am writing my first site using backbone and as a Java Dev sometimes I have a hard time to do things in backbone, I want to make everything a into reusable objects and views as far as I am seeing right now are not always to be used like that.
Sometimes They are used to listen to collections and create smaller things( like a factory ) sometimes they can represent a whole small popup, sometimes a single HTML entity.
I am sure my code is not 100% yet, but patterns like this help a lot.
Not sure why you're being downvoted, but I tend to agree. I've found that my backbone apps are a lot nicer to deal with when I think of my views as potentially re-usable components.
It takes a bit of forethought but you end up with much nicer, composable interfaces that allow you to respond quickly to changing requirements.
I know in the javascript world there's a preference by large to use camelCasing but I'm not a fan of it. I don't think its easier to read, and there can be confusion with what to capitalize.
Also whats the purpose of putting your templates inline? I compile all my templates server side into a js file called template.js and when I need a template I simply call:
Notice how this carefully doesn't use silent: true, seeing as in the latest version of Backbone, they have repurposed the silent option for completely different functionality.
Not quite. (Although you and I have certainly discussed this plenty on GitHub.) For folks who haven't been following along:
Performing "silent" changes to a model are a power-user feature of Backbone, where you can twiddle attributes on a model temporarily, or many times, without receiving change events. Then, when you're ready, you get a single change event with the diff in model state.
Prior to 0.9, you'd get the single diff, but not all of the individual "change:attribute" events for the diff. 0.9 and above have been improved to give you both. Yes, it's something to watch out for if you want to upgrade an existing app.
The problem is your complete unwillingness to compromise and to make it easier for people to upgrade an existing app.
The way that silent works now should be it's own option, say "defer". Because you're deferring the changes until a later date. It could even be called delay or later. Whatever it is called, it is in no way silent anymore.
My proposal is to add a new option, mute, which bypasses the change events and causes the attribute to change but does not trigger change:attribute.
While I appreciate the effort and persistence, having {silent: true, mute: true} be part of the model API is definitely not the direction that the Backbone API should be going.
That said, what you do with your copy of backbone.js in your own project is your business. I'd highly encourage you to extend your version with your preferred behavior for "silent" -- in fact, the source is annotated to make this sort of thing easier for folks that find the need.
This is nice to have it in one place, but I still not sure I like bootstrapping model data that way. Does anyone else find it a bit messy? Also, I'm using AMD/Require.js throughout my Backbone apps, so how could I bootstrap the model data in that manner, and still have access to it inside my modules?
... is because, all else being equal, it will noticeably improve the speed of your initial page load. Instead of N separate HTTP requests, all of your model data is available in the same HTTP request that fetches the HTML. Put the bootstrap at the bottom of your page, and you're in pretty good shape.
Depending on the other content of the page and the nature of your traffic/user data, it might make more sense to take advantage of caching by making the initial loaded resource (the HTML file) completely static and loading the bootstrapped data in a single separate request.
Yes, absolutely. If the initial HTML page is heavy, and can be cached for all users, then separate makes sense. If the initial HTML page is light, or user-specific (the usual case for a backbone app) then bootstrapping in a single HTTP request makes sense.
You can define a requirejs module that just consists of data: http://requirejs.org/docs/api.html#defsimple. Then in your app incantation (main.js for requirejs stuff), load this module and pass it to your app instance.
2. Make your 'top-level' view bind to a collections 'reset' event that fires once the model is loaded. At that stage you can give instances of the loaded models to whatever views need them and they can redraw themselves, either by calling a method on them directly or because they're listening for some event that you trigger.
Im still walking the backbone path so this is pretty useful.
Im curious how one would setup a instant search using it? I have done it previously by attaching a jQuery keyup event listener but I know I should be using a view. I have had a poke on google for this but haven't turned up anything.
I'd like to nominate private subviews as a pattern.
(function(){
var myPrivateView = Backbone.View.extend({...});
app.views.Foo = Backbone.View.extend({
/* use myPrivateView somewhere in here */
});
})();
It's a good way to break a view into logical sub-components, while still only exposing one overall view to the world. Really just a variation on data hiding and encapsulation.
I have a hard time seeing the advantages of backbone.js over something simpler like knockout.js. Is it that good? Is it a question of having a complicated enough webapp?
The Backbone link goes to a "who is using Backbone" page. Which is nice, and quite convincing that Backbone is a serious library used in some huge projects.
The Knockout link, however, goes to a "how do you use Knockout" page. Which is also nice, and a very useful documentation source that Backbone is sadly lacking.
But as a new developer, if anything, the Knockout link is a better reason to pick it. Good documentation goes a LOT further than knowing that Groupon has selected the library, in my book.
First, both Backbone and Knockout are very simple, and if anything Backbone is simpler than Knockout. Neither is rally comparable to a full framework like Rails or Django, and neither has much "magic" either. Both could be replaced with a very small collection of standalone JS libraries.
Backbone is, basically, just some "smart" models and collections that know how to consume and persist to a REST data source, and a router. If you want anything else - like templates, or any support for relational data, or two way binding of your data to your rendered HTML, then you need to turn to standalone libraries or plugins, or just write it yourself. (Note: There's some kickass template libraries around, but in my experience the only data binding options are Backbone.ModelBinding and Synapse, and neither of them is production ready. I also had a bad experience with Backbone relational. YMMV) Also, Backbone is, by design, very much NOT opinionated. You can structure your code however you want. That's good if you know what you're doing, but a pain in the ass if you're coming at it fresh from Django or something.
Knockout is, basically, just a fantastic data binding library with integrated support for a decent template library. If you need smart models, or to persist stuff to a REST data store, or routing, then you need to use standalone libraries or roll your own. (Note: Writing your own code to load and save models is actually easy. And as far as routing goes, there's a million solution. I like Sammy though.) Also, it's a little more opinionated, and I like the docs better - they give concrete examples of how to do things, rather than vague "some people like to implement this via X, but others prefer to Y" hints, like Backbone.
In short, neither is going to give you the full set of tools you want; you should pick the one that is more closely tailored to what you are planning, but always keeping in mind that you're going to need to fill in a lot of gaps yourself. (Hell, some people use both libraries at once; there's actually not a lot of overlap.) So it's not really a question of how complicated the webapp is, but more a question of what kind of webapp it is, and what features it needs.
If I was going to write a streaming music player (or something else that basically needs to be a simple GUI over some very complex JS code), I'd be inclined to turn to Backbone. I believe Pandora used Backbone for their recent interface rewrite, and PeepCode has an excellent series of tutorials showing someone building a music player in Backbone you can follow along with.
On the other hand, if I was building any form of CRUD app, especially one with a very complex or rich interface, and especially one that needs to edit deeply nested relational data, I'd be strongly pulled towards Knockout. You could do it in Backbone, but you'd do it by, basically, rewriting the core of Knockout in your own code, while getting only minimal benefit from Backbone.
TL;DR summary: Neither is really simpler. Neither is more appropriate for more complex apps. They solve different problems. (But personally, I had some pretty complex problems to solve, and after struggling with Backbone for weeks because all the cool kids were using it, I eventually rewrote my app in Knockout, and breathed a sigh of relief. More functionality in less time with fewer bugs and prettier code. But that's me, for my app. Different programmer or a different app? Different story. And keep in mind there's like, 15 different JS frameworks out there, some of which also look awesome. Serenade and Ember in particular...)
This is nice! Been using backbone for about a year, and often I wonder if there are better ways. I'm learning a lot of new solutions by reading this. Thanks.
Otherwise, for every view you will be fetching the template from the DOM. The difference in implementation would be from this:
to this: It's a bit more work, but it reduces the amount of work that has to happen just to render one of many templates.