News for hackers. Stuff that matters.
Re:ES6 Cheatsheet by mercer on Friday January 22, 2016 @11:15AM (#10953551)
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 perfectly comfortable with using ES5, because as a freelancer/contractor I often have to do so. But I really miss the ES6 stuff and the more I use it, the more time it takes me to 'switch' to a mindset where I'm only allowed to use ES5 functionality.

Nonetheless, it strikes me as really odd to actively prefer ES5. Having worked with Ruby and Python (among others), ES5 feels limiting for no good reason. The only rationale I can think of for prefering ES5 is nostalgia.

Could you elaborate why you don't like the 'perl/python' style changes? Because I truly do not understand why one would choose to limit oneself to things like .bind(this) instead of the different forms of arrow functions that make functional-like programming so much easier. And I've found that the best part of JS is that it's decently functional.

Edit: I would agree when it comes to the new 'class' keyword though. I'm not a fan of that.

Re:ES6 Cheatsheet by alistproducer2 on Friday January 22, 2016 @11:43AM (#10953782)
> 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 by mercer on Friday January 22, 2016 @12:06PM (#10953960)
> 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 by cletusw on Friday January 22, 2016 @11:55AM (#10953865)
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 by mercer on Friday January 22, 2016 @12:04PM (#10953939)
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...
Re:ES6 Cheatsheet by nailer on Friday January 22, 2016 @02:32PM (#10955023)
> 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.

If it's helpful: the current stable node (4.x) already supports ES6 out of the box.

Re:ES6 Cheatsheet by mercer on Saturday January 23, 2016 @03:56AM (#10957728)
I'm currently doing that for a project, but I'm about to change things up and use Babel anyways, for the following reasons:

- my project contains jsx files, which currently are compiled into .js files which feels a bit messy.

- I'm seriously considering using ES7's async/await functionality, which is not supported by node yet.

- and most importantly: node's ES6 support is incomplete. In particular, I miss default function parameters and destructuring assigment.

Using Babel would solve all these issues, and I could simply remove Babel once support is sufficient.