Why is crypto.subtle.digest designed to return a promise?

Every other system I’ve ever worked with has the signature hash(bytes) => bytes, yet whatever committee designed the Subtle Crypto API decided that the browser version should return a promise. Why? I’ve looked around but I’ve never found any discussion on the motivation behind that.

  • Technus@lemmy.zip
    link
    fedilink
    arrow-up
    1
    ·
    4 months ago

    It executes on a native thread in the background. That way it doesn’t stall the Javascript execution loop, even if you give it a gigabyte of data to hash.

  • vzq@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    1
    ·
    4 months ago

    It’s standard for operations that take a while and can be performed asynchronously.

    What’s your problem with it?

    • Ethan@programming.devOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 months ago

      async/await infecting all of my code, being unable to create a get myField() method that involves a hash calculation. It may be standard to do heavy lifting concurrently, but async hash functions are certainly not standard in any of the languages I’ve used (which is quite a few).

      • vzq@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        1
        ·
        4 months ago

        From browsing your other comments on this thread I understand that you are in a context where you can’t await, that you expect the invocation to take very little time, and that the library offers no complementary sync interface.

        As far was I know you’re stuck in this case. I consider the stubborn refusal to add “resolve this promise synchronously right now” a major flaw in js.

        • macniel@feddit.de
          link
          fedilink
          arrow-up
          0
          arrow-down
          1
          ·
          edit-2
          4 months ago

          Given the nature of JS running only on a single thread. Promises/asynchronity is the only way to keep the browser from locking up.

          Thus insisting on any other way is a major flaw in the developer not the language.

          • vzq@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            1
            ·
            4 months ago

            Thus insisting on any other way is a major flaw in the developer not the language.

            I mean, I understand the idea, but this is a pretty asshole way to frame it. I don’t think I deserve that, and certainly OP doesn’t deserve that.

  • macniel@feddit.de
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    its a good idea to be as non blocking as possible especially on time and resource consuming tasks like IO, cryptography, …

    just use await in an async function.

    • Ethan@programming.devOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 months ago

      just use await in an async function.

      Sure, I’ll just put await and async everywhere. Oh wait, I can’t. A constructor can’t be async so now I need to restructure my code to use async factories instead of constructors. Wonderful…

      • macniel@feddit.de
        link
        fedilink
        arrow-up
        0
        ·
        4 months ago

        Sounds like an architectural issue to begin with. A constructor shouldn’t do the heavy lifting to begin with.

          • macniel@feddit.de
            link
            fedilink
            arrow-up
            0
            ·
            4 months ago

            The API doesn’t restrict the amount of bytes to be hashed. So yeah it’s still heavy lifting.

            Trigger a loading event after the constructor is finished that the view model takes to calculate your hash.