> Another related, highly recommend reading:

Sorry, I don't follow your recommendation. Urgh, what a mess of a post.

All the (very valid) arguments that could be made for prototypical inheritance and functional programming style are drowned in a self-congratulatory fluff piece, full of marketing speech, substituting arguments by strawmen and namedropping, full of absolute claims and superlatives while demonstrating an rather pinhole view of computer languages, all the while not even giving a single practical example.

Me too (and later my organization)

It doesn't bring anything (except a bit more performances when you create tons of objects, a setup that rarely matters unless we're talking video games or some very niche applications that somehow can't work with a subset of your data) but only create more cognitive load (bind, call, =>, closures using this, where Am I? is it a method or a function? Is it already pre-bound?).

Functionalities that create extra cognitive load and doesn't give you anything shouldn't be used.

I absolutely agree.

As a related side rant, the `new` keyword, or equivalent, makes great sense in a manual-memory-management language like C, and it's an offense to sanity in a language like Java or Javascript. Factory functions should be the default everywhere. So any JS coding style that encourages `new` is a wildly bad fit to the rest of the language.

But it is important to admit the caveat, as you do, which is "when you create tons of objects".

Such situations are unequivocally in the minority (compared to line-of-business stuff where RAM and CPU more than sufficient to the task), but not the vanishing minority. So we do still need a good solution for those.

Rendering, simulation, sampling/signal-processing, parsing... the list goes on. This isn't truly systems-level code, but it's easy to generate a billion objects per second. So we do need patterns for doing this kind of programming.

> Factory functions should be the default everywhere.

Factory functions still need to create the object somehow to return it.

Absolutely. The guts of the factory function should usually involve an object literal. Or in some cases, Object.create.

(If we're talking about Java, then obviously you have to have `new` somewhere, which is just one of the many shortcomings of Java, although obviously not a fatal one.)

I do really like JavaScript's ability to compose objects like that, and I feel that people interested in it as a language should definitely learn how to program in that manner. However, I suspect that for most people JavaScript is a means to an end, and it's more useful in a number of senses to try to write JavaScript more like other class-based languages. I mean, I feel like things like TypeScript sort of miss the point of having a dynamically typed language, but there is a solid case to be made for features like strong typing, especially as size and contributors go up.

Beware referencing or learning from Eric Elliott.

https://www.reddit.com/r/javascript/comments/6q2lk0/why_comp...

https://www.reddit.com/r/javascript/comments/5c5lkq/what_eri...

https://www.reddit.com/r/javascript/comments/3x91ac/why_not_...

Parent poster here, thanks for pointing out this, I wasn't aware of the critics.