Hacker News Reader

Comment by tormeh | Hacker News Reader

A big issue is that it doesn’t currently replace the old webtech, but instead just adds to it. You can’t use WASM in the browser without also using JS, which is unfortunate.

View on HN

That's the direction they're actively working towards. Unfortunately you can't expect to design a big novel piece of web tech and every intended interface point correctly in a way that a cohort of unrelated browser vendors will implement before the very first release.

If that is what they want then they should scrap WASM and start over. The design is just fundamentally wrong for a JavaScript replacement.

... based on what do you say that?

The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling.

I'm not saying that it is impossible, but you would end up pretty much building a new language with all the required features, sitting next to the useless array-based thing.

The ability to support GC'able DOM references in browsers through integration with the host-side GC is absolutely being worked on, it just took several years to stabilize because it's a tricky feature. It will also allow GC'd languages to target standalone runtimes more easily. The developers just didn't want to block the early 1.0 spec, early toolchain and software support, etc. all on that. It was just easier to ship the C/C++ style memory management model because a lot of existing code could immediately be reused and it was easier to implement. But it was always planned from a very early phase to have GC integration, at minimum, since web usage was always a big priority.

The string story is a bit unfortunate (how to handle conversions between modules in different languages). Until the component model is fully fleshed out I don't think there's a clear answer here besides things like bindgen-style interfaces, but I agree it's a sore spot.

I don't know what a rewrite of the spec would achieve at this point since most of these things would be impossible to get right on the first try, I suspect, and the current one is actually pretty good for the cases it does support.

If you do a rewrite you can throw away the memory buffer and handle all data with opaque pointers, thus allowing complete integration with the GC.

And yes, you could just leave the buffer dangling there, and tell people not to use it, but it doesn't ease any part of the task of designing the new thing.

Yeah, but it is kind of hard to do right and they are working towards it.

How would starting from scratch solve that?

It wouldn't solve the issue, but it would remove all the things in the way of one competent person sitting down and writing a spec.

Writing a spec and implementing a spec are 2 different things. But they are connected. A spec can sound good in theory, but can turn out to be allmost impossible to implement. Do you think, you could write a better spec for wasm2, that browser vendors can realistically implement? Well, they are open for participation.

> The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling.

WASM spec authors and implementors seem to agree that this all can be naturally handled by providing direct bindings to regular web APIs in WASM.

I would tend to agree... Those don't exactly seem core to the design of the runtime?

The DOM is garbage collected, you cannot hold a reference to a DOM element in a non-garbage-collected environment without having to manually mark as held and free.

Remember that some old IEs had memory leaks because one could make circular references through the DOM and JavaScript, and they each had separate garbage collectors. Well working garbage collection is not an afterthought, and you can't get two distinct garbage systems to work together in the seamless manner that a single system can operate.

I have honestly no idea what you're saying isn't possible.

I've been writing a bunch of Rust code running in browsers, for work and play. I'm not futzing with the details, I just use wasm-bindgen and web-sys.

I've honestly never worried about garbage collection before, one of the professional hazards of working with a well-designed Rust API. I guess that web-sys provides types with a Drop impl that tell the browser side the object is dead.

> without having to manually mark as held and free.

I guess that's what you're worried about? It's never been a concern of mine. Maybe if one were writing WASM by hand?

Reply on news.ycombinator.com