River

Wow so it turns out I was right, Javascript is a gross language that is impossible to read for anybody who isn't already familiar with its syntax.

I come from C/C++ and Python land when it comes to network request stuff, and I'm accustomed to code just executing one line after another. I can get used to the async stuff, but it's pretty damn frustrating that VS Code doesn't even have any indications to tell you when a function is going to be async or not.

There's also seemingly no immediately clean way to just say "don't continue, everything after this is going to rely on the result of this function".

Maybe I'm just bitching because I don't understand how await and Promises work.

#webdev #JS #html #async #raceCondition #programming

Mar 17 at 4:34amWeb
Show threadLesley LaiMar 17
@riverpunk Personally, I think JS is probably one of the easiest entry points of asynchronous programming (compared to C (no high-level abstractions), C++/Python (new, complicated, difficult to use correctly). Asynchronocity is a hard problem that both programmers and language designers struggle with, and I don't think it's possible to have an async abstraction that doesn't add any cognitive overhead compare to synchronous programming
Show threadRiverMar 17

@lesley yeah. It seems JS is the way it is because it's solving a damn difficult problem in program logic.

So it's ugly because it's used to do complicated things. Still doesn't make it any more pleasant for me to interact with. I also wish there were better documentation for what the syntax actually means in terms that people coming from more procedural languages might be able to understand.

Maybe I just need strap in for the ride and learn to love the chaos, idk. I'm so much more comfortable in my little Python & C/C++ bubble of doing things linearly. It doesn't help that my program would technically work just fine without async, except that the library I'm using already built it in (for good reason, ofc).

Show threadBryce DixonMar 17

@riverpunk Promises are kind of the older way of doing things (mostly because they lead to a thousand nested lambdas) which are *supposed* to be replaced by await syntax, but not every library or function supports the new syntax...

Here's the short of what you need to know: Promises take a set of callbacks to invoke in case of success or failure. As an alternative, await says "instead of calling another function, just continue here" and throws an exception instead of calling a function on failure.

It's definitely awkward to get used to, but once you're used to it you kind of wish it was available in other languages like C++.

Show threadLyokoluxMar 17

@riverpunk > There's also seemingly no immediately clean way to just say "don't continue, everything after this is going to rely on the result of this function".

Have a look to Promise.all and Promise.allSettled
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

or await for one promise

Promise.all() - JavaScript | MDN

The Promise.all() static method takes an iterable of promises as input and returns a single Promise. This returned promise fulfills when all of the input's promises fulfill (including when an empty iterable is passed), with an array of the fulfillment values. It rejects when any of the input's promises rejects, with this first rejection reason.

MDN Web Docs
Show threadHaraldMar 17

@riverpunk

You are correct in every statement, including the suspicion that you probably don't understand it fully yet.

The even more awful part is that you will do many more swearing once you understand it fully.

One of my favorites is: when you read "await", you think "wait here", but the execution does the complete opposite and immediately, at this point in your code, returns from the function.

In particular, the rest of the function code is wrapped up in a Promise and this is returned.