31–40 of 71 posts
Earlier quoted context omitted.
WebAssembly can be used anywhere. It is not tied to JavaScript in nature. So think of it kind of like the JVM in a way (but it's not an implementation, just a spec).
So people are using wasm in a non web context ?
I’m looking forward to the results of this work!
Earlier quoted context omitted.
>non-JS WASM backend ...what's a non-js wasm backend?
WebAssembly can be used anywhere. It is not tied to JavaScript in nature. So think of it kind of like the JVM in a way (but it's not an implementation, just a spec).
So when they say, it generates a big switch statement, do they generate this big switch statement for whole program or for individual functions which takes enough context to continue at at point where it yielded?
> Go’s garbage collection is fully supported. WebAssembly is planning to add its own garbage collection, but it is hard to imagine that it would yield a better performance than Go’s own GC which is specifically tailored to Go’s needs I don't think it's hard to imagine reading the GC proposal. The JS collector that might be reused could be off thread, something WASM can't (yet) do. > Most file system operations are ma…
> WASM has fairly strict stack/frame rules/types, so arbitrary gotos wouldn't work. kinda funny because golang follows the same idea.
Earlier quoted context omitted.
WebAssembly can be used anywhere. It is not tied to JavaScript in nature. So think of it kind of like the JVM in a way (but it's not an implementation, just a spec).
So people are using wasm in a non web context ?
Earlier quoted context omitted.
WebAssembly can be used anywhere. It is not tied to JavaScript in nature. So think of it kind of like the JVM in a way (but it's not an implementation, just a spec).
but i'm asking what are some webasm languages/backends/use cases that aren't a JS interpreter?
Earlier quoted context omitted.
Yes. Not a ton of people (yet), but yes, some are.
but why, if you have plenty of good languages to do this? Wasm is good for browsers because only choice we have is js.
The main benefit of using the Web Assembly GC is not improved performance within the language, but rather having a single GC that handles both native DOM objects and language objects. Having two GCs interoperate is a big pain, and it's very difficult to pull off without leaks or performance problems. This is especially true for DOM objects, which have no user-visible finalizers. (The closest thing is WeakMaps, but I…
In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.