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

361–370 of 520 posts

Re: WASM 3.0 Completed

#361

Post by dontlaugh »

whizzter wrote: post #78
flohofwoe wrote: post #33

Since it hasn't been mentioned here yet: I wonder if the multiple-memories feature will somehow allow to avoid the extra copy that's currently needed when mapping a WebGPU resource. This mapping is available in a separate ArrayBuffer object which isn't accessible from WASM without calling into JS and then copying from the ArrayBuffer into the WASM heap and back. Multiple WASM memories and Clang's/LLVM's address space…

I'm just getting horrible segmenting and far-pointer vibes of the whole thing, been coding a classic Gameboy game for fun so fiddling with memory mappings is part of the "fun" but for anything non-constrained I'd hate that. We buried far pointers with DOS and Win16 for a good reason..

"Far" memory is already a central concept in modern GPU APIs. Not all GPUs naturally share memory with the CPU they're running against and handles for resources are a requirement.

Re: WASM 3.0 Completed

#362

Post by Tade0 »

namuol wrote: post #218
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?

> When can we finally kill JavaScript? If you think JavaScript has problems I have bad news about the DOM…

Wanted to say the same thing. People often conflate JS with the DOM API, but that couldn't be further from the case.

You can get rid of JS, but that won't help much because it's just a small language interfacing with a huge, old, backwards compatible to 20+ years ago system that is the DOM.

Re: WASM 3.0 Completed

#363

Post by dontlaugh »

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…

DOM API interactions with JS are already described with a DDL, they're not exactly native JS APIs.

Re: WASM 3.0 Completed

#364

Post by DaiPlusPlus »

mananaysiempre wrote: post #262
magicalhippo wrote: post #191

Earlier quoted context omitted.

It was glorious I tell you. Especially how you could increase the segment value by one or the offset by 16 and you would address the same memory location. Think of the possibilities! And if you wanted more than 1MB you could just switch memory banks[1] to get access to a different part of memory. Later there was a newfangled alternative[2] where you called some interrupt to swap things around but it wasn't as cool. T…

> Think of the possibilities! Schulman’s Unauthorized Windows 95 describes a particularly unhinged one: in the hypervisor of Windows/386 (and subsequently 386 Enhanced Mode in Windows 3.0 and 3.1, as well as the only available mode in 3.11, 95, 98, and Me), a driver could dynamically register upcalls for real-mode guests (within reason), all without either exerting control over the guest’s memory map or forcing the g…

> The absolute madmen put the upcall entry point inside the BIOS copyright string.

Isn’t that an arbitrary string, though? Presumably AMI and Insyde have different copyright messages, so then what?

Re: WASM 3.0 Completed

#365

Post by bsder »

jayd16 wrote: post #325
prewett wrote: post #259

Earlier quoted context omitted.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…

But that's what they're doing. The hard part isn't the VM. The hard part is the long fought functional yet secure sandbox that a browser provides.

> functional yet secure

Secure? Debatable. Functional? Not really.

For example, try accessing a security key and watch the fun. Sure, if you access it exactly the way Google wants you to, things kinda-sorta work, sometimes. If you don't want to obey your Google masters, good luck getting your Bluetooth or USB packet to your security key.

And because you are "secure", you can't store anything on the local hard drive. Oh, and you can't send a real network packet either. All you can do is send a supplication request to a network database owned by somebody else that holds your data--"Please, sir, can I have some more?". The fact that this prevents you from exporting your data away from cloud-centered SaaS providers is purely coincidental, I'm sure.

So in the name of security we just kneecap the end users--if the users can't do anything, they're secure, right? Diana Moon Glampers would be proud.

Re: WASM 3.0 Completed

#366

Post by rglullis »

pjmlp wrote: post #351
adrianton3 wrote: post #343

Earlier quoted context omitted.

> booked tickets for a flight or bought a home or a car or watched a cat video Would you install a native app to book a flight? One for each company? Download updates for them every now and then, uninstall them when you run out of disk space etc I can ask the same question about every other activity we do in these non-native apps.

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.

Re: WASM 3.0 Completed

#367

Post by tcfhgj »

benrutter wrote: post #358
vinkelhake wrote: post #187

Earlier quoted context omitted.

You can write a WASM program today that touches the DOM, it just needs to go through the regular JS APIs. While there were some discussions early on about making custom APIs for WASM to access, that has long since been dropped - there are just too many downsides.

I have slightly different question than OP - what's left until it feels like javascript is gone for people who don't want to touch it? Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?

> Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?

yes, e.g. with Leptos you don't have to touch JS at all

Re: WASM 3.0 Completed

#368

Post by sebstefan »

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 concepts that are at a much higher level than it?

To WASM isn't it all just pointers in a big heap like every other assembly?

Re: WASM 3.0 Completed

#369

Post by pjmlp »

flohofwoe wrote: post #337
prewett wrote: post #259

Earlier quoted context omitted.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…

The problem is: even us old timers can't deny nor change the fact that operating systems have been putting up barriers to disallow running untrusted code downloaded from the internet. Try to distribute an installer on Windows that isn't signed with an extensive EV-certificate for instance. It's scare popup galore. Not to mention the closed gardens of the Apple and Google Stores which even when you get in, you can be…

Just wait until the Web finally becomes ChromeOS Platform, after the Safari barrier is out of the way.

Re: WASM 3.0 Completed

#370

Post by sfn42 »

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.

Sounds to me like they forgot the W in WASM.
Post reply on HN