Comment by jholman | Hacker News Reader

Comment by jholman | Hacker News Reader

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway...

I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS interop lowers the cost of the obvious workaround. And yes, there's discussion in the article of getting WASM to play nice with JS GC, which I understand is a prerequisite. But there should be explicit discussion of what the predicted path is for making WebAPIs available in WASM, what the sub-goals are, and how to measure progress.

And the first paragraph of the article is a joke, claiming that people thought the 2017 version was the final version. No, we're waiting for a relevant version (this sentence is an exaggeration, but it's more true than what TFA said).

It seems to be tracked under/after GC, since that would be a prerequisite.

See https://github.com/WebAssembly/gc/blob/master/proposals/gc/O.... Things like DOM access are specifically mentioned.

You can access web APIs and access DOM in wasm today (from your comment you seem to be unware of that?). I just wrote a tiny web app in Rust with wasm-bindgen, and it’s pretty good already. With wasm-bindgen interfacing is pretty manual at the moment — you need to declare the APIs you need in Rust by hand, but an app without dependencies that modify the DOM generates a wasm file that’s only a few KB. My app pulls in quite a few libs and ended up with a ~700KB wasm build — a bit larger than satisfactory, but definitely in the tolerable range.

I know wasm-bindgen exists, and I presume it works. But it's black magic.

Near as I can tell, it serializes everything through the linear memory; this would have a huge impact on the performance of both ends, would it not? (Particularly if you wanted to do DOM manip w/ it.) I believe this is what the article means here,

> You need to pass values into the WebAssembly function or return a value from it. This can also be slow, and it can be difficult too.

> There are a couple of reasons it’s hard. One is because, at the moment, WebAssembly only understands numbers. This means that you can’t pass more complex values, like objects, in as parameters. You need to convert that object into numbers and put it in the linear memory. Then you pass WebAssembly the location in the linear memory.

I only spent about an hour on the rust + wasm app for fun, so I treated wasm-bindgen and wasm-pack as black boxes and didn't really try to understand the inner workings. You're probably right about serialization, but I'm not sure it has to copy huge buffers around.

Look, the supported types in wasm-bindgen are somewhat restricted. The full list is here [1]. Other than "atomic" types like numbers and pointers (I assume the opaque types are treated as pointers too), the interesting one are str/String (basically &[u8] under the hood) and number slices. It's apparently not great if you have to copy these around, but since these are well-aligned, why can't you just pass the starting address and length? Again, I don't know enough about wasm or its current state to say if this is doable. Maybe it doesn't like "someone else's memory" at the moment.

(By the way, wasm-bindgen allows you to access pub fields of structs from JS, but they have to be Copy. That is to say, the opaque types are not completely opaque, but I'm not sure if the pub field access is achieved through implicit getter methods or serialized in the first place.)

Anyway, the frictions might be a big problem if you're doing React-style DOM re-renders all the time, but in my app, I'm only running the computation heavy and memory sensitive tasks in wasm, and communications are few and far between, making it a non-issue.

[1] https://rustwasm.github.io/wasm-bindgen/reference/types.html

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)?

0 - https://github.com/WebAssembly/host-bindings/blob/master/pro...

Performance

One might expect that never leaving the WASM context and interoperating with browser APIs, even if defined in JS terms, would not incur JS penalties. Granted it may affect JS argument validation. But this requires representation of those types. For example, if the DOM API allows searching for a selector which is a string, how do you build that string in WASM and how do you pass it? You'd use host refs anyways I would guess, essentially creating a new host "string" which is meaningfully equivalent to creating a JS string.

I’d assume you would get a performance (and therefore battery) benefit by not maintaining a js layer, though a js layer is a perfectly acceptable temporary solution.

Careful. Javascript was a perfectly acceptable temporary solution too. Temporary solutions have a way of becoming permanent.

The difference is being able to serve some WASM script that interacts with your page without having to send and entire glibc equivalent.

In practice, that means having an standard library on browsers that you can call in a standard idiom.

Dead code elimination in your compiler should be taking care of this, no?

It would kind of be like defining a set of syscalls that anything targeting WASM could use. Right now, JS interop is sorta like being given a DLL that requires an entire JS runtime to support it, whereas direct Web-API interop would mean there is no JS runtime requirement IIRC.

(Hoisting to top level from a comment farther down.)

The section "Small modules interoperating with JavaScript", talks about general access to JavaScript code. Web APIs are a subset of that usecase.

Native support for WebAPIs is blocked on garbage collection - WASM code will need to claim a reference to garbage-collected DOM/JS objects, and will need to be able to hand off GCed objects and callbacks to JS APIs.

Yes, we know that, and I even said that in my comment, which I'm sure you read.

But many things that were discussed in TFA are blocked on other things that were discussed, and yet still got hundreds of words of article space.

GC is listed under a section "Small modules interoperating with JavaScript", which talks about general access to JavaScript code. Web APIs are a subset of that usecase.

Reply on news.ycombinator.com