views:

152

answers:

4

Douglas Crockford said a long time ago:

Classical objects are hard.

....

Shallow hierarchies are efficient and expressive.

I came to this conclusion separately after years of JS development, and now I'm struggling to convince my colleagues. Arguments don't help, because apparently "classes and dozens of methods are easier to understand".

I was trying to explain by reason, but I needed an example. So I rewrote one of the js files we have in the admin interface in a better way.

But apparently the "writing JS as it's Ruby/Java" is still better.

Is it me who's been wrong all along, or the world? Please, I need your opinions, as I am not sure anymore.

(more specific, which version is easier to understand and is more maintainable?: http://glebm.blogspot.com/2010/10/object-oriented-javascript-is-evil.html)

+9  A: 

I've also come to the same conclusion - JavaScript is frankly Awesome, it is however also one of the most misunderstood languages and its easy to see why people dislike it and see it as inferior.

In fact I can very easily sympathise with everyone who dislikes JavaScript as not so long ago I too hated JavaScript with a passion! I was working on some particularly terrible code in which every feature of the language had been twisted into a cruel and sadistic mechanism by which to make debugging as difficult and as painful as possible.

At the time I even had strong JavaScript supporter try and explain to me why JavaScript was so awesome, but it was no good - my view was tainted by the horrible monstrosity that I was tasked with maintaining - every hypothetical good example usage of various language features was countered with a compelling case of how that same feature can make a programmers life hell.

And therein I believe lies the problem - for most people the only experience they have had of JavaScript are awful examples of how the language can be abused written by people who didn't understand JavaScript - peoples judgements are often swayed predominantly by their bad experiences, and JavaScript has those aplenty.

For me the thing that changed my mind was seeing code written by someone who did understand JavaScript - the code was just so clean and easy to read that I couldn't help but be impressed - until that point I had never realised that it was even possible to write such code in JavaScript.

So my advice would be: Don't try too hard to force peoples opinion - instead just make sure that they get exposure to well written JavaScript every now and then and hope they come around! :-)

Kragen
Oh thank you so much for this answer!
glebm
+2  A: 

I'm currently using some classical object patterns in a 10k+ line JavaScript application. I'm doing so, because the code almost requires it. My classes have constructors, initializers, methods that instruct the classes what to do or how to behave, and some classes even inherit from others. To me it's all about code reuse and having the correct references to objects in the right place.

I think your question is too generalized. Use different patterns for different situations. The example you give doesn't warrant a "class" in my opinion, because it really only does one thing. However, I don't see a reason not to follow the class pattern.

Edit after reading glebm's comment:

I completely agree. For the vast majority of JavaScript code there is absolutely no reason to force it into classical patterns. Doing so will over-complicate and make the code more difficult to maintain.

JoshNaro
It's too generalized, yes. So, to clarify, I am referring to pieces of javascript like the one in the link, i.e. 95% of the js usage out there
glebm
A: 

Yeah I think you're on your own here.

Gio
`<sarcasm>` detected :)
glebm
A: 

Prototype chains provide inheritance that I personally find easy to understand. So if you want a new class Child that has parental guidance (so to speak) from a class (well function to be exact) that you have called Parent somewhere in your code, just inherit from the Parent like so.

function Child(){/* constructing blah */}
Child.prototype = new Parent();
Child.prototype.dryfoo = function () {/* dry stuff */};

For completeness I added the kids own shiny new method dryfoo.

prototypes are mem' efficient too Not really sure if I have gone off track from your question as Roatin Marth rightly says says "you don't have inheritance in your code". But I am PRESUMING this is the area you are referring to. Don't flame me if I am wrong, only trying to help :)

dryprogrammers