3 ms·

How? Javascript has a lot going for it from async-everything to conveniences like destructuring. And it works in the browser and has things like Typescript. I

• LargeWu 8y ago
  I would argue async-everything the biggest hassle with Javascript. Most of the time, I need things to run synchronously. Do this thing, then do that thing based on the result of the first thing. The need for async is the exception. So what we end up doing is expending extra effort forcing all the async stuff to run synchronously when that should be the default case.
  • emilsedgh 8y ago
    With the callback methods it was really a hassle. With async/await is so nice now. await step1() await step2() That's it.
    • LargeWu 8y ago
      I get what you're saying, and yes, async/await is much better. But the entire reason it has to exist (and be used everywhere) is because javascript's default async behavior gets in the way so often. The irony is that when I do want some sort of async behavior, I often have to reach for something like bluebird anyway because I want better control over the Promises. So either I'm circumventing JS's default behavior by using async/await, or using a library that makes promises manageable. Almost never is it preferable to me to use JS's standard plain async behavior.
  • duderific 8y ago
    Thank you for summarizing this so succinctly. The true use case for async in the browser is rare. Sure, you're not blocking the UI while making server calls, but how often do you need to click around while waiting for something on the server to happen?