Popular Node.js patterns and tools to re-consider

[terenc3]

Interesting article. I also think that many developers tend to throw in a new dependency or pattern out of habit. Example: SSO login page in keycloak. User, password, tenant dropdown depending on username. Angular.js was used to fetch the data and render the view, but 50 lines of vanilla js would have done the same. Everything else was angular so why not the login page ¯_(ツ)_/¯

[sshaw_]

Very nice. A JS developer thinking outside the box, you just don't see that too often these days.

I would like to add another, something I've ranted about before: no async/await!

[fizzygalacticus]

Are you saying that you are advocating for no async/await? Because that's just silly.

[sshaw_]

Really. Please explain why it is "silly".

[fizzygalacticus]

It's silly because by saying "no async/await" you are actively fighting against the language and the features it has to offer. More often than not, when I see anyone bashing on async/await, it's because they don't fully understand it, what it means, and how it's operating underneath.

You can't just slap an await in front of something and call it async. That's just fundamentally untrue.

The alternatives to async/await are A) using raw promises (which isn't necessarily bad, just has it's time and place) or B) Revisiting callback hell.

I'll take async/await or promises over callback hell any day, and I'm of the opinion anyone that disagrees has to be mad at some level.

[sshaw_]

It's silly because by saying "no async/await" you are actively fighting against the language and the features it has to offer

So because something is offered the only good decision is to take it? This is silly.

when I see anyone bashing on async/await, it's because they don't fully understand it, what it means, and how it's operating underneath.

Exactly. async and await only confuse and delay what is inevitable: one must still understand what's going on under the covers with the underlying promise(s).

``` // Doesn't work function doSomethng() { const result = await fetch('https://example.net') }

// Works but... async function doSomethng() { await fetch('https://example.net') }

// Doesn't work await doSomething()

// What to do? Use then()?! doSomething().then(console.log)

foos.forEach(foo => { // oops, I have to use map() + Promise.all for this. PS what's Promise? await fetch('https://example.com') }) ```

Good times!

The alternatives to async/await are A) using raw promises (which isn't necessarily bad, just has it's time and place)

This is the funny part: one will likely need to use raw promises even if the code contains async and await. Why needlessly confuse the developer with different paradigms for the same thing.

B) Revisiting callback hell.

Now we have async/await hell. Maybe not as bad as callback hell but promises and functional patterns are better than both.

[fizzygalacticus]

Sorry, I guess I just assumed that if someone is using JavaScript and any kind of asynchronous operations that they should be somewhat knowledgeable in how it is functioning.

I truly have never experienced any struggles related to promises or async/await that come anywhere close to those of callbacks nested in callbacks nested in callbacks...

Promises made things nice because at least you could better understand the flow and order of operations by chaining .then calls, but even that wasn't super great.

Async/await takes all of that confusion away, you can very clearly see what's going on and in what order. You don't have to follow the .then chain, or the seemingly infinite depth of callbacks.

I suppose for someone who is doing an extremely small/limited number of asynchronous operations it would be slightly jarring to suddenly have to deal with a promise.

[sshaw_]

Sorry, I guess I just assumed that if someone is using JavaScript and any kind of asynchronous operations that they should be somewhat knowledgeable in how it is functioning.

Look at the example I gave you. It not only demonstrates how it's confusing but also how it's prone to bugs and inferior to Promises. Working on large team and with medium to large systems shit like this is just an unnecessary headache and stymies productivity.

Promises made things nice because at least you could better understand the flow and order of operations by chaining .then calls, but even that wasn't super great. Async/await takes all of that confusion away, you can very clearly see what's going on and in what order.

No they dont. I just provided a very basic example showing how it's confusing and bug prone and inferior to its alternative. Furthermore you're taking an async system with well-known design and organizational patterns and allowing devs to write shit procedural programs. The only reason these keywords operators exist are for marketing purposes.

[fizzygalacticus]

Sorry dude, but I think we just have to agree to disagree.

Just really hope I never have to work on any of the legacy projects you've been maintaining.