JavaScript Motherfucking Asynchronous Bullshit.

I get it, for quite some stuff, async is very, very useful. But why on fucking earth do so goddamn many functions NEED this (and those callback functions) and can't do without?!

If there would be good and nicely understandable await documentation that actually fucking works, I'd be so happy.

I've currently got .then after .then after motherfucking then and its irritating me to no end as it, in this context, shouldn't even be necessary. This thing I'm writing doesn't give a fuck if something takes a few milliseconds before the rest of the program can continue!!

Fuck asynchronous programming in JavaScript for goddamn everything.

(I do love JavaScript!)

I agree, I hate that I can't choose whether I want an async function or not and just have to make 5 nested callback functions or awaits to get a synchronous program to work

@alexbrooklyn Any good sources on await? I still can't figure out how to use that right 😬

@highlight
(async () => {

let a = await async_fn1();
let b = await async_fn1();
...

})();

Because the browser still needs to be able to render all your cat or fox gifs while executing javascript, or rather "executing javascript". So if you're doing something like waiting for resources, waiting a couple of ms to play an animation, drawing a loading bar, and more stuff then you wouldn't wanna give your users a bad experience by freezing the page. That's why you need it.

As for how to get it, well I used to feel that way too, the whole "durr this shit is so difficult" whenever I read about it. Then I actually tried it out, played around with it, and found to my shock and horror that it wasn't so difficult after all.

Try something like axios, and instead of actually copy pasting the code examples write it out. https://github.com/axios/axios

@Ubbe I do async stuff all the time in C++ now. Any communication with external resources requires some kind of callback system. You could spin off threads for intensive stuff, but you are still stuck doing some kind of communication to that thread. Async is here to stay AND will INCREASE as apps move to more cores. The libraries I use now require async approaches anyway.

Async isn't going to get better.

@inaba While I agree with that, this is a node CLI application where the process has to wait for the result regardless.

It would be nice if it would be an option to do it synchronous or something like that

@linuxxx if you go ham with await you can basically force your way through it, wont be pretty tho'.

@linuxxx since node is build on top of V8 you still have the async nature of it all. It's also built with http servers in mind to which having everything be blocking by default isn't very nice. Having the time and callback in setTimeout be swapped wouldn't be a bad thing as well but hell I'll live with it. And tbh once you get used to using async and await it's really really nice, especially later on.

@linuxxx And what would be the difference between

try { await asyncX() } catch(err){ }

and

try { synchronousX() } catch(err){ }

except for the obvious part that it would totally block the main thread?

@hitko everything nothing at all, it depends on context. You're using it in your CLI app? Fuck all. You using it in an app with multiple things happening? Everything

There are pretty good talks about async/await and promises in JS, which helps to understand the concepts/what they are ment for (since, they're different from example async stuff/threads in C)

Don't forget your catchs after your thens 😎

@olback that sounds just like fancy good old

@Wack yep, only difference being support for await.

So... Async/Await (and promises) can be (in theory) of the main thread, while I think `window.setTimeout()` is on the main thread. Any other differences?

const result = await new Promise(async (resolve, reject): Promise<any> => someSyncFunc(params, (err, val) => err ? reject(err) : resolve(val)));

await new Promise((resolve, reject): any => {
try {
resolve();
} catch (e) {
reject(e);
}
});

.then is ugly as shit

If your gonna learn Node/JS, should learn about the event loop and the difference between single thread and multithread languages.

My team building JS APIs... but after years still don't understand this and their code in a barely JS way because they never fcking understood how it works.

I'm actually stuck trying to fix a piece of code now because it somehow ended up hanging the server... Which only happens if there's a memory leak.... Or something fcking blocked the event loop/thread...

@billgates really javascript becomes so much clearer once you learn bout the event lop and the event queue and how they relate to the call stack and how the singlethreadedness of the language is actually kinda misleading

@inaba well the q can't process of the loop can't run?

My issue is there server is accepting connections but doing nothing with them and I think that's because the either thread that's actually processing the q is stuck on a single task

@billgates the queue can't really do anything unless the call stack is empty and the loop isn't blocked (which it usually is by there being something on the call stack). But tbh the que just saves information about functions (callbacks) that can be run whenever the call stack is empty

@linuxxx if it makes you feel any better I'm a "senior-level" programmer and use async/await/promises every single day and still fuck them up every time and have to relearn it every day. Not sure how I picked up on machine learning faster than async-await haha.

Agreed complete bullshit!

First up readability goes down the toilet!
Then everything is fucking returning promises--no one likes writing code function within a function within a function

Heck, I was trying to build an analytics dashboard using d3.js & same FUCKING PROBLEM!!!

d3.csv(path) ---> returns a PROMISE, WHY? FUCK THIS SHIT! This forces the developer to write all the code, be it plotting/wrangling inside the then clause--i.e.
d3.csv(path).then(data => {
//all the motherfucking logic for plot/code/data-cleaning/regex goes here!! it's fucking stupid!!!
})

Why isn't it like python!

data = pd.read_csv(path)--I can wait for few milliseconds

and then continue the logic for plot/code & shit. FUCK JS

@alexbrooklyn I retract my statement

I love it now with async/await

I DO FUCKING AGREE MAN

GUYS PLS UPVOTE ME IMA DO THIS MY PFP