A bit OT and naive question maybe but when do you need OOP in JavaScript? I code a lot of web stuff but the only time I've used OOP in JS is when I make games (where inheritance etc makes sense). Does anyone have a real-world example?
The terms "object" and "object-oriented" mean so many different things that it's hard for any discussion not to run aground on semantics. But I'll chip in with this anyway: in my experience, you don't need OOP, and it's a particularly obscuring influence in JavaScript. Certainly you should not take for granted that OOP reduces complexity, but rather ask yourself in the context of particular programs how true that really is. (Games may be a special case, since they're closer to the simulation-of-an-external-system paradigm that is the sweet spot for OOP.)
In my view, the fundamental problem with OOP may be premature encapsulation. Once the core concepts of a program have gotten clear enough to be very well-defined, it makes sense to put them in the kiln and bake them. The rest of the code can then just use an interface and care nothing about the details. But as long as the core concepts and their relationships are still in the process of being discovered, which is actually the default case for most programming, what you need most is malleability. The OO infrastructure of encapsulation impedes that. This manifests as unclear classes with unclear names and unclear dependencies between them. Such a program is harder to work with than a loose collection of functions would be. And the fact that JS wasn't designed to be used this way makes its effects worse in JS.
> I code a lot of web stuff but the only time
> I've used OOP in JS is when I make games
The notion that OOP === single-inheritance needs to be put out of its misery. An object is anything that binds together data and code in a single value, and you use them all the time.
In an object oriented paradigm, you send messages between objects, in a functional paradigm you pass data to functions. But, functions can normally take functions as arguments as well -- and all in all you can do one thing in the other -- but I think the big difference is on whether you model "smart data" or operations/functions.
Classes comes in when you have many objects that share behaviour. That can be modelled as traits/interfaces or as classes (grouping methods, and possibly singleton state). These things can be inherited, or assigned (as in javascript/self).
Say you're working on a twitter clone for example. It'll make your life much easier if there's a "NewsFeed" class that contains an array of instances of the class "News", which when clicked on shows an instance of "NewsDetails". (All of these would be "Views" if you used if you used an MVC framework like Backbone, probably backed by a model class that contains news data like the tweet content, the # of re-tweets, etc.)
You could do all of the above without using objects; it's just that your code will be a lot messier IMO.
Ironically the PHP community suffers from this problem since it has explicit classes and interfaces,while being a design mess under the hood.
About OO and JS, a lot of projects actually use prototypal inheritance , you just dont see it because it's hidden under a jquery like facade/chainable API, where you never need to use the new keyword explicitly. It's obvious that libs that use these kind of DSL are fairly popular in the js world,more than the one using "explicit" OO.