I don't think it did. Those of us who bothered to spend more than a glancing look at prototypes figured them out pretty easily. Including Classes in JavaScript feel like pandering: there really wasn't much to directly gain from them, but they threw them in there anyways because the TC knew it'd gain JavaScript some popularity.

Wha? That's a take.

Here's mine: ES6 classes are wildly smart. They provide the benefits of prototypical inheritance--you can just reach into the thing and do what you want to do!--while making it way easier for many developers to read and parse in short order, while reducing the difficulty spike in moving to JavaScript (or, today, TypeScript).

"Pandering". Right.

I can write old-style object prototypes. It makes my eyes bleed and makes me make more mistakes. So I'm just not gonna do that anymore.

It makes your eyes bleed? If you thought mine was a take...

Anyways, let's not act like ES6 classes aren't without their slew of issues, obscure syntax, and most importantly, problems when it comes to transpiling and backwards compatibility:

https://medium.com/@WebReflection/a-case-for-js-classes-with...

"Let's" not, but I don't care about much of anything in that article. I haven't written something that targets a browser that isn't ES2015 since...2016.

It's 2020. Things move on.

Great attitude. Let's move on and leave 13% of the global internet population behind.

It depends somewhat on when you tried to learn prototypes in JS. The time before Firefox implementation detail `__proto__` leaked into general web platform usage had some rough spots, as the big obvious example to mind. It still took almost too long after that before `Object.getPrototypeOf()` and `Object.setPrototypeOf()` were standardized. Admittedly "the prototype of this instance" shouldn't always be accessed and/or manipulated directly in "proper" prototype-oriented code, but there are a lot of practical cases that show up where it ends up being useful.