Live data from Hacker News

ES6 Cheatsheet

github.com

21–30 of 89 posts

Re: ES6 Cheatsheet

#21
post #5

Earlier quoted context omitted.

I'm all in on ES6 when it's practical or allowed. Arrow functions are wonderful, I love destructuring assignment, const and let, and considering that some projects I work on involve a lot of async stuff, I'm close to just giving in and using ES7's async/await functionality. But most of the time this is in the context of Node.js development, and in every case I use Babel.js to turn the end result into ES5 code. I'm pe…

> Could you elaborate why you don't like the 'perl/python' style changes? It's really just a style preference. I enjoy the "look" of C-family code. >why one would choose to limit oneself to things like .bind(this) I know 'this' is a source of pain for a lot of people. For me, I see it a source of flexibility. I've found the ability to control the context at will to be a huge benefit. It's a feature I miss when I'm wr…

> For me, I see it a source of flexibility. I've found the ability to control the context at will to be a huge benefit. It's a feature I miss when I'm writing in other languages.

But that's why you can still use the regular functions... I don't quite understand how having the added option of a more concise syntax with automatic binding to the surrounding context is less flexible. I often find myself using the regular function declarations to differentiate between different sorts of functions. The arrow notation is opt-in.

Or is your issue that when you work with other people's codebases, you have no option to opt-out?

Re: ES6 Cheatsheet

#22
Wow, var was so broken.

Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require binding, so while the syntax of => is concise, it is rarely used as a Function.bind replacement). Pretty much went through the same experience with template strings. Generator functions are great.

I'm not a fan of the class keyword either, but to each their own. I think it obscures understanding of modules and prototypes just so that ex-Class-based OOP programmers can feel comfortable in JS, and I fear the quagmire of excessive inheritance and class extension that will follow with their code.

Re: ES6 Cheatsheet

#23

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…

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!

Re: ES6 Cheatsheet

#25
post #22

Wow, var was so broken. Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require b…

As of 5.4.0 arrow functions are more performant than binding, FYI: https://github.com/nodejs/node/pull/3622

Re: ES6 Cheatsheet

#26
post #25
post #22

Wow, var was so broken. Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require b…

As of 5.4.0 arrow functions are more performant than binding, FYI: https://github.com/nodejs/node/pull/3622

Woohoo!

I've been hoping that this guy's Function.bind optimizations land before 6.0: http://benediktmeurer.de/2015/12/25/a-new-approach-to-functi...

But you prompted me to check on the status of his work, and was happy to find a new post: http://benediktmeurer.de/2016/01/14/optimizing-bound-functio...

It looks like V8 will finally be able to inline bound functions (https://codereview.chromium.org/1581343002)! That's huge!

Re: ES6 Cheatsheet

#27
Two questions: what happens if you use ES6 standards in a browser that does not support it?

And would it be wise to hold off adopting until all browsers support it?

Re: ES6 Cheatsheet

#28

Two questions: what happens if you use ES6 standards in a browser that does not support it? And would it be wise to hold off adopting until all browsers support it?

You'll get an errror :) (probably a syntax error)

You don't need to hold off on using it but you should definitely use a compiler like Babel[1] to compile your ES6 code to ES3 for compatibility.

[1] https://babeljs.io/

Re: ES6 Cheatsheet

#29

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…

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.

Post reply on HN