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

281–290 of 520 posts

Re: WASM 3.0 Completed

#281

Post by stevefan1999 »

jesse__ wrote: post #242
apatheticonion wrote: post #209

Earlier quoted context omitted.

Agreed. This and (sane) access to multi-threading. I want to be able to write a Rust application, compile to wasm and load it with Would be great for high performance web applications and for contexts like browser extensions where the memory usage and performance drain is real when multiplied over n open tabs. I'm not sure how code splitting would work in the wasm world, however. v8 could be optimized to reduce its m…

Not sure what the Rust situation is like, but last I checked (and compiled a non-trivial personal application) WASM supported the pthreads API and it seemed to work reasonably well. Have you encountered stumbling points porting a heavily MT Rust program to WASM?

That's supposedly WASI, an interface specifically designated for system programming use, and that's where it implements part of the POSIX support including pthread.

OTOH you still need to start a wasm runtime first, then import the WASI module into the wasm host.

P.S.: used to tinker with wasmtime and wasmi to add wasm support to my half abandoned deno clone ;) I learned this the hard way

Re: WASM 3.0 Completed

#282

Post by em-bee »

catlifeonmars wrote: post #273
em-bee wrote: post #252

Earlier quoted context omitted.

getting rid of javascript entirely means to be able to manipulate the DOM without writing any javascript code. not to remove javascript from the browser. javascript will still be there if you want to use it.

Most of the time your toolchain provides a shim so you don’t need to write JS anyway. What’s the difference?

right, that's exactly the point. those that have a shim already successfully got rid of javascript, and that's enough.

Re: WASM 3.0 Completed

#283

Post by spartanatreyu »

austin-cheney wrote: post #216
cedws wrote: post #192

Earlier quoted context omitted.

But then you need two things instead of one. It should be made possible to build WASM-only SPAs. The north star of browser developers should be to deprecate JS runtimes the same way they did Flash.

That is never going to happen until you create your own browser with a fork of the WASM spec. People have been asking for this for about a decade. The WASM team knows this but WASM wants to focus on its mission of being a universal compile target without distraction of the completely unrelated mission of being a JavaScript replacement.

It's also too early to worry about DOM apis over wasm instead of js.

The whole problem with the DOM is that it has too many methods which can't be phased out without losing backwards compatibility.

A new DOM wasm api would be better off starting with a reduced API of only the good data and operations.

The problem is that the DOM is still improving (even today), it's not stabilized so we don't have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two.

New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications:

- being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition.

- the improved attr() api which can move a lot of an app's complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time.

And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications.

Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn't we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures.

TL;DR: It's still too early to work on a DOM api for wasm. It's better to wait for the DOM to stabalize first.

Re: WASM 3.0 Completed

#284

Post by jjcm »

gertop wrote: post #210
jjcm wrote: post #176

Earlier quoted context omitted.

I know you're in this for the satire, but it's less about the webapps needing the memory and more about the content - that's why I mentioned video editing webapps. For video editing, 4GiB of completely uncompressed 1080p video in memory is only 86 frames, or about 3-4 seconds of video. You can certainly optimize this, and it's rare to handle fully uncompressed video, but there are situations where you do need to buff…

> 4GiB of completely uncompressed 1080p video in memory is only 86 frames How is that data stored? Because (2^32)÷(1920×1080×4) = 518 which is still low but not 86 so I'm curious what I'm missing?

> How is that data stored?

So glad you asked. It's stored poorly because I'm bad at maths and I'm mixing up bits and bytes.

That's what I get for posting on HN while in a meeting.

Re: WASM 3.0 Completed

#285

Post by nirui »

> 64-bit address space. Memories and tables can now be declared to use i64 as their address type instead of just i32.

Could be nitpicking but in the PDF (https://webassembly.github.io/spec/core/_download/WebAssembl...), there's a passage that says:

> 32-bit integers also serve as Booleans and as memory addresses. (under 1.2.1 Concepts)

While 64-bit is not mentioned. Could it be an oversight or I understood it wrong?

Re: WASM 3.0 Completed

#286

Post by mycall »

cogman10 wrote: post #212
zekrioca wrote: post #201

Earlier quoted context omitted.

Could you list some of these downsides and what are the reason of their existence?

For starters, the DOM API is huge and expansive. Simply giving WASM the DOM means you are greatly expanding what the sandbox can do. That means lower friction when writing WASM with much much higher security risks. But further, WASM is more than just a browser thing at this point. You might be running in an environment that has no DOM to speak of (think nodejs). Having this bolted on extension simply for ease of use…

> you probably don't want to actually expose the DOM, you want to expose the framework functions.

Aren't the framework functions closely related to the DOM properties and functions?

Re: WASM 3.0 Completed

#287

Post by pveierland »

The SpecTec mentioned in the announcement is really cool. They're using a single source of truth to derive LaTeX, Sphinx docs, Coq definitions for proofs, and an AST schema. Building the language spec in a way that its soundness can be proven and everything derived from one truth in this way seems super useful.

https://webassembly.org/news/2025-03-27-spectec/

Re: WASM 3.0 Completed

#288

Post by thrance »

DarkNova6 wrote: post #184
cedws wrote: post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

I am watching patiently from a distance to my hands on a well-designed frontend language but can't help to wonder... is it really _that_ inefficient to call a JS wrapper to touch the DOM? Most code already is so horribly inefficient that I can't imagine this making a noticeable difference in most scenarios.

No, it's not that bad honestly. But it's not more efficient than JS either, and all this ugly glue code hurts my sensibility.

Re: WASM 3.0 Completed

#289

Post by azakai »

kannanvijayan wrote: post #268
azakai wrote: post #236

Earlier quoted context omitted.

The special part is the "signal handler trick" that is easy to use for 32-bit pointers. You reserve 4GB of memory - all that 32 bits can address - and mark everything above used memory as trapping. Then you can just do normal reads and writes, and the CPU hardware checks out of bounds. With 64-bit pointers, you can't really reserve all the possible space a pointer might refer to. So you end up doing manual bounds che…

Hi Alon! It's been a while. Can't bounds checks be avoided in the vast majority of cases? See my reply to nagisa above ( https://news.ycombinator.com/item?id=45283102 ). It feels like by using trailing unmapped barrier/guard regions, one should be able to elide almost all bounds checks that occur in the program with a bit of compiler cleverness, and convert them into trap handlers instead.

Hi!

Yeah, certainly compiler smarts can remove many bounds checks (in particular for small deltas, as you mention), hoist them, and so forth. Maybe even most of them in theory?

Still, there are common patterns like pointer-chasing in linked list traversal where you just keep getting an unknown i64 pointer, that you just need to bounds check...

Post reply on HN