Hacker News Reader

Comment by Eikon | Hacker News Reader

> Now that you know how you can easily create and use WebAssembly code, there is nothing stopping you from refactoring performance critical parts of your code using WASM.

There is, writing WASM by hand will not only create an unmanageable mess but also should be strongly discouraged, WASM is supposed to be a target not a “language” like the author is mentioning.

Also, it’s doubtful WASM is actually faster than plain JavaScript for most use cases when not speaking of benchmark-optimized tests. It’s not the point of WASM.

Unfortunately, the way I see it is the ASM part in WASM is going to create a disaster where people really believe it’s an analog to physical machine code.

Even speaking of proper assembly code, it’s not advisable to write it by hand except in very rare and specific scenarios such as cryptography as it’s most of the time going to be slower than using an optimizing compiler anyway.

View on HN

WASM was explicitly designed to be human readable and human editable. The WAT format wouldn't have been created if that wasn't the intention[0]. That's a lot of effort being invested into readability, and it would have been a lot simpler to just create the binary format and not worry about syntax or WAT compilers if humans weren't meant to be able to read and debug the final product.

Of course I wouldn't write web assembly by hand normally for most projects, but I also wouldn't create a blanket rule that it should be discouraged across the board. It's another language that goes through a compile process, just a very specialized one, like assembly.

[0]: https://webassembly.github.io/spec/core/text/index.html

I thought that one of the major points of WASM was that it would be fast? The first advantage listed on the official WebAssembly website is "Efficient and fast" [0]. But I suppose you wrote "the point" - it's just one of several points. But ideally, it should run at "native speed", right?

[0] https://webassembly.org/

It is designed to be able to skip the "tier up JIT" stage that JS code has to go through, where JS code is profiled at runtime to decide what should be optimized, what the types are, etc. `1 + 1` in JS and `(i32.add (i32.const 1) (i32.const 1))` should still result in the same cpu code, the only difference is that it takes longer for the JS code to get there (and there's no guarantee that it happens to the JS code).

(and yes I know, the addition would be constant folded, it's just an example okay)

In Firefox, Wasm still uses a tiered JIT. Like JS, there is a single-pass JIT and a JIT that does more aggressive optimizations (mostly: good regalloc).

However the compilers are much simpler than the equivalent JS compilers, because wasm doesn't need on-stack-invalidation.

It sounds more useful to just ship less JavaScript code if your problem is taking too much time script parsing, etc. Especially given how bundle sizes have grown in the past few years.

Never mind that this example parses and compiles the wasm code at runtime, so it's probably not faster at all to takes chunks of JS and port it to wasm if you're going to run it this way.

Though it might be useful in niche situations. In the C world, crypto libraries often use inline assembler. I assume there might be similar use cases for JS and WASM.

Not really applicable here as WASM is not machine code and is interpreted / compiled / JIT compiled behind the scenes. Something you definitely don’t want for cryptography.

I wasn't directly suggesting cryptography. Rather pointing to a similar "niche" use case of inlining in a different ecosystem.

I assume there are several use cases where WASM is faster than JavaScript, despite all the things you mention. Some types of canvas manipulation are typically faster with WASM, for example.

Reply on news.ycombinator.com