Object Oriented Programming in JavaScript. Is there life without it? [duplicate]

Question

At our company we have pretty large body of PrototypeJS based JavaScript code, which we are porting to jQuery for several reasons (not really important here). I'm trying to set up coding guidelines to make/keep things tidy during the porting.

One observation from wading through the prototype based implementation is that a lot of code is written in OOP style (using Prototype's Class.create), but the code is not "object oriented" in spirit. The general pattern I've seen: one "constructor" which you are expected to call (but not call twice, because the constructor uses hardcoded DOM id's), a bunch of other "functions" and event handlers, which you are not expected to call (but the because there is no "private" in JavaScript, you don't know that) and data sharing between all these functions through this. Seen from the caller's point of view there is just one "callable" and nothing else.

I'm starting to believe that OOP in JavaScript can and maybe should be avoided in a lot of cases. At least for our use case, which is not the next generation Goole Wave UI, but simply put: a bit of AJAX based enhancements, registering some event handlers here and there, minor DOM manipulations and such.

• the functionality we need seems to be implementable just fine in the typical jQuery non-OOP way, using closure magic to obtain encapsulation and privateness. As side effect, the minification efficiency of the ported code is much better.
• OOP in JavaScript is non-traditional and confusing if you are coming from a "traditional" background. There are a lot of attempts and frameworks to approximate traditional OOP, but IMHO this makes things even more confusing and fragile.
• One thing that Crockford's "JavaScript the good parts" taught me, is that the true power of Javascript lies in function scopes and closures, much less in OOP patterns.

I'm wondering if there is wider support for this feeling that OOP in JavaScript doesn't really cut it as the sacred mantra, like it is in other languages/platforms. And, in extension, what kind of non-OOP/closure based patterns are much more preferable.

Answer 1

People tend to get caught up in advanced patterns with OOP. MVC, MVVM, MVVC and every other permutation of 'M', 'V', and 'C'. I've never opened up a js project with 20,000+ lines and said to myself: "Thank god this is in MVC", because the reality is that most projects with 20,000+ lines are going to be a terrible mess.

Having said that, I still think large projects are almost impossible without OOP. At the very least, the ability to write complex objects and store them in separate files and namespace-protect them from collisions using a library like dojo will save you thousands of hours of painful debugging.

"Oh", you might say to yourself, "Well, I can write modular groups of functions in separate javascript files with the best of them. I don't need to use OOP." Well, my friend- congratulations, because you're already effectively using OOP without even knowing it. So as long as that's the case, why not just go one step further and use actual classes?

It's true that javascript relies on the prototype model, however, the base of OOP is pretty much inheritance/encapsulation/polymorphism, and javascript can do that perfectly well. Take a look at dojo.js.

Answer 2

I feel it's important to point out a couple of things:

1. OOP and classes are two fully orthogonal concepts. Classes could just as well work with structs/records (and in fact they do in some languages). They incidentally happen to be useful for constructing specific kinds of objects.
2. Access control is a nice tool for encapsulation, but it's not a prerequisite. In JavaScript it's common to prefix "private" members of an object with an underscore. Whether or not you choose to access those anyhow is for you to decide. In most languages there are some means to get past access control if you really want to. It's just a really silly thing in general to write code against something that was never consciously exposed by a human being for you to consume (and can for example change at any time).
3. OOP is certainly not about how specific parts of your system are implemented (let alone the syntax involved) and I would thus argue that the implementation cannot be "object oriented in spirit" or not. OOP is mostly a relatively clever mechanism for indirection built on encapsulation and polymorphism. In essence, it is little more than "Tell, Don't Ask".

If you want to jump through hoops to turn JavaScript into something it isn't, you may be unhappy with the result. So instead, you could pick any of the available languages that compile to JavaScript but are closer to what you might want a programming language to look like (Haxe, ParenScript, TypeScript, CoffeeScript, ScriptSharp, Dart, Java (through GWT), C/C++ (through Emscripten) ... in fact almost any other popular language can be translated to JavaScript with varying quality).

But if you use JavaScript for what it is, you will find a language that allows "class-oids", mixins/traits, AOP and what not. More often than not, you will realize than limiting yourself to Java-esque idioms might not be the best idea. Nonetheless, they undoubtedly come in handy at times.

Answer 3

One observation from wading through the prototype based implementation is that a lot of code is written in OOP style (using Prototype's Class.create), but the code is not "object oriented" in spirit. The general pattern I've seen: one "constructor" which you are expected to call (but not call twice, because the constructor uses hardcoded DOM id's), a bunch of other "functions" and event handlers, which you are not expected to call (but the because there is no "private" in JavaScript, you don't know that) and data sharing between all these functions through this. Seen from the caller's point of view there is just one "callable" and nothing else.

Not every Javascript project needs OOP. I wouldn't go there unless I were using an existing OO framework like ExtJS. In your case, where it seems the only use of OOP is misuse, I think you should skip it entirely. Since you are switching to jQuery, just follow the jQuery plugin architecture. Write custom plugins when convenient.