Although OP certainly could’ve used softer language to express this thought, I do think this…
Mike Chen

Thank you for taking the time to write a reasoned response (I’m not sure why the OP didn’t do so themselves). I appreciate all feedback.

I didn’t invent Factory Functions. They were originally presented as an appealing alternative to Constructor Functions because they have fewer gotchas.

Factory Functions have been around for much longer than the JavaScript class syntax. So, I think calling Factory Functions a “non-standard way of doing things” is a bit of a stretch.

I fully agree that educating people about the potential pitfalls of a given feature is a good approach. My hope is that people come away from this article knowing MORE about Classes and their relative advantages and disadvantages, not less.

I also believe that someone who has read this article (or any other decent article about Factory Functions) will have no trouble understanding and using Classes properly when they are forced to do so by a framework or coding standard because these articles always talk about the trade-offs with Classes.

I think it’s much more likely that someone who has never heard of a Factory Function or why it exits, will fall victim to the common gotchas of JavaScript Classes.

My experience working with large teams and complex code bases leads me to believe that there is a lot of value and wisdom in making “the right things easy and the wrong things hard” as you said.

I’ve never seen a major performance issue in a JavaScript code base caused by the use of Factories, but I have seen several bugs over the years related to the use (or rather mis-use) of Classes.

Thanks again for your feedback.