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

161–170 of 520 posts

Re: WASM 3.0 Completed

#161

Post by flohofwoe »

gspr wrote: post #141
flohofwoe wrote: post #132

Earlier quoted context omitted.

Think of it as traditional FFI (foreign function interface) situation. Many important libraries have been written in C and only come with a C API. To use those libraries in non-C languages (such as Java) you need a mechanism to call from Java into C APIs, and most non-C language have that feature (e.g. for Java this was called JNI but has now been replaced by this: https://docs.oracle.com/en/java/javase/21/core/forei…

Sure, but if someone came at the C-centric ecosystem today and said "let's do the work to make it so that any language can play in this world", then surely "just FFI through C" would be considered rather underwhelming?

Well that's what the WASM Component Model set out to solve, some sort of next-gen FFI standard that goes beyond C APIs:

https://component-model.bytecodealliance.org/

In my opinion it's an overengineered boondoggle, since "C APIs ought to be good enough for anything", but maybe something useful will eventually come out of it, so far it looks like it mostly replaces the idea of C-APIs as lingua-franca with "a random collection of Rust stdlib types" as lingua-france, which at least to me sounds utterly uninteresting.

Re: WASM 3.0 Completed

#162

Post by sjrd »

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…

Binaryen has a lot of baggage from Wasm early days, when it was still a strict AST. Many newer features are difficult to manipulate in its model.

In our compiler (featured in TFA), we chose to define our own data structure for an abstract representation of Wasm. We then wrote two emitters: one to .wasm (the default, for speed), and one to .wat (to debug our compiler when we get it wrong). It was pretty straightforward, so I think the instruction set is quite nice. [1]

[1] https://github.com/scala-js/scala-js/tree/main/linker/shared...

Re: WASM 3.0 Completed

#163

Post by Ductapemaster »

IshKebab wrote: post #96
phickey wrote: post #28

Earlier quoted context omitted.

https://github.com/WebAssembly/custom-page-sizes is a proposal championed by my colleague to add single byte granularity to Wasm page sizes, motivated by embedded systems and many other use cases where 64kb is excessive. It is implemented in wasmtime, and a Firefox implementation is in progress.

> Allow Wasm to better target resource-constrained embedded environments, including those with less than 64 KiB memory available. If it has less than 64 kB of memory how is it going to run a WASM runtime anyway? And even cheap microcontrollers tend to have more than 64 kB of memory these days. Doesn't not seem remotely worth the complexity.

It's not about the whole microcontroller having less than 64kB of memory - it's that each WASM module has a minimum memory size of 64kB, regardless of how much it actually requires. Also, if you need 65kB of memory, you now have to reserve 2 pages, meaning your app now needs 128kB of memory!

We're working on WASM for embedded over at atym.io if you're interested.

Re: WASM 3.0 Completed

#164

Post by [deleted] »

gspr wrote: post #141
flohofwoe wrote: post #132

Earlier quoted context omitted.

Think of it as traditional FFI (foreign function interface) situation. Many important libraries have been written in C and only come with a C API. To use those libraries in non-C languages (such as Java) you need a mechanism to call from Java into C APIs, and most non-C language have that feature (e.g. for Java this was called JNI but has now been replaced by this: https://docs.oracle.com/en/java/javase/21/core/forei…

Sure, but if someone came at the C-centric ecosystem today and said "let's do the work to make it so that any language can play in this world", then surely "just FFI through C" would be considered rather underwhelming?

[deleted]

Re: WASM 3.0 Completed

#166

Post by nicoburns »

catapart wrote: post #86
cdata wrote: post #61

Earlier quoted context omitted.

Don't sleep on the Rust toolchain for this! You can have DOM-via-Wasm today, the tools generate all the glue for you and the overhead isn't that bad, either.

Got a rec? The reply to you is talking about a component framework, rather than actual vanilla html/css access. I haven't seen anything, personally, that allows real-time, direct DOM interaction.

https://github.com/wasm-bindgen/wasm-bindgen is the tool for raw access to the DOM APIs.

Re: WASM 3.0 Completed

#167

Post by sjrd »

hinkley wrote: post #35

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

Wasm 3.0, with its GC and exception support, contains everything you need. The rest is up to the source language to deal with. For example, in Scala.js [1], which is mentioned in the article, you can use the full extent of JavaScript interop to call DOM methods right from inside your Scala code. The compiler does the rest, transparently bridging what needs to be.

[1] https://www.scala-js.org/doc/project/webassembly.html

Re: WASM 3.0 Completed

#168

Post by poly2it »

tjoff wrote: post #148
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

Webapps limited by 4GiB memory? Sounds about right. Guess 512 GiB menory is the minimum to read email nowadays.

It doesn't actually allocate 4 GiB. Memory can be mapped without being physically occupied.

Re: WASM 3.0 Completed

#169

Post by zb3 »

Jtsummers wrote: post #143
zb3 wrote: post #137

Earlier quoted context omitted.

What ignorance? Safari doesn't support the most important additions: - memory64 - multiple memories - JSPI (!!) I recently explored the possibility of optimizing qemu-wasm in browser[0].. and it turns out that the most important features were those Safari doesn't implement. [0] https://zb3.me/qemu-wasm-test/

Multiple memories and Memory64 just became part of the spec. And JSPI is still being standardized. Is Safari slower to roll out new things? Yes. But it's hardly stopping adoption. Chrome has 70% of the browser market, Safari barely has 15%.

But Apple doesn't allow using other browser engines on iOS, so this matters much more. I mean, they were forced to allow them, but of course they didn't actually comply, they created artificial barriers to ensure only Safari can be used on iOS.

EDIT: By "safari" here I actually mean WebKit.

Re: WASM 3.0 Completed

#170

Post by sjrd »

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…

If your language and its compiler use JS String Builtins (part of Wasm 3.0) for their strings, then there is no cost to give them to JS and the DOM.
Post reply on HN