Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Playground

observablehq.com

Post reply on HN
Print view View original

81–90 of 99 posts

Re: WebAssembly Playground

#81

Post by pphysch »

davidmurdoch wrote: post #69
martinald wrote: post #54

Earlier quoted context omitted.

As far as I know Figma used asm.js (then WASM) from the start. I actually don't think they'd have had the success they had without it - it would have been too slow built in JS. So in a way webasm/asm.js is already allowing whole new categories of webapps we take for granted now.

I always wonder how much faster JS could be if the effort that went into WASM went into JS. ASM.js, SIMD, snapshots, etc directly in JS could have really made it a serious contender for high-performance software. Of course, without WASM, we'd be missing out on lots of cool software that was previously stuck on desktop/native. But I'm not entirely convinced it was the right path.

JS being abused as a compilation target is definitely not a long-term strategy for the web. Going forward we need less emphasis on JS and more on HTML and WASM.

Re: WebAssembly Playground

#82

Post by titzer »

kevingadd wrote: post #79
ledgerdev wrote: post #56

Earlier quoted context omitted.

From my perspective It's 2 primary blockers. 1. It's too damn hard to get data into and out of wasm modules. The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data into and out of modules first. 2. Lack of GC which has made languages like js/python/jvm/c# u…

Sadly the current iteration of WASM GC is still too limited for stuff like JVM or C# garbage collection semantics without jumping through a lot of hoops. I'm optimistic that in a few years there will be an expanded version of it that more runtimes can adopt, though. #1 is a pet grievance of mine though. The intentional choice not to build mmap or read-only pages into the WASM memory model is really frustrating.

Are you referring to the weak references or to interior pointers? What I've been surprised by over the years it that a simplified, perhaps slightly broken version of a language comes to Wasm first, then as features expand, more of the guest language features, libraries, platform, and ecosystem comes, piece by piece. CheerpJ claims to have a fully-featured JVM, and Google is fielding Java compiled to Wasm GC with pretty good results. Wasm is bringing these platforms over piece by piece; so far there haven't been few "boom, here's full Language X on Wasm" moments. Instead we're progressing quite incrementally.

Re: WebAssembly Playground

#83

Post by ledgerdev »

digdugdirk wrote: post #74
phickey wrote: post #73

Earlier quoted context omitted.

> The component model is addressing this but it's sprawled out into literally rebuilding "worlds" and turning wasm modules into sort of lightweight virtual machines. I wish there was just more of a focus on getting data into and out of modules first. As someone who works on the Component Model, this perception is interesting to me, can you explain your thinking a bit more? From my perspective, getting data in and out…

As someone who wanted to try to use WASM ~1yr ago, I was unable to find any reasonable way to get data in/out of wasm from the local environment, and gave up on trying to learn it because of this. Could you please provide links/info for how to do so? I want to be able to learn how to use it, but without this ability it seems entirely useless for me.

What host language and guest language would be top of list? I have some a few working I have been playing with.

Re: WebAssembly Playground

#84

Post by int_19h »

actionfromafar wrote: post #49
bennettbackward wrote: post #32

Earlier quoted context omitted.

The official Windows video editor Microsoft Clipchamp[1] also extensively uses WASM for it's video export process. [1]: https://clipchamp.com/en/windows-video-editor/

A Windows only WASM program? But…

That's one way to write software that can seamlessly adapt to any future architecture changes. And Windows on ARM is already a thing.

Re: WebAssembly Playground

#85

Post by int_19h »

jsheard wrote: post #51
bennettbackward wrote: post #32

Earlier quoted context omitted.

The official Windows video editor Microsoft Clipchamp[1] also extensively uses WASM for it's video export process. [1]: https://clipchamp.com/en/windows-video-editor/

Microsoft Flight Simulator also uses WASM for plugins, which allows them to run portably on both the PC and Xbox versions of the game, with sandboxing, and still get decent performance. https://docs.flightsimulator.com/html/Programming_Tools/WASM... It should also be future proof should they ever do a native ARM build.

I do wonder why this use case - using wasm as cross-platform, cross-architecture portable binaries with performance profile "close enough" to optimized native code - is not more common. One can easily imagine an OS directly supporting such binaries even, JIT-compiling and caching them as needed.

Re: WebAssembly Playground

#86

Post by davidmurdoch »

pphysch wrote: post #81
davidmurdoch wrote: post #69

Earlier quoted context omitted.

I always wonder how much faster JS could be if the effort that went into WASM went into JS. ASM.js, SIMD, snapshots, etc directly in JS could have really made it a serious contender for high-performance software. Of course, without WASM, we'd be missing out on lots of cool software that was previously stuck on desktop/native. But I'm not entirely convinced it was the right path.

JS being abused as a compilation target is definitely not a long-term strategy for the web. Going forward we need less emphasis on JS and more on HTML and WASM.

I'd like even more emphasis on JS, personally.

Re: WebAssembly Playground

#87

Post by kevingadd »

titzer wrote: post #82
kevingadd wrote: post #79

Earlier quoted context omitted.

Sadly the current iteration of WASM GC is still too limited for stuff like JVM or C# garbage collection semantics without jumping through a lot of hoops. I'm optimistic that in a few years there will be an expanded version of it that more runtimes can adopt, though. #1 is a pet grievance of mine though. The intentional choice not to build mmap or read-only pages into the WASM memory model is really frustrating.

Are you referring to the weak references or to interior pointers? What I've been surprised by over the years it that a simplified, perhaps slightly broken version of a language comes to Wasm first, then as features expand, more of the guest language features, libraries, platform, and ecosystem comes, piece by piece. CheerpJ claims to have a fully-featured JVM, and Google is fielding Java compiled to Wasm GC with pret…

Interior pointers and WRs are both basically mandatory, yeah. I have faith they'll arrive eventually.

I think incremental progress is generally great, but since we already have 'all of .NET' in WASM by shipping our own GC, end users seem like they wouldn't be happy with 'we use WASM GC now and all of your code is broken'

EDIT: We also have dependent handles in a few places, and I'm not sure how you'd do those without a more sophisticated GC. But it's probably possible and they're at least not used as widely as WRs.

Re: WebAssembly Playground

#88

Post by kinow »

modeless wrote: post #12
thrdbndndn wrote: post #2

Question from someone knew very little in this domain: what stops mass adoption of WebAssembly? A few years ago, I used a WASM demo website which can use a WASM version of ffmpeg to mux audio and video into a file (transcoding obviously wasn't practical, at least not at that time), and I was very impressed. I can see lots of potential of it. But I still haven't see much usage of it even today. (To be totally honest -…

I bet it is used in a lot of ways people don't notice. In my site[1] I use wasm to run an ancient piece of code called SGP4 to propagate satellite orbits, but it's totally invisible to the user. Someone actually ported SGP4 to JavaScript but it's slower and the results don't perfectly match the original, so it's great to have the option to run the real C version (actually the original is Fortran but the C port is the…

Ah, I used your site a lot after I bought a beginner's telescope some years ago, thanks for all the fun I had waking up early to spot satellites! Had no idea it had any wasm, interesting!

Re: WebAssembly Playground

#89

Post by lewisjoe »

lesuorac wrote: post #60
lewisjoe wrote: post #24

Earlier quoted context omitted.

By mass adoption, do you mean why not all existing softwares are ported to webassembly so that they can be run on browsers? Most websites are just that - "sites". Complicated softwares that _need_ to be run on the web are already leveraging WebAssembly to an extent. 1. Figma (Design tool) uses Webassembly underneath for graphics operations. 2. Zoho Writer (word processor) uses WebAssembly for leveraging ICU capabilit…

Is there a citation for 3? Afaik, WASM is only used by Sheets [1]. [1]: https://2024.wasmio.tech/sessions/webassembly-at-google/

No there's no announcements yet for #3. But if you look around their code you'll find wasm files for spellchecking/proofing and associated models for select few languages.

Combined with the fact that google docs support proofing for those languages offline, it's easy to guess how they achieved it.

Re: WebAssembly Playground

#90

Post by neonsunset »

kevingadd wrote: post #87
titzer wrote: post #82

Earlier quoted context omitted.

Are you referring to the weak references or to interior pointers? What I've been surprised by over the years it that a simplified, perhaps slightly broken version of a language comes to Wasm first, then as features expand, more of the guest language features, libraries, platform, and ecosystem comes, piece by piece. CheerpJ claims to have a fully-featured JVM, and Google is fielding Java compiled to Wasm GC with pret…

Interior pointers and WRs are both basically mandatory, yeah. I have faith they'll arrive eventually. I think incremental progress is generally great, but since we already have 'all of .NET' in WASM by shipping our own GC, end users seem like they wouldn't be happy with 'we use WASM GC now and all of your code is broken' EDIT: We also have dependent handles in a few places, and I'm not sure how you'd do those without…

Quite a bit of code may end up relying on a CWT because a dependency uses assembly-unloading-friendly cache internally, hopefully it fails gracefully once .NET switches to WASM GC...
Post reply on HN