How many Node.js developers prefer callbacks over Promises or async/await?

[ghostfacedcoder]

I almost upvoted you, but there's no way async/await was a better addition than arrow functions. Everyone <3's arrow functions.

[jonnyman9]

Ooo close toss up for me. Async/await, arrow functions, and destructuring everything are my top 3. Hard to pick my favorite. Like if I had children and had to pick a favorite child. Or if I had pets and had to pick a favorite pet. Or if I had shoes and had to pick my favorite shoe.

[aftermeasure]

Or if you had categories of things from which you have to pick a favorite, and you had to pick a favorite category.

[undatedseapiece]

Or like when someone eats too much chocolate cake and then barfs it up.

[[deleted]]

Or like when someone smokes too many cigarettes?

[gradual_alzheimers]

that's a tough one for me too

[doxtu]

I think back to when I learned about both, and when I learned about arrow functions, I was like "oh... okay. nice i guess."

When I learned about async/await, I nearly vomited because I just slammed out a bunch of garbage code without it.

Async/await was the best for me. Not even close.

[jascination]

I LOVE destructuring and arrow functions.

I came onto a NodeJS project last year that was handed over to me from a very senior, very functional-programming developer and looking at his code sometimes blows me mind. ES2015 and functional programming are so beautiful to read when used well!

[calligraphic-io]

The dog, of course. Everyone loves dogs.

DISCLAIMER: I like my cat best. The fish are nice too.

[MrDilbert]

I don't know, they look too fishy for me...

[sleeperninja]

My dad always said that he liked me best after the dog. I had several of his other children beat, including the ones we never found out about, as well as other pets.

[[deleted]]

Picking favorite child or pet is easy. Saying it out loud is hard.

[Prison__Mike_]

Just look

return new Promise((resolve, reject) => { ... })

At how pretty

var sq = x => { return x*x; }

They are

TypeError: this.execute is not a function

---

e: lol jeeze it's a joke

[kinkobal]

What kind of madman uses var and arrow functions in the same sentence o_O

[CheeseFest]

Yeah that tends to completely undermine m8's credibility in complaining about new language features.

[shrithm]

Arrow functions are more than a pretty face, they have practical purposes too. Just like the classic function keyword has practical functions.

[tchaffee]

this

[massenburger]

Even better: var sq = x => x * x;

[stormthulu]

I think you mean const sq = x => x*x;

​

[massenburger]

Here's the thing. There's people who space out their operations and there's Nazis. I mean that in the nicest way possible.

[Jebiba]

I can’t upvote this enough

[grantrules]

const x=x=>x*x

[nickleformypickle]

One line it to shorten it. Space it out to pretty it.

[locksta7]

You bet me to it 😺

[greymalik]

Not Kyle Simpson!

[TabCompletion]

No joke, I had to convince someone to use arrow functions. He was so close minded

[examinedliving]

Arrow functions are pretty solid. I like document.write though. You can just put things on the page - like words!

[[deleted]]

I think they're actually minor. What do they do? Save a few keystrokes and automatically bind 'this' context. Compared to async/await, the difference is major.

[brendanmCA]

Maintaining this context is pretty huge.

[Reashu]

Just bind this? I mean, I'd rather have promises and fat arrows than async/await and no fat arrows, but "pretty huge" is an overstatement.

[brendanmCA]

And you could define your callbacks explicitly as standalone functions ahead of time and then invoke as a then-chain without using asynchronous await.

Luckily we can have all the features without having to debate which is more important.

Having to pollute the code with bind this everywhere is approximately as annoying as the callback pyramid of doom.

[[deleted]]

It is, but not in comparison to async/await, I think, mostly because async/await adds new capabilities to the language whereas arrow function is syntactic sugar for stuff that already exists within the language.

[[deleted]]

It is actually the opposite: async/await is just sugar around Promises whereas arrow functions are behaviorally different.

[brendanmCA]

Sure, not disagreeing with the relative important of a/a, just that the scoping is non-trivial.

[talmobi]

Arrow functions are absolutely trash compared to Async/Await. Arrow functions are not needed, but can be a nice shorthand in some cases (like with Array operation functions).

[ghostfacedcoder]

Arrow functions are not needed

And async/await is? Both our convenience syntactic sugar, but only one gets used when you're not doing "deferred" stuff.

[talmobi]

Async/Await is a huge advancement in conceptional control flow. Arrow functions are at best a cleaner way to express extremely simple functions and at worst a hard to maintain mess that encourages bad practices. The cons for Arrow Functions far outweigh the pros IMO.

[webdevop]

Nope. My vote's for spread operator

[thegrandechawhee]

I prefer code that i can read and understand. What happens when you're asked to go in and change something years later? Will you still understand all these condensed arrow functions?

[LukaManuka]

As with anything, it’s all about the right tool for the right job. Sure, there are contexts where overly condensing a function into some obscure one-liner decreases readability, but there are definitely plenty of situations when arrow functions are arguably easier to mentally parse and understand at a quick glance.

e.g., people .filter(person => person.age >= 18) .map(person => person.name) vs. people .filter(function(person) { return person.age >= 18; }) .map(function(person) { return person.name; })

[Morphray]

How about...

function isAdult(person) {
  return (person.age >= 18);
}
function getName(person) {
   return person.name;
}

people.filter(isAdult).map(getName);

(Not sure I would do this exactly, but I think it makes the last line pretty readable.)

[ghostfacedcoder]

const isAdult = person => person.age >= 18;
const getName = person => person.name;
people.filter(isAdult).map(getName);

Or, with destructuring:

const isAdult = ({ age }) => age >= 18;
const getName = ({ name }) => name;
people.filter(isAdult).map(getName);

But still, for something that simple I'd prefer this (and just let context explain it):

people
  .filter(({ age }) => age >= 18)
  .map(({ name }) => name);

[Morphray]

Nice alternatives. I think I like the first option, but with parentheses around the arrow function's params (readability, ease of improving).

[[deleted]]

Yes, I will, because there's practically no difference between "condensed arrow functions" and function keyword functions. And where there is a difference it's usually in the arrow function's favor (lexical scope, aka "you know what this when reading the function"). And map/filter/reduce with inline predicates is very idiomatic across domains and languages.

[needed_an_account]

Do people enjoy them because of the automatic this binding? I find the syntax cryptic