7 ms·

> Promise-fatigue JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar ac

> Promise-fatigue JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice. > poor ecosystem Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages. > For the extra tax you pay in terms of build pipeline This pipeline is norm in the frontend development, so in case you have people proficient in tooling, it is not that high (of course, it is hard if you have Java developers). > Typescript vs Javascript as if these are the only two possible options for web development They are not, but the nice thing about it is that you can have almost the same tooling as on your frontend, if you have some sort of complex application. So that increases speed of development, and TypeScript gives you some sense of scalability. Last part is that TypeScript can be adopted incrementally, while another languages will require complete rewrite (and different deployment, etc).

bgorman 8y ago
Other langauges can be adopted incrementally as well e.g. ReasonML and Clojurescript. I am not sure how you concluded that other languages need a different deployment. On the front end everything gets delivered to the browser...
ajxs 8y ago
I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might not actually be as async as you think it is. Of course this is a godsend compared to the callback hell that it replaced, but I can't help feeling that this is the right solution to the wrong problem. In my experience, most of the server-side applications I've seen written in Node are only practically asynchronous at the router level. Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous. With the exception of the rare `Promise.all(...).then(...)`.... If you're using `await` on every single function call, it stops being syntactic sugar and just becomes more syntactic salt.
- sieabahlpark 8y ago
  I think most people think async/await gives them all the previous benefits of async but doesn't
  - orange8 8y ago
    All the previous benefits of async? Did you mean promises, callbacks or async? async/await is just syntax sugar over promises.
  - mschuetz 8y ago
    What benefits don't we get with async/await?
- hn_throwaway_99 8y ago
  I completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java. As you put it, "Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous" but that's because for most people it's far easier to think about a problem as a series of individual steps. Even then, if you have a bunch of serial awaits it's usually pretty trivial to go back and then await on a Promise.all() if you realize things can be run concurrently.
  - ajxs 8y ago
    I think I might not have explained myself too well up there. I was referring to entirely sequential async calls. Like: ``` Thing thing = await loadThing(); Thing other = await thing.doSomething(); thing = await saveThing(); // repeat x1000... ``` I see this over and over.
    - mschuetz 8y ago
      And what exactly is the problem with that? "Thing thing = await loadThing(); ": Start loading thing, then await so the main thread can continue doing other stuff while thing is loaded. "Thing other = await thing.doSomething();": Invoke some other function that does some stuff in the background, then await so the main thread can continue doing other stuff while thing does something. "thing = await saveThing();": Saving can often be done in parallel so no need to block the App while something is saved. Invoke the save function, then await so the main thread can continue doing other stuff while thing is saved. This gets you the advantages of async programming while still maintaining a legible coding style that looks similar to common synchronous code.

bgorman 8y ago

Other langauges can be adopted incrementally as well e.g. ReasonML and Clojurescript. I am not sure how you concluded that other languages need a different deployment. On the front end everything gets delivered to the browser...

ajxs 8y ago

I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might not actually be as async as you think it is. Of course this is a godsend compared to the callback hell that it replaced, but I can't help feeling that this is the right solution to the wrong problem. In my experience, most of the server-side applications I've seen written in Node are only practically asynchronous at the router level. Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous. With the exception of the rare `Promise.all(...).then(...)`.... If you're using `await` on every single function call, it stops being syntactic sugar and just becomes more syntactic salt.

sieabahlpark 8y ago
I think most people think async/await gives them all the previous benefits of async but doesn't
- orange8 8y ago
  All the previous benefits of async? Did you mean promises, callbacks or async? async/await is just syntax sugar over promises.
- mschuetz 8y ago
  What benefits don't we get with async/await?
hn_throwaway_99 8y ago
I completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java. As you put it, "Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous" but that's because for most people it's far easier to think about a problem as a series of individual steps. Even then, if you have a bunch of serial awaits it's usually pretty trivial to go back and then await on a Promise.all() if you realize things can be run concurrently.
- ajxs 8y ago
  I think I might not have explained myself too well up there. I was referring to entirely sequential async calls. Like: ``` Thing thing = await loadThing(); Thing other = await thing.doSomething(); thing = await saveThing(); // repeat x1000... ``` I see this over and over.
  - mschuetz 8y ago
    And what exactly is the problem with that? "Thing thing = await loadThing(); ": Start loading thing, then await so the main thread can continue doing other stuff while thing is loaded. "Thing other = await thing.doSomething();": Invoke some other function that does some stuff in the background, then await so the main thread can continue doing other stuff while thing does something. "thing = await saveThing();": Saving can often be done in parallel so no need to block the App while something is saved. Invoke the save function, then await so the main thread can continue doing other stuff while thing is saved. This gets you the advantages of async programming while still maintaining a legible coding style that looks similar to common synchronous code.