Is it worth having hash implementations?
riperk opened this issue · comments
Not really a bug-report, but just some food-for-thought if you weren't aware (and my apologies if you were).
One thing I've had a lot of success with is writing a sha256 hash like this:
as well as provide a node.js version with the same signature:
and then in the package.json tell it to switch files depending if it's included in the browser or not:
It's also worth noting there's no browser crypto for ripemd, so that's another annoyance.
Thanks for opening an issue! This is a great question – and your solution is definitely the best option for a lot of projects. (Related, this is something I've changed my mind on a lot over time.)
Ultimately, the reason this project provides WASM implementations of those methods is to allow for complete portability (see the Design Goals):
3. portable – All code should work on every platform (no Node.js bindings or separate browser versions)
By writing code in a completely portable way, we ensure all of our code is maximally reliable – if different platforms run different code paths, bugs may be present in one path but not the other. By using the exact same code across platforms, we also reduce downstream build configuration complexity: e.g. these WASM methods can easily work in a new Deno project without modification.
You can see some other interesting stats in the blog post I wrote about these WASM hashing functions. Here's the most interesting part to me:
The WebAssembly implementations are up to 4x faster than the built-in Node.js implementations (especially for smaller inputs), and easily outperform the pure JavaScript implementation (between 2x and 20x, depending on the use case).
WebAssembly is also remarkably consistent — while other implementations rise and fall in the rankings based on workload, the WebAssembly implementations perform fairly consistently in all cases.
Thanks for the issue! I'm going to close it for now, but please feel free to continue discussing below.