• emerald@lemmy.place
    link
    fedilink
    arrow-up
    57
    arrow-down
    1
    ·
    2 years ago

    If your code is that deeply nested, surely something has gone horribly wrong, yes?

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      link
      fedilink
      arrow-up
      25
      arrow-down
      12
      ·
      2 years ago

      Problem is that Js kind of encourages this being single threaded and using callbacks for anything blocking. To be fair, the new async syntax sugar helps in modern Js, but nesting a bunch of callbacks or promises was basically the way you did stuff for the longest time.

        • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
          link
          fedilink
          arrow-up
          6
          arrow-down
          6
          ·
          2 years ago

          I’m not arguing that avoiding deep nesting is a good idea, or that techniques foe doing that don’t exist. I’m just pointing out that Js style programming naturally leads you to nesting things because of the nature of callbacks. Notice how your example isn’t using callbacks.

            • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
              link
              fedilink
              arrow-up
              2
              arrow-down
              8
              ·
              2 years ago

              Sure, you end up passing higher order functions around, and my point is that complexity obviously goes up. There’s a reason callback hell is a well known thing in Js land. Meanwhile, Js is single threaded from user perspective. The fact that there is a background rendering thread in client side js is completely tangential to the discussion.

              Finally, the problem with callbacks is generally seen in server-side Js runtimes. A great example is if you have an HTTP handler that needs to get data from a db. In a language with user accessible threads you just make a db operation synchronously and return the result. In Js, you have to do a callback. The reason you can do the operation synchronously when you have threads is due to the fact that HTTP handler thread can accept a request and then dispatch a new thread to handle it while waiting for other requests.

                • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
                  link
                  fedilink
                  arrow-up
                  2
                  arrow-down
                  8
                  ·
                  2 years ago

                  Js is single threaded from user perspective. You have no access to the threading runtime as a user and cannot spawn a thread in Js to do some background work. Workers are a recent addition, but using them is quite different from what I’m talking about.

                  And being stuck in a while loop is precisely why people have to use callbacks and why all the APIs are async. This is literally the problem. If you’re dealing with any non trivial load, you are forced to use async mechanics.

    • Blackmist@feddit.uk
      link
      fedilink
      English
      arrow-up
      5
      ·
      2 years ago

      I prefer a bunch of

      if (fucked_up) {return(error_code);}

      for checking common errors.

      • DWin@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        2 years ago

        Yup, never nest.

        All the conditions should be checked and returned if they failed as you go through the function with the successful response being the last line.