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

141–150 of 520 posts

Re: WASM 3.0 Completed

#141

Post by gspr »

flohofwoe wrote: post #132
gspr wrote: post #100

Earlier quoted context omitted.

> If you need to manipulate the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. From the point of view of someone who doesn't do web development at all, and to whom JS seems entirely cryptic: This argument is weird. Why is this specific (seemingly extremely useful!) "web thing" guarded by a specific language? Why would something with the generality and wide scope of WASM…

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?

Re: WASM 3.0 Completed

#142

Post by mistahchris »

I'm still hype about WASM. This looks like a cool release. I'm running some pretty high traffic WASM plugins on envoy, running some plugins for terminal apps (zellij), and for one of my toy side projects, I'm running a wasm web app (rust leptos).

For 2 of those 3 use cases, i think it's not technically the optimal choice, but i think that future may actually come. Congratulations and nice work to everyone involved!

Re: WASM 3.0 Completed

#143

Post by Jtsummers »

zb3 wrote: post #137
Jtsummers wrote: post #90

Earlier quoted context omitted.

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

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

Re: WASM 3.0 Completed

#144

Post by flohofwoe »

jschoe wrote: post #122
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.

You don't get it.

Don't get what, exactly?

Re: WASM 3.0 Completed

#145

Post by 3836293648 »

cjs_ac wrote: post #120
nostrademons wrote: post #114

Earlier quoted context omitted.

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.

But that's not the (original) argument being made. Just as IO belongs in POSIX and not C, DOM access belongs in some other standard, not WASM

Re: WASM 3.0 Completed

#146

Post by [deleted] »

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.

[deleted]

Re: WASM 3.0 Completed

#147

Post by sestep »

alabhyajindal wrote: post #135
sestep wrote: post #129

Earlier quoted context omitted.

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.

Isn't wasm-tools for working with Wasm modules? Maybe I'm missing something. I was using Binaryen to compile an AST to WebAssembly text. Also worth mentioning that Binaryen is the official compiler/toolchain for this purpose which is why I expected more from it.

Currently you use Binaryen to build up a representation of a Wasm module, then call emitText to generate a .wat file from that. With wasm-tools you'd do the same thing via the wasm-encoder crate to generate the bytes corresponding to a .wasm file, and then use the wasmprinter crate to convert from the .wasm format to the .wat format. Alternatively, I believe the walrus crate gives you a somewhat higher-level API to do the same thing, but I haven't used it because it's much heavier-weight.

Re: WASM 3.0 Completed

#148

Post by tjoff »

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.

Re: WASM 3.0 Completed

#149

Post by cookiengineer »

cjs_ac wrote: post #120
nostrademons wrote: post #114

Earlier quoted context omitted.

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.

There is, it is just called WASI and it specifies syscalls in a different way.

WebASM is an assembly-like dialect, after all.

Post reply on HN