Consider adding `blob.dataUrl()` method, or some other analogue to `readAsDataURL`

Obviously data URLs and base64 in general should be avoided where possible, but unfortunately developers are often interacting with systems/libraries/APIs outside their control, and, practically, readAsDataURL is used a lot.

In fact, readAsDataURL is used about as much as readAsText and readAsArrayBuffer combined:

• readAsDataURL: https://github.com/search?l=JavaScript&q=readAsDataURL&type=Code (1.6 million hits)
• readAsText: https://github.com/search?l=JavaScript&q=readAsText&type=Code (770k hits)
• readAsArrayBuffer: https://github.com/search?l=JavaScript&q=readAsArrayBuffer&type=Code (830k hits)

The blob.arrayBuffer() and blob.text() methods are delightful to use compared to previous methods, but for data URLs / base64 we're stuck with:

let file = ...;
let dataUrl = await new Promise((resolve, reject) => {
  const reader = new FileReader();
  reader.readAsDataURL(file);
  reader.onload = () => resolve(reader.result);
  reader.onerror = (e) => reject(e);
});

which is the opposite of delightful. This is one of those cases where I'm "embarrassed" by how convoluted a simple task is in JS when helping someone who is new to JS.

There are a couple of proposals that are related to this issue:

• https://github.com/lucacasonato/proposal-binary-encoding
• https://github.com/tc39/proposal-arraybuffer-base64

That said, I really like promise-based blob.methodName() approach, and I'm hoping that we'll eventually get something like that for data URLs.

No repository file or test is identified in the issue. Start by reviewing the existing Blob arrayBuffer() and text() methods alongside the linked binary-encoding and ArrayBuffer base64 proposals, then determine whether a promise-based data URL API has a defined direction. Done requires an agreed API design rather than a localized edit.