You'll have to excuse HN Guy that assumes that every project on GitHub is done to try and take over the world and not because, you know, learning is fun. So keep on doing weird things with your weird and awesome language.
I may be in the minority then: one of the big advantages, for me, of WASM is that I can use not-Javascript in the browser. Some of the issues I have with JS are an artifact of being one of the first things to run in the browser (e.g. atrocious standard library) and some are just baked in poor designs (e.g. implicit type casting, == vs ===).
Oh gosh, let's not forget what happens when you try to use map and parseInt together.
Sure, but you're putting a workaround in – there really shouldn't be any need for that no-op arrow function. But you do actually need it in order to drop all but the first arguments.
This doesn't work because map() stuffs a counter into the second argument of parseInt(), which is expecting a radix for its second argument. So the iterations of the map go like this:
…and so on, which obviously gives garbage results. JavaScript is littered with these kinds of weird edge cases. Even your example with the workaround isn't 100% reliable, it's browser-dependent – when you have leading zeros in your strings, some browsers will interpret them as octal, and some won't.
Language version dependent rather than browser dependent.
It may seem the same (after all, different browsers implement different versions of the language), but it's a bit different, if you say 'browser-dependent' it makes it sound like there is no standard when in fact, the leading zero behaviour hasn't been the case since ecmascript 5. You'll struggle to find a browser in common use that doesn't support at least ecmascript 5. It's as browser-dependent as the array.map function which was added at the same time.
Your example code would never have the leading 0 problem since you're using array.map and array.map didn't exist in the engines that had that leading 0 'feature'.