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

121–130 of 520 posts

Re: WASM 3.0 Completed

#121

Post by dcchambers »

flohofwoe wrote: post #112
dcchambers wrote: post #103

Earlier quoted context omitted.

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 pr…

Fair enough, thanks for sharing!

Re: WASM 3.0 Completed

#122

Post by jschoe »

flohofwoe wrote: post #85
dcchambers wrote: post #81

Earlier quoted context omitted.

> Direct DOM access doesn't make any sense as a WASM feature. I disagree. The idea of doing DOM manipulation in a language that is not Javascript was *the main reason* I was ever excited about WASM.

> 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.

You don't get it.

Re: WASM 3.0 Completed

#123

Post by alabhyajindal »

The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating.

Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well designed instruction set. Maybe this is a criticism of Binaryen and its poor documentation because I liked writing short snippets of Wasm text very much.

1. https://git.sr.ht/~alabhyajindal/jasmine

Re: WASM 3.0 Completed

#124

Post by leptons »

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?

> without performance concerns?

WASM isn't going to magically make the DOM go faster. DOM will still be just as slow as it is with Javascript driving it.

WASM is great for heavy-lifting, like implementing FFMPEG in the browser. DOM is still going to be something people (questionably) complain about even if WASM had direct access to it. And WASM isn't only used in the browser, it's also running back-end workloads too where there is no DOM, so a lot of use cases for WASM are already not using DOM at all.

Re: WASM 3.0 Completed

#125

Post by baq »

jsheard wrote: post #104
renehsz wrote: post #97

Earlier quoted context omitted.

Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time). But if you really need more than 4GB of memory, then sure, go ahead and use it.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

didn't we call it 'segmented memory' back in DOS days...?

Re: WASM 3.0 Completed

#126

Post by davexunit »

leoc wrote: post #7
steveklabnik wrote: post #3

This looks like a great release! Lots of stuff people have wanted for a long time in here.

Tail calls. Tail calls!

The tail call instructions (return_call and friends) were crucial for compiling Scheme. Safari had a bug in their validator for these instructions but the fix shipped in their most recent release so now you can use Wasm tail calls to their fullest in all major browsers.

Re: WASM 3.0 Completed

#127

Post by k9294 »

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 ;)

Oh wow, that really is terrible naming... I always thought WASM was a specification for compiling code into something that runs natively in web browsers—like a web-specific compilation target.. Today I learned.

Re: WASM 3.0 Completed

#129

Post by sestep »

alabhyajindal wrote: post #123

The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating. Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well design…

For what it's worth, I also tried Binaryen from TypeScript and similarly found it frustrating. I switched to using wasm-tools from Rust instead, and have found that to be a vastly better experience.

Re: WASM 3.0 Completed

#130

Post by quix0t3 »

Jtsummers wrote: post #90
quix0t3 wrote: post #71

steve job's ghost will prevent wasm adoption.

> steve job's ghost will prevent wasm adoption. https://webassembly.org/features/ That isn't updated for Safari 26, but by that table Safari 18 is only missing 3 standardized features that Chrome supports, with a fourth that is disabled by default. So what's the point of your comment? Just to make noise and express your ignorance?

Historically speaking, apple has consistently limited web app functionality on iOS since 2008. I think we would be much further ahead if it wasn't for Apple’s policies under his leadership.

Apple took over the distribution to prioritize a cut to the app store which crippled/slowed the open web PWA and WASM adoption.

Post reply on HN