not fast nor small

Nobody has claimed this yet.

Hey, stumbled upon this when I was looking for some docs/middleware that handles POST-payloads for polka.

Bro.. ur code.. it's.. I'm sorry :man_facepalming: a waste of string-ops and entropy...

If you want to minimize LOC have a oneliner:
```js
export const hexoid = len => Array.from(new Array(len)).map(() => ((Math.random() * 0xff) | 0).toString(16)).join('')
```

If you want to target computational efficiency
Then don't throw away all the decimals it's, fresh entropy,
here's a variant that sweeps 8 letters (4bytes) per iteration,
it should be at least 8x faster.

```js
export function hexoid (n = 16) {
let s = ''
for (;n>0; n-=8) s += ((0xffffffff * Math.random()) >>> 0).toString(16), s.length % 2 && (s+='0')
return s.substr(0, s.length + n)
}
```

- The LUT looks fun, not sure it's faster than `toString(16)`
- `Math.random()` is collision-wise a horrible source of random..`randomBytes(8).toString('hex')` works nicer
- Avoiding dynamic allocation speeds things up, when final size is known ahead of time, define your output array/string with set size and use it as working memory.

Thank you this was fun :pray: can you point me in the right direction for parsing payload-data? I wanna go home :cry:

The issue does not name a source file, test, or benchmark. Read the repository's current hexoid implementation first, then determine whether the requested change is size or computational efficiency; done should preserve the utility's output behavior while demonstrating the chosen improvement.

Written by the indexing model from the issue text.