Should base64 advance alone or should it be part of a larger proposal? · Issue #7 · tc39/proposal-arraybuffer-base64 (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

Somewhat related to my worries in #6, I worry that working on a one-binary-encoding-per-proposal basis might have subpar ecosystem impacts. If base64 gets promoted to first-class language support, but base64url or hex require packages, that might not be the best outcome.

I understand from the discussions in #4 that the champions here don't like the API shape of https://github.com/lucacasonato/proposal-binary-encoding, but I think that proposal does a better job of putting multiple binary encodings on equal footing and ensuring they all get implemented together.

(It might also be worth doing some research on other binary encodings; base64, base64url, and hex are the ones I'm aware of from the research in https://github.com/lucacasonato/proposal-binary-encoding, but I guess the relevant RFC defines base32 as well, and I guess there are a lot of them: https://en.wikipedia.org/wiki/Binary-to-text_encoding )