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

311–320 of 520 posts

Re: WASM 3.0 Completed

#311

Post by afiori »

dustingetz wrote: post #107
flohofwoe wrote: post #82

Earlier quoted context omitted.

It's not a WASM feature, but would be a web browser feature outside the WASM standard. E.g. the "DOM peeps" would need to make it happen, not the "WASM peeps". But that would be a massive undertaking for minimal benefit. There's much lower hanging fruit in the web-API world to fix (like for instance finally building a proper audio streaming API, because WebAudio is a frigging clusterf*ck, and if any web API would ben…

so the feature does make sense, it’s just the implementation crosses a Conway’s law boundary (I also want this feature, to drive DOM mutations from an effect system)

Sorta, in practical terms once WASI is ready the browsers can define a DOM world in WIT and maybe support components using it

Re: WASM 3.0 Completed

#312

Post by blackoil »

prewett wrote: post #259
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 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…

Security model of web is needed to be brought to the OS.

Re: WASM 3.0 Completed

#313

Post by jesse__ »

matt_kantor wrote: post #292
jesse__ wrote: post #244

Earlier quoted context omitted.

Pretty sure this is here, my dude.

What are you referring to?

My bad, didn't fact check myself before I made an annoying quip. For some reason I thought browsers and started to roll out out native support for TS.

Re: WASM 3.0 Completed

#314

Post by afiori »

hinkley wrote: post #58
Imustaskforhelp wrote: post #49

Earlier quoted context omitted.

I wish the same mate, Please wasm team, I am more than happy waiting 3 years if you can guarantee that you are looking into the best way possible into integrating this feature of dom manipulation. I sometimes feel like js is too magic-y, I want plain boring golang and want to write some dom functions without using htmx preferably. Please give us more freedom! This might be the most requested feature and this was how…

I was even trying to be charitable and read the feature list for elements that would thin down a third party DOM access layer, but other than the string changes I’m just not seeing it. That’s not enough forward progress. WASM is just an extremely expensive toy for browsers until it supports DOM access.

The three main camps of wasm use cases are ( in no particular order )

1. Non browser application (lightweight cloud, plugins, sandboxing)

2. Performance kernels (like compiling a game/rendering engine or AI stuff)

3. Compiling js-like applications from other languages (eg blazor wasm and others)

The only case where DOM access would be useful is 3 and even there 90% of the gains are already available from the JS-strings proposal to avoid copying+reencoding.

Direct DOM access is otherwise mostly a red herring

Re: WASM 3.0 Completed

#315

Post by simultsop »

spartanatreyu wrote: post #283
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.

It's also too early to worry about DOM apis over wasm instead of js. The whole problem with the DOM is that it has too many methods which can't be phased out without losing backwards compatibility. A new DOM wasm api would be better off starting with a reduced API of only the good data and operations. The problem is that the DOM is still improving (even today), it's not stabilized so we don't have that reduced set to…

I am oversimplifying it, why should anything be stable?

That is the trend we face now days, there is too less stable stuff around. Take macOS, a trillion dollar company OS, not an open source without funding.

Stable is a mirage, sadly.

Re: WASM 3.0 Completed

#316

Post by ivell »

prewett wrote: post #259
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 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…

I would argue that as soon as it was decided to include JavaScript runtime in the browser, it stopped being a plain document browser. From then on, we were just on the evolutionary path of converting it from a low capability app sandbox to a highly capable one.

Re: WASM 3.0 Completed

#317

Post by jesse__ »

halfcat wrote: post #277
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…

> DearIMGUI can probably already do like 85% of what modern webapps do I’m with you. Main blocker I’ve seen to “just use ImGui for everything” (which I’d love to adopt), is if I run ImGui in WASM the keyboard doesn’t open on mobile. This seems possible in theory because egui does it. Even though running ImGui on mobile via WASM isn’t the primary use case, inevitably the boss or someone is going to need to “just do a…

I'd say two things about this.

1. Opening the native keyboard and plumbing those events through to the WASM runtime sounds pretty easy. It's probably not cause modern software, but conceptually it should be trivial.. right??

2. In terms of 'the boss' wanting to do 'that one weird thing' that there isn't a library/plugin/whatever for in DearImgui land. If dev time for everything else gets faster, than the 10x cost of that small corner case can be absorbed by net win. Now, I'm pretty sus on the claim everything else gets better today, but we can certainly imagine a world where they do, and it's probably not far away

Re: WASM 3.0 Completed

#318

Post by exabrial »

My dream is we get pluggable execution runtimes (wasm, jvm, , LLVM IR?) with pluggable display tech (svg, html, opengl) and each tech JITs itself on your platform.

While we do need a default “text mode” (html), js is not the answer to a common language and is holding everything back.

Re: WASM 3.0 Completed

#319

Post by wyager »

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…

This seems less than ideal to me.

1. Different languages have totally different allocation requirements, and only the compiler knows what type of allocator works best (e.g. generational bump allocator for functional languages, classic malloc style allocator for C-style languages).

2. This perhaps makes wasm less suitable for usage on embedded targets.

The best argument I can make for this is that they're trying to emulate the way that libc is usually available and provides a default malloc() impl, but honestly that feels quite weak.

Post reply on HN