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

371–380 of 520 posts

Re: WASM 3.0 Completed

#371

Post by pjmlp »

cesarb wrote: post #232
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…

> Plus ça change...

The difference is that now it is cool.

https://cheerpj.com/

Re: WASM 3.0 Completed

#372

Post by grishka »

sebstefan wrote: post #368

I've never used WASM so apologies in advance but for >Typed references. The GC extension is built upon a substantial extension to the Wasm type system, which now supports much richer forms of references. Reference types can now describe the exact shape of the referenced heap value, avoiding additional runtime checks that would otherwise be needed to ensure safety. Why is an assembly-like dialect interacting with conc…

IIRC initially this was proposed so the runtime (i.e. the browser) could expose its APIs directly to wasm code, without the need for JS wrappers.

Re: WASM 3.0 Completed

#373

Post by sapiogram »

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?

WASM does not support pthreads in the browser, only web workers, which are much more limited.

Re: WASM 3.0 Completed

#374

Post by pjmlp »

dfabulich wrote: post #342
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?

Basically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested in starting down that road. https://danfabulich.medium.com/webassembly-wont-get-direct-d... Killing JavaScript was never the point of WASM. WASM is for CPU-intensive pure functions, like video decoding. Some people wrongly thought that WASM was trying to kill…

People have to look at it, from the same point of view Google sees the NDK on Android.

"However, the NDK can be useful for cases in which you need to do one or more of the following:

- Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

- Reuse your own or other developers' C or C++ libraries."

And I would argue WebGL/WebGPU are preferably better suited, given how clunky WebAssembly tooling still is for most languages.

Re: WASM 3.0 Completed

#375

Post by pjmlp »

bborud wrote: post #65

I'm a simple man who has simple needs. I want a better and faster way to pass Go structs in and out of the runtime that doesn't mean I have to do a sword dance on a parquet floor wearing thick knit wool socks and use some fragile grafted on solution. If there can be a solution that works for more languages: great. I mostly want this for Go. If it means there will be some _reasonable_ limitations, that's also fine.

This is exactly why I say WebGL/WebGPU are much better for perfomance code on the browser than dealing with WebAssembly tooling.

Re: WASM 3.0 Completed

#376

Post by DarkNova6 »

thrance wrote: post #288
DarkNova6 wrote: post #184

Earlier quoted context omitted.

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.

Sounds like something that could be trivially turned into a library, no?

Re: WASM 3.0 Completed

#377

Post by torginus »

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?

Contrary to naysayers, I'm pretty sure this is very doable. Most browser JS objects map 1-1 to C++ native objects implemeneted in the browser.

As others have pointed out, the Js compoment interface is define in a language called WebIDL:

https://firefox-source-docs.mozilla.org/dom/webIdlBindings/i...

How it works in Chrome(Blink) is that a compiler generates a wrapper between V8, which is a V8 object that holds onto the native object reference using this IDL.

Once V8 cleans up the Js object, the native code, holding a weak reference to the native objects, detects that it has become unreachable and cleans that up.

In any ways, the object lifetime is encapsulated by the v8 Isolate (which is depending on how you look at it, the lifetime of the HTML document or the heap), so it'd be perfectly fine to expose native references as they'd be cleaned up when you navigate away/close the page.

Once you support all the relevant types, define a calling convention, and add an appropriate verifier to Wasm, it'd be possible to expose all native objects to Wasm, probably by generating a different (and lighter weight) glue to the native classes, or delegating this task to the Wasm compiler.

Of course, if you wanted to have both JS and Wasm to be able to access the same object, you'd have to do some sort of shared ownership, which'd be quite a bit more complicated.

So I'd argue it'd make sense to allow objects that are wholly-owned by the Wasm side or the JS side, which still makes a ton of sense for stuff like WebGL, as you could basically do rendering without calling into JS.

I'm going out on a limb here, but I'd guess since this multi-memory support has landed, that means a single webassembly instance can map multiple SABs, so it might be the beginnings of that.

Re: WASM 3.0 Completed

#378

Post by mallets »

dfabulich wrote: post #342
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?

Basically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested in starting down that road. https://danfabulich.medium.com/webassembly-wont-get-direct-d... Killing JavaScript was never the point of WASM. WASM is for CPU-intensive pure functions, like video decoding. Some people wrongly thought that WASM was trying to kill…

A bit unrelated, but are there any recent benchmarks comparing it with native perf?

Hard to believe it can compete with V8 JIT anytime soon. Might be easier to integrate fast vector libraries within javascript engines.

Re: WASM 3.0 Completed

#379

Post by pjmlp »

rglullis wrote: post #366
pjmlp wrote: post #351

Earlier quoted context omitted.

I have installed all them on the phone, so yes. Unfortunely several of them are glorified webviews. I am old enough to have lived through the days Internet meant a set of networking protocols, not ChromeOS Platform. And on those days hard disks were still bloody expensive, by the way.

> I have installed all them on the phone, so yes. Isn't your phone providing a sandbox, a distribution system, a set of common runtime services, etc to get these native apps functional? You don't have to squint your eyes to realize that this thing we call "document browsers" are doing a lot of the same work that Apple/Google are doing with their mobile OSes.

You mean like Windows Store, Mac App Store, apt, yum/dnf, emerge,....?

All the OS frameworks that are available across most operating systems that don't fragment themselves into endless distributions?

Re: WASM 3.0 Completed

#380

Post by chrismorgan »

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.

On the contrary, it’s something that solid progress is being made towards, and which has been acknowledged (for better or for worse) as something that they expect to be supported eventually. They’re just taking it slow, to make sure they get it right. But most of the fundamental building blocks are in place now, it’s definitely getting closer.
Post reply on HN