←back to thread

160 points todsacerdoti | 3 comments | | HN request time: 0.727s | source
1. metadat ◴[] No.41899074[source]
> I should also acknowledge: there is a perf hit from using Wasm versus pure-native tools. So this could be another reason native tools are taking the CLI world by storm, but not necessarily the browser frontend.

I didn't know about this before, I wonder how much overhead?

The reason I am reluctant to rely on JS tools for anything CLI is because of Node.js instability due to version sensitivity and impossible-to-fix-without-reinstalling-the-os low level LibC errors.

Compared to go, rust, or python, the odds that any given CLI.js program will run across my (small) fleet of machines is very low, by factor or 10x or more compared to alternatives. Some boxes I don't want to reinstall from scratch every 4 years, they're not public facing and life is too short.

replies(2): >>41901638 #>>41902691 #
2. lenkite ◴[] No.41901638[source]
Deno is fixing this with their standard library and JSR.
3. csomar ◴[] No.41902691[source]
wasm itself is a bit slower than code compiled for a particular CPU. However, there is significant overhead when it comes to the browser. This is because, now, wasm has to use JavaScript to talk to the browser. The performance gain/loss will depend on the type of operations you are doing. There are plans, however, for wasm to have direct access.