views:

112

answers:

4

Javascript is a powerful language but I can't get it why there are several ways to OOP, don't you think that it is adding a frontline barrier for new developers which have to work harder to master the libraries?

+8  A: 

JavaScript only does OOP one way: Prototype based.

Libraries like MooTools add layers on top of JavaScript to make it seem more familiar to people familiar with Inheritance based OOP.

If you're just starting out learning JavaScript, don't use a framework or library until you're familiar with the basics. That way you'll understand how everything really works instead of looking at different abstractions and thinking they're all native JavaScript.

Justin Niessner
+1  A: 

Yes, you pretty much have to know OOP very well already if you want to do it in Javascript, it's not a good language for learning OOP.

Although you can implement most OO concepts, it's not what comes naturally for the language.

Guffa
+2  A: 

My puny prototype oriented mind cannot possibly comprehend the deep meaning of your question's title.

String.prototype.replaceBS = function() {
  return this.replace(/principle|OO|OOP|enforce|static|class|private|protected|final|best practice|Java|IE/gi, 'lolcat');
};

(a = document.getElementById('question-header').getElementsByTagName('a')[0])
    .textContent = a.textContent.replaceBS();

Ahhh...

MooGoo
LMAO - [discovery of a lifetime](http://lolinator.com/lol/stackoverflow.com/questions/3300416/doesnt-javascript-go-against-the-hidd) - "my puny prototype orientd mind cannot possibli comprehend deep meanin uv ur question title."
Anurag
From this point forward I shall use `thiz` instead of `that`/`self`! Screw bes practicez.
MooGoo
+1  A: 

The key phrase to focus on is "new developers". I would consider Javascript to be one of the more advanced languages even aside from OOP. The fact that you can redefine functions on the fly and add functions to core objects lead me to the opinion that new developers should probably stick to the entry level javascript stuff and get a hang for OOP in C++ or Java before attempting to create Javascript classes.

Also if you start creating a large number Javascript classes in your application it would probably be a good idea to take a step back and reevaluate your design and see if some of the logic should actually be done server side. I love AJAX, but sometimes it makes it easy to put too much logic on the client-side when in fact it belongs in the server code. This coming from a Javascript enthusiast.

Adam
I don't agree. An application like gmail will not be possible if we limit the role of JavaScript to basic DOM manipulations. It has to be well architected at the client level too.
Anurag
I wasn't saying limit it to DOM manipulations. I was just saying you should analyze your code to make sure code that should have been executed on the server didn't make its way onto the client. If someone was designing an application like Gmail that heavily relied on Javascript, they could still put most of the code on the server by using AJAX to make asynch REST or SOAP calls to the server so the server still handles most of the work.
Adam
I think my "I love AJAX, but" line might have caused some mis-reads. I just meant while AJAX is a valuable tool it introduces more pit falls like placing more logic than is needed on the client. Any client-side code can be read and manipulated by the end-user which introduces security risks. Not to mention that too much Javascript can cause the transmission of the http response to be slower. So it's always important to keep the important stuff on the server. Having too much OOP in your Javascript can make it easier for server code to make its way to the client.
Adam
If an app already requires Javascript to function, why not put as much logic client side as possible? What better way to lighten server load, in both CPU time and bandwidth. The security risks will be present no matter what proportion of your logic is server/client side. In theory, you could get pretty far with using server side code merely for validation, security, and database relaying, with JS handling the rest. I'd say if offloading logic to the client can lessen the frequency and size of HTTP requests without introducing any security holes, go for it.
MooGoo
A lot of web applications wouldn't necessarily require Javascript if designed correctly, the Javascript would just be added in to make it flow nicer. For example, with GMail I think there are ways to switch to a less "AJAX heavy" version that would just download the emails and make synchronous http requests without a heavy use of AJAX. If the designer had put in as much client side logic as possible then they wouldn't be able to provide the lightweight version as easily. Plus, if you add as much JS as possible then you'll have to update that much more code when a new browser deprecates code.
Adam