At Digg we use jQuery extensively, but it doesn’t offer a much in the way of Object-Oriented JavaScript. Existing OOJS libraries weren’t a good fit — often trying to shoehorn traditional OOP patterns in where they don’t quite fit — so we rolled our own. Class adds OOP patterns to jQuery, modeled after the original Class object in Prototype but with significantly greater capabilities — including namespacing, limited classical inheritance and more robust prototypal inheritance.

Interesting but I don’t see the point in piggybacking on jQuery’s abstraction? I think your class-based implementation is quite suitable on its own.

I never really understood the point in trying to make JavaScript something it’s clearly not. Prototypal inheritance CANNOT go hand in hand with classical – consigning to one is the only way in my opinion.

Building complex applications with inheritance is a pain if you use the strict prototypal way. Mainly because calling super class methods needs to be something like MyClass.prototype.myMethod.call(this, args); Or even worse if you use name spaces it would be something like: mylibrary.mynamespace.MyClass.prototype.myMethod.call(this, args);
when it could have been: this.parent(args); or this.Super.myMethod(args); if you use a OOP framework.

The latter expression will always evaluate to `true`, since `typeof` always returns a string. Did they forget quotes around `undefined`. It’s also not clear why there is a limitation of `constructor` being an Object. What if I want to pass an object that inherits from `Object.prototype` but doesn’t really have `Object` as its `constructor`? It would be better to check for either [[Class]] or use `typeof`.

I also don’t see how it’s modeled after Prototype.js. Prototype.js uses `beget`-like pattern for inheritance. They, on the other hand, seem to manually iterate over methods with for/in. Those are 2 completely different approaches.

There’s also no fix for JScript’s DontEnum bug, which might bite them one day. I also couldn’t find any unit tests…

Hmm…didn’t a library have a class system in it years ago natively that rocks, keeps code organized, introduces custom events and chaining in a integrated fashion???

Oh yeah Mootools! that’s right!

Here is my analogy for this article:

When IE first did tabbed browsing lay people everywhere were like “Oh my god tabs how awesome.” I can vouch, I still have friends who aren’t working in internet technology who think FireFox is the one doing the UI and functional copying…

So I see this post, and so many recently, in much the same way, namely: “Oh my god look what you can do with jQuery, brilliant!!!” – make sure to read emphatically like a guinness commercial puppet for full effect.

Using Google more would solve many problems folks, there is the whole new world out there beyond the little js lib box. (don’t bust my balls over the chance Aladdin reference). I mean I don’t use jQuery much but I read John’s blog sometimes and try and stay up with developments they do…

Meh. Why not just use the power of the language itself? Could you justify to a software architect this approach? To the argument that this would create a codebase that would not work exactly (note: exactly) in the way someone from a classical OO background would expect, and would be confusing for those who weren’t (ie. the massive pool of developers who are trained in javascript), what would you say? To a recruiting manager: how would you explain that you’ve architected a codebase which makes it more difficult to find cheap talent, for zero performance or other benefit? Do you believe debugging will be more difficult by injecting this sort of inheritance into another sort of library model *on top of* a language which *both* of these layers abstract, differently? Does the added complexity, man-hours and other negatives go away due to some benefit? And what is that benefit?

I coded things in regular old script before using a lib (not for long, it sucks) and even used Mootools without digging into the Class framework for quite a while. The thing is when I started using classes the pieces fit together so seamlessly. Binds, mutators, chaining, binding with custom events, extensibility of the code, DRY, reuse++, modularity, class inheritance and extends, it makes it a snap to do just about anything cleanly and efficiently with little fuss.

I would never go back, ever. Just a different world when you dig into it.

The first and most important thing to say is that I am glad that you see the value of a consistent development model. That being said, I leave you with some Crockford, in particular the last bit, and the thought that it is to me ridiculous to say that the most popular language in the world has a model that is hard to use:

JavaScript can be used like a classical language, but it also has a level of expressiveness which is quite unique. We have looked at Classical Inheritance, Swiss Inheritance, Parasitic Inheritance, Class Augmentation, and Object Augmentation. This large set of code reuse patterns comes from a language which is considered smaller and simpler than Java.

Classical objects are hard. The only way to add a new member to a hard object is to create a new class. In JavaScript, objects are soft. A new member can be added to a soft object by simple assignment.

Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.

I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.