Perhaps I missed the point?
When I was putting this together, I kind of felt like I was writing a general article on one method of exploiting polymorphism--not necessarily the Strategy pattern specifically. Honestly, I'm still not sure.
What I do know is that JavaScript has a number of features that make OOP significantly more informal--namely dynamic typing, object literals, and first-class functions. I'm thinking of implementing more patterns in JS in the future to try and get a better grasp on this...
I think jbwyme is getting at this with his comment http://news.ycombinator.com/item?id=2680408 (specifically "Then, if needed, use a prototype to set defaults"). Using the prototype is not really necessary at all, but it adds some amount of formality to what is otherwise a ragtag collection of objects.
"This leads many seasoned programmers to respond with, “well, duh” when first confronted. Design patterns are derived from scrutiny of best practices in the real world (not your old CS prof’s black cauldron)."
SomeComponent.prototype.views = { home: { template: '/path/to/template', render: function(tmpl) { this.element.html(Mustache.to_html(tmpl, this.data)); } } };
I then have SomeComponent inherit the prototype of Component which has a generic render method. When I call the render method on any given component, it will have some logic to figure out which view it is in, then call the render method specific to that view with the correct template, that it fetches the content of under-the-hood.
Having consistent and expected behavior in your code is a huge win.
