Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
What’s so funny ’bout pseudo-classical inheritance (in JavaScript)?

Our customers are asking for richer interfaces and user experiences. And so we – and by “we” I mean the Rails development community – are writing more and more JavaScript. We’ve gone from ignoring JS (using RJS server-side) to rendering JSON and writing our own jQuery plugins.

But in this transition some of us left our objects & design patterns on the server. Just because you’re writing a click handler in JavaScript doesn’t mean it couldn’t, or shouldn’t, be a method on an object.

If you have a long-lived page, its data are clamoring for object orientation. That data needs to be loaded, reloaded, and paginated via AJAX calls – why build that code (or that interface) more than once?

What about APIs that you’re accessing via AJAX? Wrapping an API in an object means you can more easily mock out the actual service in test and keep all the parameter logic separated from your data models. Or even more exciting, you can reuse your API code on the server (thanks for the timely example, Dion!).

JavaScript already has objects, but how do you organize your code in a more object-oriented way?

I’m a fan of a more Pseudo-classical approach to my JavaScript. (Sorry, Mr. Crockford, but I’m spending nearly all my time in Palm webOS these days and Mojo new‘s my objects). I’m not a fan of Prototype.js’s Class.create$super is awkward, puts too much responsibility on the coder, the errors you get when you forget one are confounding, I don’t need to rename my constructor…the list is a bit longer, but you get the idea.

Instead we use JavaScript prototypes a lot like Ruby’s Classes – objects that implement common “class”-wide behavior. We setup an inheritance graph between child & parent prototypes – much like Google’s Closure. And we explicitly call functions on parent prototypes when we need “super”.

The result is a set of techniques that behaves enough like Classical inheritance for us to be productive. More importantly, we like it and the code we write with it – if there’s demand, I’ll write up an example.

Defining objects for purposes of encapsulation, abstraction and ease of testing (no matter the technique) is not only possible in JavaScript, they (surprise!) offer all the same benefits they do in other languages: less code that’s more robust and that you don’t mind extending & maintaining.

Why else is this important now? THE FUTURE.

Writing HTML5/RIA/MobileWeb applications in JavaScript is different than Rails/MVC web development. In order to make our code manageable we’ll need and want to crib from the object-oriented patterns of desktop client development.

But that’s another post.

  • Here’s a simple method for doing JavaScript inheritance, which doesn’t rely on directly accessing __proto__ (so it should work in e.g. Internet Explorer), and heeds some important advice from Mozilla not to call ParentClass() to create ChildClass()’s prototype.

  • Davis W. Frank

    Thanks, Clay.

    That’s close to what we came up with. We do an extra step to ensure the `.constructor` property is as expected. And we did not go the extra step of the`.__super`, but recent refactorings have us thinking of doing something similar.

  • Yes, please! I’d love a full example. And eventually, that other post you mention.

  • Steve Conover

    A nice unit-testable class that has, say, < 5 constructor inputs, 1-10 public methods, and 0-5 private methods, 0-7 instance variables will, I predict, be a good solid organizational paradigm far into the future, across languages.

  • I’d actually love to see an example of your coding style as well.

Share This