Shouldn't the first example read:
george.roar(); // displays: "George, the lion ROARS!!!"Simple JavaScript Inheritance with Backbone
11–19 of 19 posts
Re: Simple JavaScript Inheritance with Backbone
#12Shouldn't the first example read: george.roar(); // displays: "George, the lion ROARS!!!"
You're right! Fixed. Thanks for letting me know.
Re: Simple JavaScript Inheritance with Backbone
#13You can also use CoffeeScript to get more "traditional" OOP from JavaScript.
CoffeeScript does have really nice syntax for OOP, but I think JavaScript deserves some lovin' too. Well-written JavaScript (such as Backbone) looks pretty beautiful. Another plus is that new devs (if you have to worry about that sort of thing) don't have to learn a new language.
Yes, that would be me. I'm still getting my head round Javascript, cant take something new on at the moment.
I havent even learned what inheritance is yet, so have no idea how Backbone.js would benefit me, even though im working on a project where i need to use a class.
Re: Simple JavaScript Inheritance with Backbone
#14I've just started down my path of really learning JavaScript. My first stop was "JavaScript: The Good Parts", and the author there really advocates using closures to define objects and enable encapsulation. It seems in practice this approach isn't used often (such as Backbone here), why is that?
Take a look at the source-- Backbone itself is written in the module pattern.
Underscore and Backbone will both teach you a lot. This chapter from Eloquent Javascript will also help motivate the rationale behind Underscore:
Re: Simple JavaScript Inheritance with Backbone
#15I've just started down my path of really learning JavaScript. My first stop was "JavaScript: The Good Parts", and the author there really advocates using closures to define objects and enable encapsulation. It seems in practice this approach isn't used often (such as Backbone here), why is that?
The mostly likely reason is probably familiarity. Most languages use the 'new' operator to create new objects, so it seems natural to follow the same pattern when creating a JS API that will likely be consumed by people who come from other languages.
The main advantage of Douglas Crockford's power constructor pattern is that it allows truly private variables or functions. I used to be adamant that this was the right way to go (and I still appreciate the pattern), but then I found that just following the convention of prefixing private members with an underscore worked fine--most people understand that it means "private". My code also started to look a little neater. All of my instance members are actually tied to the 'this' context object, rather being spread between nested functions or local variables declared within the constructors, and public/privileged methods declared on the new object itself.
Re: Simple JavaScript Inheritance with Backbone
#16I've just started down my path of really learning JavaScript. My first stop was "JavaScript: The Good Parts", and the author there really advocates using closures to define objects and enable encapsulation. It seems in practice this approach isn't used often (such as Backbone here), why is that?
Performance. If you have n objects with m methods, that creates n * m function objects. With "normal" prototypal inheritance where those methods are on the prototype, it only requires n objects + m functions.
Re: Simple JavaScript Inheritance with Backbone
#17I've just started down my path of really learning JavaScript. My first stop was "JavaScript: The Good Parts", and the author there really advocates using closures to define objects and enable encapsulation. It seems in practice this approach isn't used often (such as Backbone here), why is that?
Performance. If you have n objects with m methods, that creates n * m function objects. With "normal" prototypal inheritance where those methods are on the prototype, it only requires n objects + m functions.
As always, munificent is right on the money.
The "closure pattern" is one of the most serious JavaScript anti-patterns -- it doesn't make much of a difference in tiny scripts, but for any decent-size JavaScript application, it can hurt performance terribly, especially regarding memory use.
For example, benchmarking the creation of 1 million objects, each with 10 member functions, in both the prototypal style and the closure style (in Chrome):
1 million prototypal objects: Brief pause, 32.4 MB
1 million closure objects: Minutes wait, 368.1 MB
For more info, here's Brendan Eich on the subject:
Re: Simple JavaScript Inheritance with Backbone
#18Earlier quoted context omitted.
Performance. If you have n objects with m methods, that creates n * m function objects. With "normal" prototypal inheritance where those methods are on the prototype, it only requires n objects + m functions.
As always, munificent is right on the money. The "closure pattern" is one of the most serious JavaScript anti-patterns -- it doesn't make much of a difference in tiny scripts, but for any decent-size JavaScript application, it can hurt performance terribly, especially regarding memory use. For example, benchmarking the creation of 1 million objects, each with 10 member functions, in both the prototypal style and the…
I don't even know if this can be considered the "closure" pattern anymore, but I wanted to try to get method sharing among the objects by doing something like this: https://gist.github.com/877259
The hope was that since the functions were created and bound within the function literal, the "create" method could simply assign references to the existing functions instead of creating a new function each time (ie, avoid what munificent mentioned).
Funny thing is, even though the last line indicates that the first and last objects' "ten" method is actually shared between them, I'm still getting about 370 MB of memory usage after creating 1 million objects. I am under assumption that the cause of this memory increase is the fact that each one of the million objects has its own local references to each of the 10 functions. When I put the 10 functions inside of the "create" method, memory usage goes up again to roughly 750 MB.
Re: Simple JavaScript Inheritance with Backbone
#19Earlier quoted context omitted.
Performance. If you have n objects with m methods, that creates n * m function objects. With "normal" prototypal inheritance where those methods are on the prototype, it only requires n objects + m functions.
As always, munificent is right on the money. The "closure pattern" is one of the most serious JavaScript anti-patterns -- it doesn't make much of a difference in tiny scripts, but for any decent-size JavaScript application, it can hurt performance terribly, especially regarding memory use. For example, benchmarking the creation of 1 million objects, each with 10 member functions, in both the prototypal style and the…
That was a really interesting talk--thanks for the link!
Something that initially confused me was that Eich's use of the term "prototypal" (a pattern for implementing class-based inheritance) was different from Douglas Crockford's use of it (an alternative to class-based inheritance - http://javascript.crockford.com/prototypal.html).
In case anyone else finds this useful, here's how I sorted it out:
- "class-based" & "prototype-based" inheritance (Crockford refers to them as "classical" & "prototypal" inheritance). Different styles of instantiating objects.
- "closure pattern" & "prototypal pattern" (aka "prototypal inheritance" in this context). Different techniques for implementing class-based inheritance.