Consider using web standard APIs, swap EcmaScript-only approaches (like `Buffer`) for native bindings

[mikedotexe]

Prerequisites

• I'm using the latest version of near-api-js.
• I have tried to start with a fresh project and reproduce the defect with minimal code changes. (Not a bug report, an improvement)
• I have read the console error messages carefully (if applicable).

Description

I believe there's a solid opportunity to make a handful of changes such that near-api-js can compile down to many (any) JavaScript build target.

There are some usages of Buffer for instance, which works great in NodeJS code or Node REPL, but are not compatible with CommonJS, which is "the OG JavaScript" that many people desire to use for various reasons.

Buffer can actually be replaced by Uint8Array which has the green flag of "baseline widely available" which is great.

There are a couple dependencies in near-api-js that can be removed because of another Web API Crypto. For instance, we can securely generate random bytes using Crypto.getRandomValues

Another example of a healthy replacement is the TextDecoder API, which can be utilized. These are built into the sort of foundational layer of JavaScript, which isn't always advertised but quite powerful.

---

The effect of making these changes means people will be able to use near-api-js in systems that don't require an npm/pnpm command or app.

Reproducible demo

No response

Steps to reproduce

This isn't a bug but instead "help us improve" part of that selection. The steps to reproduce are running the existing scripts in package.json

Expected behavior

The JavaScript library is able to be used by developers who may not be using NodeJS or wish to use EcmaScript for their project. I see that the near-connect repository is one of those that wishes to do this and has accomplished it for quick load and execution without dependencies.

Actual behavior

Same functionality as before, just using different native bindings and Web APIs built into modern JavaScript in ESM and CJS

Your environment

(Not a bug, but an improvement suggestion)

Self-service

• I'd be willing to fix this bug myself.

[mikedotexe]

fellow countrymen, it seems we can make NEAR's JS library hyperefficient, as results are showing for in-flight work I'm doing at the moment:

this is showing how near-connect (approach from docs) could shrink wallet sizes when pointing to my local changes to near-api-js. Pretty crazy to see, and there are a few culprits but I think polyfills is a big one.

So I'm looking to open a PR to generally shrink everything, but keep all the same API, tests, tests passing, etc. But it's going to feel like one of those whoppers that takes energy but hopefully is not straining.
Last thing, I want to give a small history where I worked hard on this before last year's ETHDenver, before Claude Code was exceptional. So I've pointed AI at the repos and the work I've done isolated from near-api-js that proved out some efficiencies. But now seems like a time to contribute back, and likely sunset FastNearJS as a useful spike and proving out a concept. But I wouldn't want someone asking AI to build something on NEAR, and having more than one JS API.

and kudos to the fresh maintainers, and the solid major release recently. it made a lot of great progress with something i work on day-to-day. anyway, this PR comment giving an update.