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

391–400 of 520 posts

Re: WASM 3.0 Completed

#391

Post by norman784 »

jenadine wrote: post #354
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…

That's true. But without the DOM we also loose the browser native accessibility support and text interaction and so on.

I know nothing about how accessibility supports works in the browser, but could they offer a way to use the accessibility API with your custom UI rendered in WebGL/WebGPU?

Re: WASM 3.0 Completed

#392

Post by norman784 »

jesse__ wrote: post #313
matt_kantor wrote: post #292

Earlier quoted context omitted.

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.

Maybe you got confused, because NodeJS is now able to strip annotations (it does not transform enums, etc) to let you run Typescript files directly.

Re: WASM 3.0 Completed

#393

Post by flohofwoe »

creata wrote: post #350
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…

> WebAudio is a frigging clusterf*ck Out of curiosity, what issues do people have with WebAudio since audio worklets became widely supported?

Audio worklets are a step into the right direction for streaming audio, but for a simple audio-streaming API you don't need the complex node-based architecture of WebAudio, you just need a JS callback which writes samples into an ArrayBuffer.

With audio worklets this callbacks runs in a separate audio thread, and with the (deprecated) ScriptProcessNode this callback runs on the main thread.

E.g. a "good" web audio API replacement would only offer a callback that runs in a separate audio thread plus a convenience function call which allows to push small sample-packets from the main thread to the audio thread (at the cost of increased latency to avoid starving) - this push-function would basically be the replacement for ScriptProcessorNode.

In general, see here for a pretty good overview why WebAudio as a whole is a badly designed API: https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud...

TL;DR: WebAudio's original design requires a lot of complexity and implementation effort for use cases that are not relevant to most of its users - and all that effort could be used instead to implement a much smaller and focused web audio API that covers actually relevant use cases.

Specifically for audio worklets: those mainly make sense when the entire audio stream generation can happen on the audio thread.

But if you need to generate audio on the main thread (such as in emulators: https://floooh.github.io/tiny8bit/), unless you want to run the entire emulator in the audio thread, you need an efficient way to communicate the audio stream which is generated on the main thread to the audio thread. For this you ideally need shared-memory multithreading, and for this you need control over the COOP/COEP response headers, and for this you need control over the web server configuration (which excludes a lot of popular web hosters, like Github Pages).

For this situation (generate sample stream on browser thread and communicate that to the audio thread) you're basically re-implementing ScriptProcessorNode, just less efficiently and limited by COOP/COEP. So at the very least ScriptProcessorNode should be un-deprecated.

Re: WASM 3.0 Completed

#394

Post by Terretta »

wyldfire wrote: post #265
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…

> ... document browser ... document reader ... I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser". > If we think we need a more thoroughly virtualized machi…

document browser, document reader, printed paper, paper form, return to sender... those are all in the same concept space*

"virtual machine" is clearly not

that said, i love WASM in the browser, high time wrapping media with code to become "new media" wasn't stuck solely with a choice between JS and "plugins" like Java, Flash, or Silverlight

it's interesting to look back at a few "what might have been" alternate timelines, when the iPhone was intended to launch as an HTML app platform, or Palm Pre (under a former Apple exec, the "pod-father") intended the same with WebOS. if a VM running a web OS shows a PDF or HTML viewer in a frame, versus if a HTML viewer shows a VM running a web OS in a frame...

we're still working on figuring out whether new media and software distribution are the same.

today, writing Swift, or Nim, or whatever LLVM, and getting WASM -- I agree with you, feels like a collective convergence on the next step of common denominator

* note: those are all documents and document workflows with skeuomorphic analogs in the same headspace, and newspaper with "live pictures" has been a sci-fi trope for long enough TV news still can't bring themselves to say "video" (reminding us "movie" is to "moving" as "talkie" was to "talking") so extending document to include "media" is reasonable. but extending that further to be "arbitrary software" is no longer strictly document nor media

Re: WASM 3.0 Completed

#395

Post by ifwinterco »

oblio wrote: post #299
xmichael909 wrote: post #266

Earlier quoted context omitted.

Personally not a fan of Windows 95 in the browser, however the browser stoped being a “document reader” a decade ago it’s the only universel, sandbox runtime, and everything is moving in that direction ... safe code. WASM isnt a worst VM; it’s a diffrent trade off: portable, fast start, capability scoped compute without shiping a OS. Raw device still have their place (servers). If you need safe distribution + perform…

A decade ago? Gmail was launched in 2004, 21 years ago.

Not to mention Java applets which is how you would do this sort of thing in the early 2000s

Re: WASM 3.0 Completed

#396

Post by apignotti »

pjmlp wrote: post #371
cesarb wrote: post #232

Earlier quoted context omitted.

> Plus ça change...

The difference is that now it is cool. https://cheerpj.com/

Hi, thanks for the mention :-)

Lead dev of CheerpJ and CTO of Leaning Technologies here. Happy to answer any question from the community.

Re: WASM 3.0 Completed

#397

Post by singularity2001 »

afiori wrote: post #330
preommr wrote: post #22

On gc: > Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm. There's already a lot misunderstandings about wasm, and I fear that people will just go "It supports GC, so we can just export python/java/c#/go etc." This is not a silver b…

The two main benefits of wasm GC are that compilers can avoid implementing or compiling a full GC but also that the guest and the host can share structured data types

That was the hope but unfortunately the browser can't do anything with WASM GC structs, not even read them!

Re: WASM 3.0 Completed

#398

Post by phkahler »

atroche wrote: post #258
phkahler wrote: post #119

Still looking forward to when they support OpenMP. We have an experimental Solvespace web build which could benefit quite a bit from that. https://cad.apps.dgramop.xyz/ Open source CAD in the browser.

This is one of the best WASM-based web UIs I've seen! What was the hardest part of getting your desktop build working via Emscripten?

One thing worth noting, everything but the menus and popups is drawn with openGL. The text window uses GNU unifont which is a bitmap font. All the interactions are handled the same way as the desktop versions.

Re: WASM 3.0 Completed

#399

Post by thrance »

DarkNova6 wrote: post #376
thrance wrote: post #288

Earlier quoted context omitted.

No, it's not that bad honestly. But it's not more efficient than JS either, and all this ugly glue code hurts my sensibility.

Sounds like something that could be trivially turned into a library, no?

There are some already (https://docs.rs/web-sys/latest/web_sys, for example), and I made mine too as an exercise. But it's still ugly, unecessary, verbose and inefficient code.

Re: WASM 3.0 Completed

#400

Post by phkahler »

threeducks wrote: post #355
phkahler wrote: post #295

Earlier quoted context omitted.

I didn't do the WASM port. It was started by our previous lead whitequark, and some more work done by a few others. It's not quite complete, but you can do some 3d modeling. Just might not be able to save...

> Just might not be able to save... Oops, I did not read that before going ham in the editor. It seems that the files are stored inside the emscripten file system, so they are not lost. I could download my exported 'test.stl' with the following JavaScript code: var data = FS.readFile('test.stl'); var blob = new Blob([data], { type: 'application/octet-stream' }); var a = document.createElement('a'); a.href = URL.creat…

PRs are welcome. ;-)
Post reply on HN