[79d697i6fdif]

I think it's around 5 years too late to prevent the complexity explosion :)

JS has been object oriented since the beginning it just has an insane prototype based inheritance hierarchy that they're increasingly trying to hide/pave over.

[treehau5]

> just has an insane prototype based inheritance hierarchy that they're increasingly trying to hide/pave over.

Can you elaborate more on why you think it is insane? I think it is quite elegant, and in my experience they only try to hide or pave over it because just so many damn people can't get over the fact that it isn't classical object oriented

Also, for those who haven't read: http://javascript.crockford.com/inheritance.html

[79d697i6fdif]

the way inheritance works in JS leads to a ton of inelegant design patterns that need to be remembered and very inefficient handling of many casts because the prototype chain is literally just a linked list.

It also prevents sound encapsulation of class local variables and methods, the main point of object oriented programming in the first place.

[treehau5]

There are many other languages that do not have multiple inheritance, or do not handle it the way you typically see in C++ or Java type languages, go being one of them, ruby another. Composition is more favored, and arguably a far better pattern regardless. I disagree with your assessment that it prevents sound encapsulation, and regardless, a better argument made against it is the fact that it is a dynamic language. In any way, there are patterns to achieve classical OO-style encapsulation, but that is not the main point of object oriented programming in any case.

[79d697i6fdif]

My argument doesn't have anything to do with multiple inheritance. C is the only one I know of that supports multiple inheritance and it's largely considered a historical mistake (see deadly diamond of death). Javascript uses something called the prototype chain to determine InstanceOf(). It's literally a linked list, and a ton of disadvantages come with the object system being a re-purposed linked list. It's possible (and easy) to break the type of an object by corrupting the prototype chain. It's the reason you have to do hacky stuff like Array.Prototype.ForEach to make sure your code actually works in larger JS applications. It's also slow and a big reason why javascript runs around 10x slower than most JIT'ed languages. The crazy object system prevents a ton of optimizations from working.

Encapsulation isn't the "classic version" of OO. It's literally the main reason OO was created. Javascript fails to encapsulate because it doesn't support true private data members. There's patterns to achieve some sort of data safety (see http://speakingjs.com/es5/ch17.html#private_data_for_objects) but they all have disadvantages because it isn't built into the language, it's another hack.

Composition can be easily achieved using interfaces in most languages, another thing javascript doesn't support.

Excusing these faults to being dynamic language is like saying the model T is a nice car because "it was good for its time". Many languages before JS (including perl even) supported a more sound and convenient type system.

JS was badly designed in many ways and we are still paying the price for it today. ES6 and transpiling have made it finally worthwhile to try to develop anything significant using it which has led to the recent explosion of javascript development. I pray that EMCA continue to remedy what can be fixed in future and that Typescript catches on since it mows over much of the insanity.

[erikpukinskis]

The next generation of package management tools will allow for multiple "universes" of libraries, using different development philosophies. Then we'll have a real hard fork and the ES6/hundreds-of-control-structures+complex-build-pipelines crowd will have to compete with the JavaScript/small-idiomatic-modules crowd.

Think subreddits for NPM.