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

181–190 of 520 posts

Re: WASM 3.0 Completed

#181

Post by TrueDuality »

renehsz wrote: post #97
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time). But if you really need more than 4GB of memory, then sure, go ahead and use it.

The irony for me is that it's already slow because of the lack of native 64-bit math. I don't care about the memory space available nearly as much.

Re: WASM 3.0 Completed

#183

Post by afiori »

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.

I am not sure what you actually want but it sounds like something where the component model (the backbone of WASI) might help.

It defines a framework to allow modules to communicate with structured data types by allowing each module to decide how to map it to and from its linear memory (and in future the runtime GC heap)

In your case you could be able to define WIT interfaces for your go types and have your compiler of choice use it to generate all the relevant glue code

Re: WASM 3.0 Completed

#184

Post by DarkNova6 »

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.

Re: WASM 3.0 Completed

#185

Post by icar »

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 would bet on browsers being able to consume Typescript before WASM exposing any DOM API. That'd improve the Javascript situation a bit, at least.

Re: WASM 3.0 Completed

#186

Post by ctvo »

jschoe wrote: post #122
flohofwoe wrote: post #85

Earlier quoted context omitted.

> The idea of doing DOM manipulation in a language that is not Javascript ...is already possible, see for instance: https://rustwasm.github.io/docs/wasm-bindgen/examples/dom.ht... You don't need to write Javascript to access the DOM. Such bindings still call JS under the hood of course to access the DOM API, but that's an implementation detail which isn't really important for the library user.

You don't get it.

... maybe you don't get it?

_Telling the browser how you want the DOM manipulated_ isn't the expensive part. You can do this just fine with Javascript. The browser _actually redrawing after applying the DOM changes_ is the expensive part and won't be any cheaper if the signal originated from WASM.

Re: WASM 3.0 Completed

#187

Post by vinkelhake »

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.

Re: WASM 3.0 Completed

#188

Post by wslh »

jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

I assume that looking into the present we need to think about running local LLMs in the browser. Just a few days ago I submitted an article about that [1].

[1] https://news.ycombinator.com/item?id=45200414

Re: WASM 3.0 Completed

#189

Post by afiori »

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.

Webgl can't access the dom either

Re: WASM 3.0 Completed

#190

Post by grayrest »

mattlondon wrote: post #134

But looks like you still cannot open a raw TCP or UDP socket? Who needs this internet network thing huh? I appreciate it is a potential security hole, but at least make it behind a flag or something so it can be turned on.

Opening a socket would fall under WASI[1].

[1] https://github.com/WebAssembly/wasi-sockets

Post reply on HN