What practical use cases for #WebAssembly can you imagine?
Tell about it in this thread.
I use WASM to integrate software solutions across different stacks. For example, I compile a Twofish cipher implementation from C to WASM and use it in the browser. It’s cheap and prevents reinventing the wheel.
However, WASM has limitations: no threads, no hardware acceleration, etc.
What other real-world use cases can you imagine?
@pancsta i've just clicked your link.
I waited a seconds for a loading spinner. Then i closed that page.
That is unacceptable bad UX, because the Time to Useful Content is too high. The proper way is to pre-render web pages.
That is common problem of any projects who trying to use WASM instead of JS. The UI works bad and does not competitive to any site built via HTML & JS.
There are blog post about this problem
https://hacks.mozilla.org/2026/02/making-webassembly-a-first-class-language-on-the-web/
This post is an expanded version of a presentation I gave at the recent WebAssembly CG meeting in Munich. WebAssembly has come a long way since its first release in 2017. The 1.0 version of WebAssembly was already a great fit for low-level languages like C and C++, and immediately enabled many new kinds of applications to efficiently target the web.
Not really a use case, but what I consider the killer app of #WebAssembly .. *polyglot* modular systems and contract-based development where #wasm components can be dropped in at runtime and be hosted on any device, from cloud-based servers to mobile and IoT on the edge.
@blyxyas @pancsta that is how segmentation does work. One users will wait 0.5 seconds, another ones will wait 10 seconds, most of them will not wait at all and just drop the tab.
Also such sites does not work for clients who disable JS (the advanced wealthy users who could pay). They will just see an infinity scroll.
The same with SEO. Google actually can index such sites, but will rank it on the bottom. Many others search engines will not found a content and will not show site in results
@vitonsky @pancsta I'm still not seeing your problem. I tried with some more browsers on more OS.
Linux: Firefox, Librewolf, Firedragon (Floorp-based): Less than 0.5%
Linux: Tor (temporarily JS-enabled) about 5-8 seconds, on the light end for Tor.
iPhone 12 iOS with cellular: Safari < 0.5s
iPadOS with Wifi: Ecosia (chromium-based) < 0.5s
@vitonsky not a blocker for actual apps - in iOS, you also wait for installation. Websites, on the other hand, dont need JS (client side code) - see datastar and htmx. #Go is obese, but other platforms produce smaller #WASM binaries.
The point stands - avoid #JS, be happy. The BE/FE contract should move from APIs to markup structure.
btw, go-app supports SSR for SEO, and almost compiles with #TinyGo
@pancsta this design simply uncompetitive in the web.
I mean you can build everything you want as you wish, it just won't be demand.
Nobody needed in a web site that does not work as expected.
I interesting in practical use cases, not a potential scenarious in far future. Maybe 20 years later we actually will use WebAssembly as first class citizen to build sites. It would be nice future.
Interesting to know what problems & needs the WASM can solve right now or in near future.
Robert Vitonsky
pancsta
🫧 socialcoding..
Alejandra 🔜 Rust Week 2026