[igravious]

The only thing from this list of new ES6 idioms that doesn't sit comfortably with me is the short-hand for creating classes. I remember being kind of blown away way back in the day with the prototypical/functional nature of Javascript and how you could wrangle something into being that behaved in an object-oriented manner just like other languages that had explicit class declaration and object instantiation.

Part of me feels that obscuring Javascript's roots in this respect is very un-Javascript-y. What think ye?

Coming from Ruby, loving template literals, feel right at home with them, I wish even C could have them (if that makes any sense!).

[khalilravanna]

I think the cheatsheet does a great job of summarizing what makes me uncomfortable with es6 classes:

>"...the syntax for creating classes in ES6 obscures how implementation and prototypes work under the hood..."

Yes, it's great for if you're uncomfortable with prototypal inheritance and the "javascript way of doing things" (I'll maybe summarize that as composition over inheritance, mixins, knowing how to use call/apply etc.), but at the end of the day I'm worried it might be a crutch. Specifically, it might create the situation where a javascript noob might use es6 classes and never bother to learn how the prototypal chain works or all the myriad options available for mocking classes and OO behavior. That being said, maybe that's a shitty argument. When you have more tools in the toolbox there's always the option for someone picking the wrong tool. Does that mean you take the tool out? Or leave it because it is really useful when you know when to use it correctly. I imagine the latter.

[igravious]

Agreed. And I meant prototypal, not prototypical :)

[stared]

If "un-JavaScript-y" were a bad thing... JS is not a particularly pure, or well-designed, language, so we should not treat it religiously.

Personally, I love ES6 for fixing many JS pain points (yes, hacky class-like object constructors are among them). If it is against it's history - so be it!

[wvenable]

Prototype inheritance is fairly hard to reason about and fairly verbose to set up correctly. And if we aren't supposed to avoid inheritance that applies equally to prototype inheritance as well. Prototype inheritance allows even crazier inheritance situations.

I don't think it's reasonable to eliminate inheritance (it's very useful when it's needed) but restricting it down from what Javascript currently provides natively is a good thing.

[recursive]

I think it's un-Javascript-y as well, and I consider that a good thing. I don't think javascript is a particularly well designed language. (I mean, it's great considering its origins, but still)

If I could avoid writing javascript I would, but unfortunately, you have to write javascript to do anything inside a browser. I can't wait until class {} gets widespread browser support. I know compile-to-javascript languages are a thing, and I use them, but in my experience, you can't get away with not knowing javascript.