So, my twopence worth: in the short term I would deploy jQ for certain aspects of development simply for the sake of time, expediency and compatibility with other coders code, but from an academic perspective, and for the long game, I would want to study and implement MT + vanilla.

In the end its just the style, features and preference.

This is a language that HAS PROTOTYPING for a reason Captian Obvious! Even Crockford has written enhancements by prototyping, I cry a tear :p for the haters! This whole “purist, prototyping in JS is wrong” thing is complete BS.

Anywho, the word “Class” is just a word. Words don’t even really exist anyway folks; a chair is a ‘chair’ because some stupid cave man made a rock that was cool for sitting on and had to call it something more than a grunt! Stop throwing up all these lame logical fallacies to boost a baseless argument against an intended feature of JavaScript.

For the rest of the argument: I’ve never said anything such as Mootools trying to be something its not. I haven’t said either, that Mootools was stretching the language, and it would never occur to me to say what’s “the intended use of a language”. In fact, I haven’t made any criticism to Mootools in particular.
I’ve criticized: 1. As a personal preference, the fact that some frameworks/libraries feel the need to approximate class based inheritance. 2. What I think is a small inconsistency in this article (not in Mootools): arguing against a particular style promoted in one library because it “feels too different to the language”, but arguing in favour of the other library because it approximates something (or, if you really want it that way, “uses a certain terminology for some things but in the end it’s just an API”) which I feel is quite different to the language (classes and instances).

I’ll end my part of the discussion here (because I don’t see this getting anywhere). I’m really sorry if any of you have felt in anyway aggravated or have felt your favourite library was being criticised or whatever.

As a matter of interest (really, truely); what terms would you use to describe his example?

In JavaScript if we have obj1 and obj2 and we set obj2’s prototype to be obj1, what do we have? What is obj2? What is obj1? child? parent? inheritor?”

One of the things I like about Prototype’s OO is its “$super” for referencing the parent’s constructor and methods. I am not even sure if it can break anything in the process, but so far, so good. I do make plenty of use of “$super” in every class I create because every class I create has to depend on a common ancestor so it’s a flat hierarchy, it can be two or three classes deep even though deeper than that is a little rarer.

To me, OO in JavaScript works like Ruby’s OO to some extent given my tweaking of it so I am pretty happy as I understand the shortcomings.

Also, I know folks who plead “prototypical inheritance” and “Java style classes” won’t find what they could probably want when I make use of this OO thing provided by Prototype and some tweakings.

I find it kind of funny actually. Folks who don’t want any classes means that they want the “flattest” programming experience possible, which also means that I would not want to see their code. Folks who want Java style classes will end up with some of the worst experience when they try to bend JavaScript too much to their likings, and will not understand why they are in the minority.

Cheers.

@doublerebel – You write:

Hmm. I could easily implement MooTools’ hover syntax in jQuery in just a few lines… but who would want to? There’s a reason people are developing jQuery syntax for MooTools and not the other way around!

I doubt it. jQuery is a subset of MooTools functionality. This is not meant as a negative statement (indeed, for many, it is a positive thing). But this is one thing that MooTools can do that jQuery cannot. You cannot implement MooTools with jQuery; jQuery’s scope is focused on the DOM. While you can certainly duplicate MooTools, you’d be doing it in vanilla JavaScript. Again, this isn’t meant as a negative statement. But it is a limitation of jQuery (not a fault!).

I’ll reiterate what I say in the article, MooTools nor jQuery are different, with different purposes and different philosophies. I did my damnedest in the article to convey this point effectively and to assert that neither framework is a poor choice to learn (ideally, people would invest time to learn them both before making any decisions). I have a personal preference that falls in line with MooTools, but there are certainly things about it that can be much better, just as the same is true of jQuery. That’s why we’re still iterating on these frameworks.

Discrediting MooTools because it embraces prototypal inheritance, a mainstay of the language, is a matter of preference, not fact. jQuery’s lack of this functionality (and again, I’m focused in the article on the cores of both frameworks) is a deciding factor *for me*, but that’s ok. If you don’t like this pattern, don’t use it. That’s kind of the whole point of the article: both are different and different philosophies and choosing one is more a matter of personal taste than it is one of merits and demerits of each library.

I would be very surprised if you could tell who has read tfa, but I for one, have. And have read such things as “You pass Class an object (above, we pass an object with members like “isAlive” and “eat”) and this object becomes the prototype of every instance of that class. To create an instance, you call it like this: … ” (emphasis mine). I might entertain your claim of it being just an API over prototypal inheritance, but then again if he talks about classes and instances, I tend to believe otherwise.

MooTools Lets You Have It Your Way

Hmm. I could easily implement MooTools’ hover syntax in jQuery in just a few lines… but who would want to? There’s a reason people are developing jQuery syntax for MooTools and not the other way around!

jQuery doesn’t have class-based inheritance in the core, you can find it in the LowPro plugin. I would argue jQuery is built to be the more maintainable and reusable of the two languages — jQuery code reads like English to me, and the sharing and support from the plugin community is amazing. Even Aaron notes that with jQ “it’s easy to get started and see quick results but…can turn into code that’s harder to reuse and maintain (but really that’s up to you; it’s not jQuery’s problem, per se)” (Emphasis mine)

jQuery is extended properly with plugins where needed. jQ is easy to use, that’s why there are so many bad examples out there. Many inexperienced coders use jQ, that doesn’t mean jQ is any less powerful.