btoa() and atob()

[silverwind]

All major browsers expose the btoa and atob globals for encoding ASCII strings as base64 and vice versa. It'd be beneficial for the "isomorphic" javascript topic if we'd provide these too:

• https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/btoa
• https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/atob

As for the implementation, we can't Buffer('string').toString('base64') because that would encode unicode while atob and btoa must per spec throw on charcodes > 255. https://github.com/mathiasbynens/base64 looks like a solid implemenation we could pretty much drop in.

[MylesBorins]

I'd be up for writing a bunch of tests if people want to see this happen

[jasnell]

While I understand the desire on this, it could just as easily be implemented as a userland module that registers the globals. I'm -0 on adding it in to core.

[mscdex]

I think I'm -1 on this for the same reason.

[trevnorris]

function btoa(str) {
  if (Buffer.byteLength(str) !== str.length)
    throw new Error('bad string!');
  return Buffer(str, 'binary').toString('base64');
}

Think that will about cover it.

Update: actually, that's a bad length check and I'm too tired to work the correct one. we'd probably have to expose v8::String::ContainsOnlyOneByte() for the fastest option.

[Fishrock123]

I'd rather not add more globals, ever if possible.

[tflanagan]

The fact that you are linking to a userland package that already gets over a 1000 downloads a week (via npm) is solid evidence that the need for this, in core at least, is very minimal

[silverwind]

By the way: Why doesn't v8 provide functions like these?

[bnoordhuis]

They're browser extensions, they're not part of the ECMAScript spec: https://html.spec.whatwg.org/multipage/webappapis.html#atob

[jasnell]

Feel free to continue discussing, but given the -1's, I'm closing.

[buzinas]

The fact that you are linking to a userland package that already gets over a 1000 downloads a week (via npm) is solid evidence that the need for this, in core at least, is very minimal

In fact, that's because everyone uses the packages atob and btoa, e.g:
https://www.npmjs.com/package/atob

~500k downloads per month

[kav]

The fact that you are linking to a userland package that already gets over a 1000 downloads a week (via npm) is solid evidence that the need for this, in core at least, is very minimal

Regarding the above. Isn't the fact that thousands of users are using a userland package for this a reason to include it rather than the reverse?

Perhaps I'm confused but if the userland package had very few downloads wouldn't you find yourself saying; "well no one really seems to need this". I know I would.

A bit lost on the reasoning.

[addaleax]

The reasoning here is that the situation seems quite well for everyone without something being provided by Node core.

[kav]

Yes but isn't the existance of a rarely used userland package also a valid reason to say it shouldn't go into core? So if either a userland package is used a lot (per your comment) or a little (per mine) it shouldn't be in node core. How then does that have any bearing on the question at all?

[bmeck]

looking at WHAT spec btoa/atob only handle strings with 8bits, so emoji etc. will throw errors, likely those APIs are not sufficient, but I do not see a web API that does universal base64 transformation except FileReader.prototype.readAsDataURL.

[MylesBorins]

for base 64 there is https://en.wikipedia.org/wiki/Base64#RFC_4648

I have helped to maintain a library that has quite a bit of usage in this space

https://github.com/brianloveswords/base64url with 877k weekly downloads.

Could be worth looking at that for API inspiration

[jasnell]

Opened a pr that implemented this and the immediate reaction was meh given that our current mechanisms for this are better and it's something that is easily handled by userland. Closing the issue as it's not something we're likely to land.

[devinivy]

In nodejs/citgm#852 (comment) it was flagged that there are some new globals in node v16 including atob() and btoa() that our test suites should account for. If these are here to stay we'll ensure our test suites allow these globals, but based on what @jasnell mentioned above it seems like they may not land in node v16. Any clarity on this would be much appreciated!

[cjihrig]

@devinivy these landed already, so I think it's safe for lab to start tracking them as allowed globals.

[Tofandel]

It's weird, so most people were against it but it landed anyway under the radar..

[jasnell]

@Tofandel ... there is no "under the radar" here. All changes go through the same review and approval process before landing, and all discussions/reviews are public.