[hn_throwaway_99]

Lord, no, please, please don't do this in any codebase that anyone else has to actually look at/contribute to.

Other commenters have pointed out some of the technical issues with this implementation (all instances get a copy of every method, no prototype-based type checking, non-standard use of "init" vs new, etc.) But the much more important issue is that you did not make life easier for other developers looking at your code. Instead, you just forced them to learn one additional, non-standard way of doing things with very little, if any, real benefit.

Developers need to learn to be extremely judicious whenever you use unusual/non-standard patterns in code. Everyone already needs to learn the standard way of doing things, so there should be a giant bar in terms of things like productivity enhancements or performance improvements if you're forcing everyone to learn your non-standard pattern. Avoiding "this" doesn't cut it.

[lucideer]

> non-standard way of doing things

Fwiw this exact pattern was the idiomatic defacto standard in JS before classes were added to the ECMA specs. This will be extremely familiar to anyone with a reasonable number of years of experience in JS.

That's not a good defense in itself: things should ideally be familiar to beginner devs, but that's more of a debate on what's being taught in current JS education than on what's "better".

i.e.: if this were a better pattern (it's not), lack of familiarity wouldn't be a good argument against it.

> with very little, if any, real benefit.

In fairness the article spends most of its time laying out the proposed benefits, so stating that there's no benefit without addressing its arguments is a little lazy.

Some of the arguments are inaccurate (private fields have been widely supported since 2021) but it's true that ECMA's class implementation is riddled with issues & exploring alternative patterns is worthwhile.

Even before ECMA added classes, I never liked this pattern: it seems a clumsy attempt to shoehorn classical inheritance -esque arrangements onto a prototypical language without ever putting forward reasoned arguments for the benefits of doing so. This article at least tries to put forward arguments about why fake shoehorned classical inheritance pattern is better than the "standardised" shoehorned classical inheritance pattern, but in reality both are bad.

[chrismorgan]

> Fwiw this exact pattern was the idiomatic defacto standard in JS before classes were added to the ECMA specs.

No it wasn’t. Some people used it, to be sure, but more used the prototype chain properly, storing data in `this` and all that.

[hn_throwaway_99]

Totally agree with the other response. This absolutely was not standard before class syntax was introduced. Use of constructors, new, this, etc. was the standard - class was essentially just a back port, adding syntactic sugar on top of the prototype design that was inherent to JS from the beginning. The only time I saw something like this was just from people that didn't really "get" or understand inheritance or OOP.