> No. Just no. Simpler is better, especially if there are no real drawbacks.

Your claim of "no real drawbacks" is very much your opinion, nothing more.

> Yet you just dismiss my approach without providing solid argumentation

I've made several other comments on this item.

> you cannot use previous OOP experience

Shock horror, a developer needs to learn JavaScript before writing JavaScript. This is a positive not a negative. There are already too many "developers" who write javascript without understanding it.

> there are MANY ways to do OOP using prototypes (functions,direct prototyping,__proto__) vs ONE

your example of "many ways" is misleading: it's not "functions" or "direct prototyping" - you assign functions to a constructor's prototype, and they become instance methods.

__proto__ is non-standard, and no developer worth working with would use it for creating "classes".

There are also MANY ways to create "classes" using object literals - the article linked just gives one example of this.

> 'this' has different meanings depending on context -> requires you to process contextual information

you're making a mountain out of a molehill.

> prototypes make existing objects unreliable ->

How so?

> requires prior knowledge about libraries and APIs (leaky abstraction)

No more than an object literal with methods attached to it.

> building an object with prototypes requires far more mental steps: you have to know about objects, functions but also about the prototype chain, the hidden prototype property (why?), the logic behind the new keyword etc.

Yes, it's so horrible that developers using a language need to have some knowledge of that language before writing more than basic code, isn't it?

> If prototypes had been implemented in a very consistent way (without the new-keyword and only using __proto__) I would have advocated prototypes instead of literals

you still haven't actually given any reason the new operator is "bad".

and you keep mentioning __proto__ which makes me think you don't understand the language at all. __proto__ is a non-standard property that some implementations expose

> On top of this, many different 'sugar' solutions exist, most of them incompatible.

You don't need "sugar" at all - just a constructor function definition, any methods for the prototype and then as many calls to instantiate objects as required.

> conforms to established industry and business standards in OOP

buzzwords and "make the boss happy" phrases mean nothing here.

> requires less knowledge about language details, this leaves much more room to focus on application logic and design

if the developer doesn't understand javascript, which OOP pattern you use is the least of your worries.

> very transparent, no sugar code (beget) or libraries required
as I said, no sugar or libraries are required for prototype "classes" - it's part of the language you are choosing to ignore.

> neat code: methods are grouped together

How is this different to assigning methods to a constructor's prototype?

> allows to implement well known design patterns easily

this is a pattern in and of itself, what are you talking about?

> no this, that or self variables

a lack of "this" is not an advantage - you mentioned earlier about not being able to re-use previous OOP experience, then argue that not using a standard OOP concept ("this" in instance methods) is a good thing?? Make up your mind!

> And all you are saying is: it's too easy, it must be for entry level developers.

No, I said "simpler is not always better". Your approach ignores huge parts of the way JavaScript works because "it's too hard".

It's nothing to do with puzzle contests or ridiculous languages - it's about learning to use a language to it's full potential, rather than sticking your head in the sand and saying "it's too hard, so I'm not going to do it!".