Refactor The Model Base Class with Mixins

Hi.

I strongly disagree with recommending, even implicitly, implementing language features yourself as part of your own project. While it might be a super-cool thing to do as part of a short tutorial getting it right is extremely hard and is therefore extremely likely to cause a huge headache for those who try it.

An excellent write up of the complexities involved can be found here: http://www.lazutkin.com/blog/2012/01/18/oop-and-js/

I would strongly suggest amending this lesson to recommend using a stable library that has worked out the kinks, like the one in the link. Trying to do it ad-hoc yourself is a recipe for disaster unless you are a true javascript expert. And even then it is wasted effort since it has been done already.

The mixin approach is described in detail in this lesson, and gets into more depth with regard to the "why" of a mixin. It also addresses the concern that the (excellent) article you linked to discusses with regard to mixins.

I've used this approach quite a bit without issue in real live code.

Well being a teacher here might qualify you as being pretty much a javascript rock star :) But do you really think "write it yourself" is the best approach to recommend to readers here that want to be able to use mixins?

When talking about extremely complex "wheels" I would really recommend using existing wheels that have been implemented by experts and proven by time and testing rather than rolling your own.

Not trying to start a flame war here, No discussion that the technique is useful etc. I'm just disagreeing about the strategic wisdom of using "roll your own" approach to this and even more to recommending the "roll your own" approach to learners of an unknown skill level.

Perhaps we should just agree to disagree :)

I agree with you completely in that you should understand the process and what is occurring before blindly "rolling your own" solution. There is value in working towards that understanding as well, which is fundamentally the point of the lessons.

No warranty, expressed or implied ;)

(I'm no JS rockstar, I learned this approach via Brett's lessons!)

Magnus- Couldn't agree with you more about many points here. Especially in the JS community, there's a serious case of Not-Invented-Here Syndrome; the sheer number of JS frameworks is good indication of that. In the Javascript ecosystem (and most ecosystems for that matter), it's important to choose the right tools for the job, and not to re-invent the wheel when you don't need to.

I've tended to learn best by understanding the layer beneath the one I'm using. I love articles like the one you shared; I picked up most of my knowledge on JS inheritance from the wonderful Douglas Crockford in his many articles (in particular, I love this one http://www.crockford.com/javascript/inheritance.html).

I tend to teach topics this way because it's how I learned, and I try to create the tools that I would have wanted when I was first learning. I'm not as aggressive about "learning the practices" as some of my peers (who think things like http://youmightnotneedjquery.com), but my heart's in the same place--I think it's important to understand both the practices and the right tools for the job. It's a lot harder to write a video on a recommendation of a tool chain, since it addresses a smaller subset of users, but that doesn't mean that these tools aren't important.

Thanks for bringing it up. It's good discussion material for folks here :)