221–230 of 242 posts
Earlier quoted context omitted.
I felt the same way coming from a threaded language. Learning the event loop, then promises, then async/await is a must. Today, you probably should throw typescript on top. A steep learning curve just to get back to a typed language that can do things concurrently. You do get used to it, but it is a mess of stuff.
This is ridiculous. Handling real threads is much more complicated than handling async calls and the event loop of JavaScript.
I believe author misses one important point. Async/await optimizes for throughput, not latency. Use case is many lightweight tasks you want to parallel as wholes. Web APIs, web sites are usual examples. However, if you need other kind of optimizations, like two parallel saves within one request, maybe async/await is not what you need in the first place.
The performance characteristics of promises and async/await are identical, no?
Now maybe it’s just my familiarity with Promises, but I look at the third example and I can quickly see an opportunity. This entire article is built around the author's ignorance and could easily be summarised as "I avoid async/await syntax because I'm more familiar with promises". The author doesn't even appear to understand that async/await is syntactic sugar for promises.
I didn’t read the article like that at all. How would you handle two asynchronous saves which can happen in parallel without using a Promise.all? Don’t think you can…and that’s pretty much the entire point of the article. Async/await is useless unless you are willing to serialize your calls defeating the entire point of async code.
const fooP = fetch(a)
const bar = await fetch(b)
const foo = await fooPEarlier quoted context omitted.
I felt the same way coming from a threaded language. Learning the event loop, then promises, then async/await is a must. Today, you probably should throw typescript on top. A steep learning curve just to get back to a typed language that can do things concurrently. You do get used to it, but it is a mess of stuff.
This is ridiculous. Handling real threads is much more complicated than handling async calls and the event loop of JavaScript.
Even if concurrency is easier to get right on node I'd say the node ecosystem has just layered on complexity in other ways to get to something just as difficult to use overall.
Promises and async/await sugar are only the tip of the iceberg.
Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify when I didn't want that behavior. So much boilerplate, so many times I've seen bugs that are the result of not being aware of a function being asynchronous or that the function was later made asynchronous. Most of the time you want seemingly synchronous behavior…
The amount of effort JS programmers have to go to in order to write synchronous code that is legible, works and easy to understand is enormous. I am a Bad Programmer so accept that some of it is just my lack of willingness to spend the time to get over that hump but I find it almost impossible to believe the gains are worth the costs.
But the async/await/Promises only make the code look synchronous because it actually makes the code synchronous. The await literally blocks the current thread, it's nice that the code is executed in a thread scheduler but I'm still blocking the current thread. How this was accepted as a big win is not clear to me. If you want to make it asynchronous you still have to write .Then(()=> {}) which is a nested function. S…
I thought "async io" was supposed to be superior to "blocking the thread". The unit of computation is "smaller" than an os thread, right? It's cooperative multitasking, where thread-per-task is not cooperative. Maybe you were using "thread" symbolically?
Earlier quoted context omitted.
IIRC that doesn’t actually happen if a native Promise is returned.
It does, but only if you also add a redundant await. Which I still do, even in TypeScript, unless there’s a compelling performance reason not to. I disagree with the article overall, but I do agree that making asynchrony as explicit as possible is a good idea. Otherwise you end up with code like: async function foo(bar) { // ... } function nonObviousAsyncFn() { // ... return foo(quux); } Explicit return types would h…
return await foo();Earlier quoted context omitted.
You really end up creating promises manually, the vast majority are downstream from an IO call like fetch() or a database query.
Many devs unnecessarily nest Promises like that. async function getData() { return new Promise((resolve) => { const res = fetch(…); resolve(res); }); } The response above is wrapped in THREE different Promises! One from fetch, one manually created, and one implicitly created by `async`. The code above behaves exactly the same as function getData() { return fetch(…); } or even just fetch(…);
Earlier quoted context omitted.
The whole async/await paradigm (including promises) is trying to fit square pegs into round holes (trying to make async processes look like they are synchronous). Just look at the comments on this page; even though async/await/promises have been around for years they are still causing difficulties for even the most experienced devs. It doesn't mean it can't be mastered, it can, but the whole paradigm is so fraught wi…
> simple thenable object Wouldn't you simply be reinventing promises?
The usage of such an object won't be as terse and seemingly elegant as await syntax, but this is part of the problem: with await/promises so much of the complex logic is hidden from view and instead needs to reside the head of each dev, where it needs to compete with a thousand other things that need attention. It's an expression of the constant but unhealthy tendency towards golfing that pervades our field IMO.