JS is definitely OO; its not class-based OO -- but its still OO. And its purer OO than, e.g., Java (class-based OO in which classes are not first-class objects but require jumping through hoops to get an object that represents the class are not as much OO as either protypical OO languages that lack classes as language features like JS, or class-based OO in which classes are objects like Ruby.)
> IMHO OOP has not proven itself out to reduce confustion, or simplify code bases. It tends to make distributed systems which are increasingly necessary for large projects more complicated. In JS I tend to have two types of objects.
IMHO, OO languages, per se, do not have that effect, though Java has that effect, due to the same limitations which make Java the poster child for repeated-code-template style design patterns.
When done correctly, object oriented programming is a lot like the Unix philosophy.
The Unix philosophy (in part): Write programs that do one thing and do it well. Write programs to work together.
Correctly done object oriented programming: Write objects that do one thing and do it well. Write objects to work together.
There's a lot of very poorly written non-OO code out there. Don't blame OO because there's also a lot of poorly written OO code out there. OO is, in part, a tool to manage code complexity. Blaming OO for complexity is like blaming Unix for complexity because there are too many programs in the /bin directory.
CoffeeScript isn't JS, its a different language that compiles to JS. So what CS can do doesn't say anything about JS as a development language.
> You will not be able to use Ruby or C++ in client-side browser code any time soon.
You can use C++ in client-side browser code now -- sure, you compile it to JS, just as you compile it to native binaries to run on the server side, but the development language can be C++. [1]
JS is not OO... IMHO OOP has not proven itself out to reduce confustion, or simplify code bases. It tends to make distributed systems which are increasingly necessary for large projects more complicated. In JS I tend to have two types of objects. The first being data, that which can be easily serialized, transported, stored and deserialized. The second being libraries meant to act against requests or use of said data. The second can be extended to those which tie a user interface to said data as well.
When you break things down in such a way it's easier to develop systems that can scale out, and are easier to maintain as such. You can do similar things in most OO environments. I also tend to think that my Duck data class should probably NOT have a quack method. My DuckHandler class should.
OO has brought us a lot of extremely bloated, over-engineered, "enterprise" monstrosities over the years, and imho should not be encouraged.
JS is very much my favorite language, and in some scenarios (testing, and build scripts) I have started to use CoffeeScript. My second is actually C#, which I pick over Java because JNI is such a pain by comparison. It really depends on what you need.
Sometimes you just need to get something done. You will not be able to use Ruby or C++ in client-side browser code any time soon. On the flip side node.js as a binding layer against a very nice set of C libraries is pretty awesome, and can be used to get closer to a "one language to rule them" ... it's often said, "don't let perfection get in the way of good enough."