Live data from Hacker News

ES6 Cheatsheet

github.com

11–20 of 89 posts

Re: ES6 Cheatsheet

#11
post #9
post #2

[deleted]

Not at work, but I use either ES6 or Typescript personally. "All of the syntactic sugar stuff changes the look and feel of the language too much for my tastes." I think it brings it into line with how the language is being used in production these days. Modules, generators etc make the language more beautiful, powerful and easier to maintain.

>>> Not at work, but I use either ES6 or Typescript personally.

Not a JS developer, but most of my friends who are have been transitioning to Typescript. The road is bumpy, but they say once you get some syntax stuff down, you're good.

Re: ES6 Cheatsheet

#13
post #2

[deleted]

Template strings, arrow functions and object shorthand ({ foo: foo } === { foo }) are very nice.

To be clear, that statement doesn't actually evaluate to true, but those two object literals are equivalent (not referentially equal)

Re: ES6 Cheatsheet

#14
post #5
post #2

[deleted]

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 writing in other languages.

Re: ES6 Cheatsheet

#15
post #9

Earlier quoted context omitted.

Not at work, but I use either ES6 or Typescript personally. "All of the syntactic sugar stuff changes the look and feel of the language too much for my tastes." I think it brings it into line with how the language is being used in production these days. Modules, generators etc make the language more beautiful, powerful and easier to maintain.

>>> Not at work, but I use either ES6 or Typescript personally. Not a JS developer, but most of my friends who are have been transitioning to Typescript. The road is bumpy, but they say once you get some syntax stuff down, you're good.

Ditto.

Re: ES6 Cheatsheet

#16
post #2

[deleted]

I prefer ES6/ES2015 (currently via Babel, and considering TypeScript). The let keyword and arrow functions in particular make it a much more pleasant language to work with than plain JS. It's now competitive with CoffeeScript, but with more coherent and predictable parsing rules.

Re: ES6 Cheatsheet

#17
post #2

[deleted]

Using ES6 here most of the time as well, there's very few reasons not to these days. Some of the changes may only be syntactic sugar but you very quickly find yourself not wanting to go back.

Re: ES6 Cheatsheet

#18
post #5
post #2

[deleted]

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…

Having used ES7 async/await through Babel extensively for some highly asynchronous code, I can say that it feels much better than using Promises alone, even better than using ES6 generators + a runner (especially since async/await meshes so well with ES6 classes).

Re: ES6 Cheatsheet

#19
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!).

Re: ES6 Cheatsheet

#20
post #18
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…

Having used ES7 async/await through Babel extensively for some highly asynchronous code, I can say that it feels much better than using Promises alone, even better than using ES6 generators + a runner (especially since async/await meshes so well with ES6 classes).

The only fear I have is that the spec might still change, which is not the case for ES6 features. Do you think my fears are unfounded? Because I'd love to use ES7 for my back-end projects where all database interaction, and by extension a large part of my codebase, relies on promises...
Post reply on HN