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

381–390 of 520 posts

Re: WASM 3.0 Completed

#381

Post by danhau »

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.

WASM is to webbrowsers what WebGPU is to webbrowsers. Designed with browsers in mind, but not bound to them.

Re: WASM 3.0 Completed

#382

Post by chrismorgan »

tormeh wrote: post #260
jesse__ wrote: post #238

Earlier quoted context omitted.

Hot take alert > When is WASM finally going to be able to touch the DOM? Coming from a web background, and having transitioned to games / realtime 3D applications... Fuck the DOM dude. The idea that programming your UI via not one but TWO DSLs, and a scripting language, is utter madness. In principal, it might sound good (something something separation of concerns, or whatever-the-fuck), but in reality you always end…

Preach. HTML and CSS are markup languages for creating documents. Using them for GUI applications is wild and obviously a bad idea.

Most major GUI frameworks operate on something very similar to HTML + CSS.

Re: WASM 3.0 Completed

#383

Post by [deleted] »

p_l wrote: post #347
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?

GC was required part, because it was needed to allow interaction between DOM-side lifetimes and WASM-side lifetimes. You might still need a puny shim to essentially "declare" whatever form you want the DOM API to look like on WASM side (probably utilizing components and WIT in the future) but that shim won't have to do anything other than register the APIs because WASM will be able to take a reference to DOM object a…

[deleted]

Re: WASM 3.0 Completed

#384

Post by kketch »

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 itself does not support pthreads. However things like Emscripten have very good support for pthreads. WASM is one of the compilation targets of Emscripten (we had asm.js before that) and on top of that emscripten provides excellent shims for many POSIX APIs. Regarding Rust which has supported WASM as a compilation target for a long time now, the idiomatic way of doing this is not shiming, but using higher level APIs: if you need parallel execution threads and need to compile to WASM you would use a crate (such as rayon) that is able to compile to WASM (and will use web workers under the hood just like Emscripten does). You would not use pthreads directly (std::thread)

Re: WASM 3.0 Completed

#385

Post by kketch »

stevefan1999 wrote: post #281
jesse__ wrote: post #242

Earlier quoted context omitted.

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

WASI does not implement POSIX. And it isn't the goal of WASI to implement POSIX. It does not support pthreads either. WASI is similar to POSIX because its an API that provides a "system interface" for WASM programs. But the API is much simpler and quite different and capability based. There are things like WASIX (by Wasmer) built on of WASI that aims to provide POSIX support for multiple languages

Re: WASM 3.0 Completed

#386

Post by rglullis »

pjmlp wrote: post #379
rglullis wrote: post #366

Earlier quoted context omitted.

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

> don't fragment themselves into endless distributions?

My dear Lord! In what world are you living in?

Take a look at all of the "mobile apps" you installed on your phone and tell me which of those would ever devote any resource to make a apt/rpm repository for their desktop applications.

Even the ones that want to have a desktop application can not figure out how to reliably distribute their software. The Linux crowd itself is still at the flatpak vs AppImage holy war. Mark Shuttleworth is still beating the snap horse.

The Web as a platform is far from ideal, but if it weren't for it I would never been able to switch to Linux as my primary base OS and I would have to accept the Apple/Microsoft/Google oligopoly, just like we are forced to do it at the mobile space.

Re: WASM 3.0 Completed

#387

Post by brokencube »

TheBicPen wrote: post #321
brokencube wrote: post #225

Earlier quoted context omitted.

I would guess 3 colour channels at 16bit (i.e. 2 bytes) (2^32)÷(1920×1080×4×3×2) = 86

Where does the 4 come from? I thought it was R+G+B+A, but you already have 3 colour channels in that calculation

Yep, my logic is faulty there. And even if we assume that it's 24bpp color, that's still a factor of 2 out.

Re: WASM 3.0 Completed

#388

Post by kketch »

apatheticonion wrote: post #209
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?

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…

You can do all of this using Rust today. Very sane access to multi-threading => writing rust code that runs in parallel and is compiled without you worrying about it to run under several web workers

Re: WASM 3.0 Completed

#389

Post by zarzavat »

nagisa wrote: post #243
zarzavat wrote: post #234

Earlier quoted context omitted.

I still don't understand why it's slower to mask to 33 or 34 bit rather than 32. It's all running on 64-bit in the end isn't it? What's so special about 32?

That's because with 32-bit addresses the runtime did not need to do any masking at all. It could allocate a 4GiB area of virtual memory, set up page permissions as appropriate and all memory accesses would be hardware checked without any additional work. Well that, and a special SIGSEGV/SIGBUS handler to generate a trap to the embedder. With 64-bit addresses, and the requirements for how invalid memory accesses shoul…

> AND-masking does not really allow for producing the necessary traps for invalid accesses.

Why does it need to trap? Can't they just make it UB?

Specifying that invalid accesses always trap is going to degrade performance, that's not a 64-bit problem, that's a spec problem. Even if you define it in WASM, it's still UB in the compiler so you aren't saving anyone from UB they didn't already have. Just make the trapping guarantee a debug option only.

Re: WASM 3.0 Completed

#390

Post by austin-cheney »

chrismorgan wrote: post #380
austin-cheney wrote: post #216

Earlier quoted context omitted.

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.

Aside from everything WASM has ever said, the security issues involved, and all the other evidence and rational considerations this still won’t happen for very human reasons.

The goal behind the argument is to grant WASM DOM access equivalent to what JavaScript has so that WASM can replace JavaScript. Why would you want that? Think about it slowly.

People that write JavaScript for a living, about 99% of them, are afraid of the DOM. Deathly afraid like a bunch of cowards. They spend their entire careers hiding from it through layers of abstractions because programming is too hard. Why do you believe that you would be less afraid of it if only you could do it through WASM?

Post reply on HN