为什么这个异步/等待 function 返回 promise？

Question

I'm not sure why the following function returns a promise, when I'm using the async / await operators?

getBase64 = async (url) => {
  const response = await axios.get(url, {
  responseType: 'arraybuffer'
  })

  const buffer = new Buffer.from(response.data,'binary').toString('base64')
  return ('data:image/jpeg;base64,' + buffer)
}

I know I can simply add .then(data => console.log(data)) but I want to assign the raw data to a variable, like:

const base64Img = getBase64()

...which is not possible since the return type is a promise for some reason.

Answer 1

An async function is just a promise. If you want the value returned, you will need to await it as well.

const bas64Img = await getBase64()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

Answer 2

The short and admittedly not very telling answer to why async functions always return a promise, is because the ECMAScript specification, which defines how async functions behave, mandates so .

It is the rationale behind their choices I will attempt to explain, but I can tell you already that it is related to some other relevant parts of the language specification such as execution contexts , jobs and job queues .

Those specifications were put in place partly due to historical reasons -- ECMAScript originating as JavaScript in Web browsers and the way these went about allowing scripting of Web pages. Since the language was standardised after multiple implementations had been in place for a while, ECMAScript was defined retroactively, in part:

The fifth edition of ECMAScript (published as ECMA-262 5th edition) codified de facto interpretations of the language specification that have become common among browser implementations [...]

(from the 7th paragraph of "Introduction" )

In any case, crucially, ECMAScript does not allow parallel script execution -- a JavaScript function call, for example, will never be interrupted by any other function call, period. Not within the same realm (in Web browsers one realm is associated with one single rendered Web page).

We can dig deeper into the "why" if we imagine a JavaScript runtime tasked with calling an async function, and see what it would take for the runtime to arrange for returning the actual value, when the value would depend on an asynchronous operation. So let's use your getBase64 function as an example. Now, we would obviously be violating the language specification doing this, but it's just to arrive at an explanation.

Looking inside the body of getBase64 , let's assume that axios.get(...) is a potentially lengthy operation because it fetches a resource on the network. If we assume it isn't, getBase64 does not have to be async , cannot use await , and behaves like a regular function. So, for the sake of this answer, we do assume it involves a lengthy operation, and we do not have the value for response before this lengthy operation completes. axios.get may be fetching a resource over network, but the nature of the operation doesn't really matter, what matters is that the operation may potentially take longer time than completing execution of the entire script otherwise would.

So, can we continue executing the body of getBase64 and return before axios.get(...) completes? For the sake of the argument, we could execute some parts of it that do not depend on the promise returned by axios.get(...) being resolved. That's called automatic code parallelisation. ECMAScript does not define that and may not even allow it. Few languages do. But as I mentioned, it is otherwise technically possible to evaluate those statements in the function body that do not depend on the resolved promise, but in any case, the return value of getBase64 depends on response , indirectly, so we at least need the lengthy operation to complete before returning. That's the important thing.

So if we cannot return yet, we have to wait for the promise returned by axios.get(...) to resolve. I mean, one way or another we need to have response before returning a value from getBase64 .

Here is where it gets interesting. A scripting runtime always has an environment it actually scripts. Part of this environment may be the browser window ( window ), a Web page ( document ) or something else entirely. As a notable example of a compliant ECMAScript runtime, Node.js has an environment, too. A question then comes to mind -- what to do if an event needs to be dispatched by the environment while getBase64 is waiting for the axios.get(...) to resolve? There may be an incoming network request (Node.js) or user clicking on a link (Web browser). You have an event listener attached, too (wouldn't be much point in having events you can't react to, would it?). Now, do you call and start executing the event listener while the getBase64 call is waiting for response , or do you wait for execution of getBase64 and the rest of the script (think of the call chain) to complete, risking poor user experience for having user wait for potentially "long" time (the network is "slow", for example)?

If you start executing the event handler, you invariably end up with two script execution contexts in parallel -- the event handler execution and the getBase64 call waiting for axios.get(...) to resolve. In effect, your event handler is executing while getBase64 is still in progress, even if the agent only uses one single thread of execution where the former pre-empts the latter. It's still parallel script execution. This is no small matter -- behaviour of your script, in particular the order of statements being executed, now depends on the event timing, You will have to deal with potential race conditions. and state synchronisation problems in general.

If you do not allow parallel script execution, you have to serialise it. Meaning finishing one script execution -- completing the getBase64 call and the rest of the script that ended up calling it, for instance -- and only then starting another, like execution of an event handler.

This is what ECMAScript designers went for. They decided to forbid parallel script execution in return for the simplicity this gets developers by freeing them from having to deal with an entire class of parallel programming problems briefly mentioned above. This constrains runtime developers in a way where different compliant runtimes executing same script will evaluate the statements present in the script in the same order, and not depending on event timing, for one.

Some may call this overspecification of the language, but I believe I have made some sort of a case for it. In any case, JavaScript had much more modest ambitions before it was standardised, and relative ease of scripting attainable by avoiding situations that stem from parallel script execution, and a simpler Web browser architecture as a result, in a time when no one spoke of CPU "cores", were priorities. ECMAScript standardised that behaviour with a rigidly specified model.

This of course still leaves us with a problem of "freezing" pages when script execution takes too long to complete, since executing event handlers and anything affecting the environment exposed to scripts, must be delayed until current execution completes. And if you ever tried to calculate anything complex enough in your page scripts, you know what I mean. No two script executions happen in parallel. Execution of callbacks for intervals, timers, promises and other operations are queued and done in their own execution contexts, as is script execution. These and other jobs -- actual progression of network requests and operations initiated by different kind of APIs -- use ECMAScript job queues. On top of that, HTML specifies something called event loops which also use job queues internally. These specifications rigidly define how events are handled, when callbacks are fired by different APIs, and otherwise still allow the scripting environment to stay responsive between hopefully short-lived script executions.

In actuality, async function execution, as you may have discerned from the "AsyncFunctionStart" definition of the specification , is split into multiple jobs at well-defined points. True to the specification, there is no parallel script execution going on, yet the function still effectively "waits" with every await expression.

So in conclusion yes, we technically could have async functions always return the values you tell them to return with the return keyword, but you would be trading in great deal of simplicity of JavaScript development in return for a different kind of "simplicity", allowing interruptions of async functions (interleaving execution contexts in general) in order to mask callback/promise handling and be able to directly work with return values, but needing to watch state changes more closely and ever being wary of the runtime peculiarities. The ECMAScript designers made the choice for you.

Why can't some async functions return "actual" values?

Even without allowing of parallel script execution, technically nothing would stop an async function that doesn't use await from returning the value you intend it to. Such function would be able to execute to completion without waiting on any promise. Basically it then behaves as an ordinary function, being async "in name only". But you'd be violating ECMAScript specification which mandates that async functions always return a promise. Again, a decision by designers of the ECMAScript specification.

The reason behind their decision isn't known to me, but I dare argue it is so that one wouldn't have to look at the implementation of an async function ("are there any await keywords here?") in order to know how to use it -- one can use the same kind of code (like using await ) for calling the function and handling the result, simply knowing if it's async or not. If it is, you'd be using await foo() or foo().then(result => {... }) where foo is such async function, and it would always work no matter if execution of foo itself includes await or not ( async function foo() { return 1; } ). You wouldn't need to look at its implementation. I think this is called a "calling contract".

Why can't one use await without async ?

In a similar manner to the rationale explained above, the decision to mandate functions be marked as async in order to be able to use await is, again, a choice on part of ECMAScript designers. ECMAScript could allow any function to use await but then, because the language does not allow parallel script execution, any such function would need to return a promise lest it severely impact due event handling. Assuming the former and staying with this thought, either all functions would then be returning promises, or only those that use await would be. All JavaScript functions always returning promises would probably be considered a terrible idea by at least ECMAScript designers, and the sentiment you yourself express with your question would seem to share their opinion. Having only those functions that use await always return promises, while a better idea, will imply that the type of value being returned by a function varies with the function's implementation , something that sort of flies in the face of the principle of "calling contracts", again -- you would need to know whether foo uses await in order to know how to work with the result of calling this foo . ECMAScript designers opted against it, expectedly, in my opinion, and this is why functions that use await must be explicitly marked -- with async .

Also, both specifications arguably help make for more optimized language runtimes.

---

¹ I use "ECMAScript" and "JavaScript" interchangeably -- discussing the distinction, if any, is beyond the scope of the answer and should in any case have little bearing on the argument.

Answer 3

Because it gives you a choice what to do. The code below async function invocation can be run immediately or it can wait till the async finishes.

You can even have some code that depends on async result to wait for a function to complete and some other code that doesn't care about the result run immediately:

someAsyncFunction().then(v => {
  // here goes the code that depends on v
}

// here goes the code that doesn't care about async completion

In blocking languages that behave just how you want it you can't do this. The rest of the code must always wait.