Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

111–120 of 520 posts

Re: WASM 3.0 Completed

#111

Post by discreteevent »

TUSF wrote: post #45
john01dav wrote: post #29

Earlier quoted context omitted.

I thought that the purpose of GC in WASM was to allow such higher level languages to be placed there without a bulky runtime also in WASM. What's the value proposition of WASM GC if not this?

As I understand it, WASM GC provides a number of low level primitives that are managed by the WASM host runtime, which would theoretically allow languages like Go or Python to slim down how much of their own language runtime needs to be packaged into the WASM module. But how those languages still need to carry around some runtime of their own, and I don't think it's obvious how much a given language will benefit.

>But how those languages still need to carry around some runtime of their own

Also just there will be a special version of those language runtimes which probably won't be supported in 10 years time. Just like a lot of languages no longer have up to date versions that can run on the common language runtime.

Re: WASM 3.0 Completed

#112

Post by flohofwoe »

dcchambers wrote: post #103
flohofwoe wrote: post #85

Earlier quoted context omitted.

> The idea of doing DOM manipulation in a language that is not Javascript ...is already possible, see for instance: https://rustwasm.github.io/docs/wasm-bindgen/examples/dom.ht... You don't need to write Javascript to access the DOM. Such bindings still call JS under the hood of course to access the DOM API, but that's an implementation detail which isn't really important for the library user.

While technically possible - the calls to javascript slow things down and you're never going to get the performance of just writing javascript in the first place, much less the performance of skipping javascript altogether.

The calls to JS are quite cheap, when trusting the diagrams in here it's about 10 clock cycles on a 2 GHz CPU per call (e.g. 200 million calls per second):

https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

The only thing that might be expensive is translating string data from the language-specific string representation on the WASM heap into the JS string objects expected by the DOM API. But this same problem would need to be solved in a language-portable way for any native WASM-DOM-API, because WASM has no concept of a 'string' and languages have different opinions about what a string looks like in memory.

But even then, the DOM is an inherently slow API starting with the string-heavy API design, the bit of overhead in the JS shim won't suddenly turn the DOM into a lightweight and fast rendering system.

E.g. it's a bit absurd to talk about performance and the DOM in the same sentence IMHO ;)

Re: WASM 3.0 Completed

#113

Post by ricardobeat »

cosmic_cheese wrote: post #101
flohofwoe wrote: post #63

Earlier quoted context omitted.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

Isn’t the whole reason why people want DOM access is so that the JavaScript side doesn’t have any meat to it and they can write their entire web app in Rust/Go/Swift/etc compiled to webasm without performance concerns?

Spoiler: there will be performance concerns.

The bottleneck is in the DOM operations themselves, not javascript. This is the reason virtual-dom approaches exist: it is faster to operate on an intermediate representation in JS than the DOM itself, where even reading an attribute might be costly.

Re: WASM 3.0 Completed

#114

Post by nostrademons »

cjs_ac wrote: post #84
flohofwoe wrote: post #63

Earlier quoted context omitted.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

WASM is an abbreviation for WebAssembly . If it doesn't have DOM access, WebAssembly is as related to the Web as JavaScript is to Java. A language ecosystem with no I/O capability is as much use as a one-legged man at an arse-kicking party.

Like C, which offloads IO to the standard library?

Re: WASM 3.0 Completed

#115

Post by cjs_ac »

flohofwoe wrote: post #95
cjs_ac wrote: post #84

Earlier quoted context omitted.

WASM is an abbreviation for WebAssembly . If it doesn't have DOM access, WebAssembly is as related to the Web as JavaScript is to Java. A language ecosystem with no I/O capability is as much use as a one-legged man at an arse-kicking party.

Well, arguably the worst thing about WASM is the naming. It's neither directly related to the web, nor is it an assembly syntax. It's just another virtual ISA. "Direct DOM access for WASM" makes about as much sense as "direct C++ stdlib access for the x86 instruction set" - none ;)

If you want to compare the situation to x86, direct DOM access for WebAssembly is more akin to the BIOS than C++ stdlib access. If it can't interact with the outside world, it's just a very special toy that you can only use to play a game that isn't any fun, and a good candidate for those 'What's the next COBOL?' discussions that come up every now and then.

Re: WASM 3.0 Completed

#116

Post by davexunit »

hinkley wrote: post #35

Still no mention of DOM. See you all for WASM 4.0.

Wasm doesn't specify any I/O facilities at all. DOM is no different. There's a strict host/guest boundary and anything interacting with the outside world enters Wasm through an import granted by the host. On the web, the host is the JS runtime.

Re: WASM 3.0 Completed

#117

Post by whizzter »

jasonthorsness wrote: post #54

I don't think the GC in this version has the features required to enable a C# runtime on top of it yet: https://github.com/WebAssembly/gc/issues/77 I wonder what language this GC can actually be used for at this stage?

I'm not familiar with all the implementation details of objects in C#, but the list of issues mixes runtime implementation details (object layouts) that should be fairly low effort to work around with actual language/runtime features (references, finalization).

In general though most regular C# code written today _doesn't directly_ use many of the features mentioned apart from references. Libraries and bindings however do so a lot since f.ex. p/invoke isn't half as braindead as JNI was, but targeting the web should really not bring along all these libraries anyhow.

So, making a MSIL runtime that handles most common C# code would map pretty much 1-1 with Wasm-GC, some features like ref's might need some extra shims to emulate behaviour (or compiler specializations to avoid too bad performance penalties by extra object creation).

Regardless of what penalties,etc goes in, the generated code should be able to be far smaller and far less costly compared to the situation today since they won't have to ship both their own GC and implement everything around that.

Re: WASM 3.0 Completed

#118

Post by titzer »

flohofwoe wrote: post #95
cjs_ac wrote: post #84

Earlier quoted context omitted.

WASM is an abbreviation for WebAssembly . If it doesn't have DOM access, WebAssembly is as related to the Web as JavaScript is to Java. A language ecosystem with no I/O capability is as much use as a one-legged man at an arse-kicking party.

Well, arguably the worst thing about WASM is the naming. It's neither directly related to the web, nor is it an assembly syntax. It's just another virtual ISA. "Direct DOM access for WASM" makes about as much sense as "direct C++ stdlib access for the x86 instruction set" - none ;)

In German, often things are named for where they came from, like Berliner or Frankfurter. WebAssembly came from the web, so makes sense :)

Re: WASM 3.0 Completed

#120

Post by cjs_ac »

nostrademons wrote: post #114
cjs_ac wrote: post #84

Earlier quoted context omitted.

WASM is an abbreviation for WebAssembly . If it doesn't have DOM access, WebAssembly is as related to the Web as JavaScript is to Java. A language ecosystem with no I/O capability is as much use as a one-legged man at an arse-kicking party.

Like C, which offloads IO to the standard library?

It's still there - you can still do I/O in C, even if you have to call a library function. In WebAssembly, there's no mechanism for I/O of any sort.
Post reply on HN