mtth / avsc

Avro for JavaScript :zap:
MIT License
1.27k stars 147 forks source link

Dropping support for old Node versions + improving browser support? #418

Open valadaptive opened 1 year ago

valadaptive commented 1 year ago

Since the days of Node 0.x, a lot of things have changed in the Node ecosystem.

When Node was first created, a lot of useful functionality was missing from the ECMAScript standard, so Node created its own set of APIs which were polyfilled by e.g. Browserify.

Over time, APIs covering the same or similar ground have been standardized to work in both Node and the browser, and browser-based polyfills for Node APIs have lost much of their utility--many aren't even being maintained anymore. Browserify has given way to bundlers like Webpack and Rollup which focus less on emulating Node in the browser and more on simply packaging all the code together.

I ran into this when trying to use avsc in my web application--the newest release of Webpack doesn't automatically polyfill Node features anymore, and I had to figure out which polyfills avsc did and did not require to function, then add each one to the Webpack configuration myself.

By dropping support for old Node versions (0.12 reached end-of-life at the end of 2016), a lot of Node-specific dependencies could be avoided, making the project easier to use in the browser. For example, avsc makes heavy use of util.inherits, which could be replaced by ES6 classes. See also #410, which proposes replacing Buffer with the browser-compatible Uint8Array.

Do you have any interest in bumping the minimum Node version (not even to the latest version--just to one which supports ES6), migrating the codebase to ES6, and reducing Node-specific dependencies? I'd be more than happy to do it myself, but I don't want to make massive unsolicited PRs without knowing whether they'd actually be helpful.

mtth commented 1 year ago

Hi @valadaptive. Thanks for bringing this up and offering to help. A PR which migrates the codebase to ES6 and reduces Node-specific dependencies would be welcome. I'd be happy to review it and release a new major version from it. We'll also want to confirm there are no significant performance regressions, for example <5% slowdown on the benchmark schemas.