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

211–220 of 520 posts

Re: WASM 3.0 Completed

#211

Post by wpm »

MisterTea wrote: post #133
boricj wrote: post #73

Earlier quoted context omitted.

Exam mode, or test mode. It's something that appeared about ten years ago, to ensure that a graphical calculator isn't loaded with cheats or has certain features enabled. The technical reason is that the RESET button no longer clears all of the calculator's memory (think Flash, not RAM) and proctors like to see a flashing LED that tells them everything's fine. It's a flawed idea and has led to an arms race, where man…

Sad state of affairs. I had no idea this was a thing.

Indeed. I got bit by the programming bug writing utility programs in TI-BASIC on my TI-83. I would've had a very different life trajectory had I not been able to do that.

Re: WASM 3.0 Completed

#212

Post by cogman10 »

zekrioca wrote: post #201
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.

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 means you now need to decide how and when you communicate its availability.

And the benefits just aren't there. You can create a DOM exposing library for WASM if you really want to (I believe a few already exist) but you end up with a "what's the point". If you are trying to make some sort of UX framework based on wasm then you probably don't want to actually expose the DOM, you want to expose the framework functions.

Re: WASM 3.0 Completed

#213

Post by baxuz »

j0e1 wrote: post #4

> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of stru…

Does this allow for shrinking the WebAssembly.Memory object?

- https://github.com/WebAssembly/design/issues/1397

- https://github.com/WebAssembly/memory-control/issues/6

This is a crucial issue, as the released memory is still allocated by the browser.

Re: WASM 3.0 Completed

#214

Post by malkia »

baq wrote: post #125
jsheard wrote: post #104

Earlier quoted context omitted.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

didn't we call it 'segmented memory' back in DOS days...?

wait.... UNREAL MODE!

Re: WASM 3.0 Completed

#215

Post by brokencode »

cedws wrote: post #192
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.

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.

You can use a framework that abstracts all the WASM to JS communication for DOM access. There are many such framework already.

The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists.

It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount of work work it’d take to do this.

Re: WASM 3.0 Completed

#216

Post by austin-cheney »

cedws wrote: post #192
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.

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.

Re: WASM 3.0 Completed

#217

Post by zb3 »

whizzter wrote: post #204
zb3 wrote: post #137

Earlier quoted context omitted.

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/

As a _user_ JSPI looks neat, however as a compiler writer JSPI looks like an horrible hairball of security issues and performance gotchas to degrade generated WASM code performance. Say you have a WASM module, straight line code that builds a stack, runs quickly because apart from overflow checks it can just truck on. Now add this JS-Promise thing into the mix: A: now how does a JS module handle the call into the Was…

Regarding C - yes, multiple stacks should be supported, and I literally opened a PR to add coroutine support based on JSPI to emscripten: https://github.com/emscripten-core/emscripten/pull/25111

JSPI-based coroutines are much faster than the old Asyncify ones (my demo shows that).

As for your core message - I'm just the user, but if Google engineers were able to implement that, then it is possible to implement that securely. I remember Google engineers arguing with Apple engineers in GH issues, but I'm not on that level, I just see that JSPI is already implemented in Chrome, so you can't tell me it's not possible.

Re: WASM 3.0 Completed

#218

Post by namuol »

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…

Re: WASM 3.0 Completed

#219

Post by lyu07282 »

vinkelhake wrote: post #187
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?

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 was under the impression that this very much still on the table, with active work like the component model laying the foundation for the ABI to come.

Re: WASM 3.0 Completed

#220

Post by [deleted] »

jjcm wrote: post #176
tjoff wrote: post #148

Earlier quoted context omitted.

Webapps limited by 4GiB memory? Sounds about right. Guess 512 GiB menory is the minimum to read email nowadays.

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…

[deleted]
Post reply on HN