Replace Buffer with Uint8Array using DataView for encoding and decoding

[Borewit]

Implements #245

• Replace Buffer with Uint8Array using DataView for encoding and decoding.

Related: Borewit/tokenizer-token#4, Borewit/strtok3#522, Borewit/peek-readable#330

[jimmywarting]

Good job, don't have so much to say. Did not expect a PR/Fix this fast.
Maybe requires a new major release now?

...Since it returns BigInt for 64 bit values now instead of a number - it's possible to cast the BigInt into a number by doing something like Number(3n) but i guess that ppl that want 64 values wants to work with bigint rather

• you made a TextDecoder a requirement now which is good for not relying on Buffer

[Borewit]

Thanks for your review @jimmywarting

If I release this, it will be major release for sure.

I started to experiment with strtok3 & music-metadata offline with these changes, and it quite a challenge to adapt to these changes.

• Lack of UintArray copy function (combination of Uint8Array.slice and Uint8Array.set can do the trick)
• TextDecoder is not supporting the same encoding types as Buffer,: 'binary', 'ascii', 'ucs-2'
• Lack of toString('hex'')

There is quite a bit of work left to do, and I need to be careful check if it worth the changing. Thing do not seems run faster from these changes, but I done proper measurement yet.

[jimmywarting]

Thing do not seems run faster from these changes, but I done proper measurement yet.

Buffer might be faster or equally fast as dataview in node but the browser polyfill maybe isn't as fast... Not entirely sure. But at least you won't need the hole buffer module in browser

[Borewit]

The vast majority of music-metadata users are Node.js users: ~ 75k vs 5k download/months, or 4544 vs 177 dependent projects if you prefer. If I can do something for the browser users that is great, sure, but I will never satisfy most of the potential users, as many of the user will not use this library because they think it to big. Therefor I would like to avoid a quality decrease for Node.js users.

For file-type users a small difference in performance is probably less very noticeable.

[Borewit]

Rebased this PR.
The migration to BigInt has now taked out of this PR and is covered in #300 (already merged).

[Borewit]

Thanks for your review @jimmywarting.

I am trying to migrate token-types, strtok3, @tokenizer/token, peak-readable, file-type and music-metadata toward more recent general purpose API definitions.

Full dependency tree: npmgraph.js.org

Lot's of challenges so step by step.

[jimmywarting]

Nice readable graph, how did u get it?
I have used https://npm.anvaka.com/#/view/2d/music-metadata a bit to scatter around often where i can cut of some old packages by updating them to newer syntax or looking at which package i can cut of and replace with something else to reduce the # of dependencies

---

I could offer to help but i literally hate typescript syntax, wasting time compiling, getting garbage output and not following the standard. I like the typing doe, that why i use typescript only with a combination of vanilla js + checkjs enabled

I have this settings on in my vscode that pretty much turns any js project into a ts project without the need for the weird syntax and wasting time to compile - that way i can always be up to speed with latest javascript features

    "javascript.suggest.completeFunctionCalls": true,
    "javascript.suggest.completeJSDocs": true,
    "javascript.suggest.autoImports": true,
    "js/ts.implicitProjectConfig.checkJs": true,

[Borewit]

npmgraph.js.org provided the nice dependency chart. Did some post processing to keep the relevant packages. (I should have cut out the content-type as well, not important in this context).

I am using IntelliJ myself, as I am doing Java development as well. Can probably do the same.

I have pretty much all my projects written in TypeScript, at the time a class declaration was not understood by some browser, that kind of enabled me to write JavaScript coming from C# & Java. Maybe you are right and it served its purpose by now.

Your help is very much appreciated @jimmywarting.

One of the dependencies which should not be there is readable-web-to-node-stream, introduced by file-type. It is only required in the browser.