> As far as applications go, the most prominent WasmGC deployment is Google Sheets. This spreadsheet app used to evaluate per-cell spreadsheet formulae using Java code, compiled to JS; Sheets has now fully switched to WasmGC (web.dev) instead. There are precious few other prominent examples, however.
> Wasm-compiled SQLite is so successful that it actually replaced a part of the web platform, causing Chrome to remove WebSQL entirely
The causual inference here is almost certainly incorrect. According to Chrome Blog [0], WebSQL turned out to be a non-starter as early as November 2010, which is before Webassembly was released, and before it became known that SQLite could be ported to Webassembly to run in web browser.
I'm currently developing a WASM app in C#. (Via in-browser Blazor). We chose this stack because we're a small team with a lot of C# knowledge, and our server-side is C#.
As a result, with a small team we can make a much prettier and slicker app; and it's easy for everyone to be "full stack" without the learning curve that comes with two languages. It's also nice to share code between the server and browser, for things like contracts and small bits of logic that are easily isolated.
One of the more frustrating aspects of WASM via C# is the slow load time because the binary is large. Another frustrating aspect is that, for tight integration with the DOM, it still is best to use JavaScript. As a result, we end up spending time writing wrappers for "best of class" JavaScript libraries instead of using C# libraries.
---
In our case, with hindsight, I think server-side Blazor (with pure JavaScript or TypeScript for logic that needs to happen in the browser,) would be better for our purposes. (It basically moves a lot of the state that would be in the browser to the server. This is really helpful for small teams.) There's reasons why I don't think we'll switch any time soon.
I'm always dubious on claims like these. JavaScript and the web platform are synonymous in discourse but much different in reality. Even with transpired languages or WASM, you still have to use the platform, but now in a non standard language. JavaScript isn't that hard, and I really question if not having to learn it really saves time.
It's not that learning JS is hard, it's that JS is a very unsafe and unergonomic language. Which is why we have TS... but TS has other problems. People want to use C# or what have you because these are languages that are simply better to develop large applications in. JS, like most dynamically typed scripting languages, becomes more and more of a liability as application size grows.
JS was always supposed to be a scripting language. That you could build whole applications in it was a neat hack but never supposed to be serious. I think a lot of people have forgotten that.
That's my point, it's still calling JS at the end of the day. Unless you have some computationally expensive functionality that needs optimization like a large Canvas or Excel-esque table, what's the advantage? Just avoiding JS is not enough of a reason for me.
In principle I support WASM, but in actuality I think it falls short for the majority of applications. It's much easier to learn JS than the web platform. Might as well learn it in the primary language.
Blazor generates HTML, but doesn't allow direct manipulation of the DOM unless you start jumping through a lot of hoops. It's generally "good enough" until you get to things like maps or charts with 1000s of datapoints.
The tech community simply wants DOM access for web apps, but the committee is focused on trying to effectively rewrite the JVM in Rust because Rust seems trendy these days.
So the web features languish while the committee still can't agree on how to send strings between two functions on Linux. And the committee moves at a slower pace than the federal government.
i am guessing you personally don't have family stuck overseas waiting for immigration paperwork to move. Its ok separate those ppl from their families?
The DOM is a very weird, complex datastructure built around a very particular programming paradigm. Building a nice interface for it to pretty much anything that can't be 1:1 mapped onto JS is very hard. That's why there are so few browser engines.
In it's class, it's definitely leading for future development. The thing is we can't compare Rust to Python or C# (can't compare Python and C# to each other either, frankly). The only language that competes with Rust genuinely is C++.
Can Rust do what C# does? Yes, unquestionably. But there is a value to a runtime and GC. It makes writing application code a bit easier, more assumptions can be made, and less care needs to be given to memory.
It's suboptimal, but usually doesn't matter. I'd rather write a backend in C#, and the performance is usually more than good enough.
Adobe describes it as a port https://web.dev/articles/ps-on-the-web#webassembly_porting_w... largely because most of the work in doing so was not related to the updated UI front end. As such, the use of Web Components is just one section of many notable things.
I have yet to encounter a scenario where Web Components or Shadow DOM are important for a big app like that where you own the stack. Their value is in creating components third parties can use, which can operate in a moderately hostile environment successfully. First parties have no need of them: React/Svelte/Vue/flavour-of-the-month is strictly better for first party components, and Shadow DOM is quite inappropriate.
That's strange because all the notable implementations of web components that I'm aware of are first party. YouTube, Discord, Slack, Adobe. MS and Alaska Airlines released libraries (in Lit) but does anyone use them?
I think the real value is for first-party complex UIs. The other folks are using React & Friends.
I will go on a record that I never really liked WebAssembly. Google's Native Client allowed people to run safety screened native assembly at like 95% native speed and virtually no startup time, while having a tiny fraction of the engineering complexity.
Accessing browser native classes is still an open issue - in fact, you have to go through JS to do anything, with all the associated performance issues. I don't get it why it's so bad - for every native JS class you find on MDN, there's an equivalent C++ class in the Chrome codebase, which somehow gets bound to the JS JIT. Couldn't we expose all the API through a marshalling/validation layer? Memory leaks are a non-issue, since you can leak native objects in both JS and in C, with the only difference being that in JS, the object is still reachable through a gc root.
Another huge issue is the crappy multithreading support. First, the multithreading solution of JS workers + SharedArrayBuffer is horrible, second you aren't allowed to do it without draconian and impractical security measures, due to the security theather around side channel attacks.
Which makes running heavy apps, like modern video games, practically impossible.
I remember Epic demoing Unreal in the browser in the early 2010s and a lot of people predicted that in the future, most games will be playable via a website. Yeah, that didn't come to pass.
Instead of becoming the default way of writing and distributing web apps, with the convenience of web deployment and the power of real desktop apps, it became a curiosity and a way of gaining tech clout.
> Google's Native Client allowed people to run safety screened native assembly at like 95% native speed and virtually no startup time, while having a tiny fraction of the engineering complexity.
I worked both with NaCl and PNaCl, and they both had their own share of problems, like:
- any interaction with the browser side had to happen via message passing (e.g. the people who today complain that WASM has no DOM access would have a complete mental breakdown if each interaction with the DOM had to go through message passing instead of direct WASM-to-JS calls).
- NaCl had to invent its own APIs for 3D rendering, audio, and pretty much anything else which required any sort of performance (since the only alternative was the above mentioned slow message passing)
- The 'main thread' was basically just an event loop, to get continuous rendering you had to spawn a separate thread (much like what you need to do on the Android NDK)
- They had their own frigging build system which wasn't compatible with anything else. Good luck getting NaCl/PNaCl integrated with something more common like cmake (it works, but it was basically the same PITA like trying to integrate the Android NDK with a proper build system today).
- PNaCl (which was essentially LLVM bitcode) had an enormous startup time, even slower than the very first WASM experiments which used AOT.
Also, NaCl was quickly deprecated in favour of PNaCl, but PNaCl suffered from much worse problems than WASM ever had (especially in startup time and runtime performance was at best comparable to WASM).
Another example of Wasm in the browser is: ZetaOffice, which is LibreOffice in the Browser [1]. They recently joined Collabora, which is used for example in OpenDesk[2], which is a replacement for Office365.
ZetaOffice talk[3] about the challenges porting Libreoffice to run client-side in the browser. With topics like GUI Event Handling, Debugging or Multi-Threading, File- System & Size to topics such as CI/CD and dependency handling and upstream.
I just don't understand why you'd want this, or any of the JS server-side nonsense. WebAssembly is designed for the web--why would you want to use it outside the browser, when there are dozens of much more mature frameworks out there that were designed to work on your machine?
It seems to me like a lot of the JS outside the browser stuff out there is motivated by JS people not wanting to learn something different. Meanwhile for those of us who have been doing dev outside the browser, all this is worse solutions to problems we've already got solutions for.
> WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
While the primary target for WebAssembly is indeed the web there are surely plenty of applications for a cross-platform stack-based virtual machine.
> It seems to me like a lot of the JS outside the browser stuff out there is motivated by JS people not wanting to learn something different.
Well that certainly can't be the case here because WebAssembly specifically isn't JavaScript. It's a well specified, reliable platform for different languages to target for cross-platform execution. Is that really so bad? To turn it on its head, if you're going to build a cross-platform application framework, why not use WebAssembly, aside from the fact that it has "web" in the name?
Sandboxing 3rd party code inside existing applications for example. Like plugins for Photoshop-like applications or game mods. Portability is also a big plus for this kind of thing too.
Agreed. Wasm let's you just revoke network access from things that don't need it. I know you can also do that with docker but its an awful big hammer for the job.
Yeah exactly, it is kinda insane how deep open source tech stacks have gone.
We need a world where we can seamlessly synchronously (no IPC, no network) call a function from a 3rd party and be sure it doesn't make any network requests, read the disk (or any other type of I/O) or read non-assigned RAM.
If we could do that the amount of scrutiny you need for your 3rd party code goes down massively. WASM is a step to get there.
One possible use-case is a system like Inferno[0] (the plan9-like operating system). Since, on that OS, you can "mount" CPUs from other machines over the network[1], you either need to make sure all of your machines have the same CPU architecture (including additional instruction sets lest you end up with AVX512 code trying to run on an Intel processor), or you use a non-compiled language. Inferno went with the latter and introduced Limbo[2] for that purpose, but with webasm we could use any language and still leverage all the great tooling being written for it.
[0] https://en.wikipedia.org/wiki/Inferno_(operating_system)
[1] Behind-the-scenes it actually mounts your filesystem onto the remote machine and sends it commands to run, rather than actually "mounting" a CPU over the network. https://9p.io/magic/man2html/1/cpu
[2] https://en.wikipedia.org/wiki/Limbo_(programming_language)
Because people need to run their Apps on multiple targets and having one codebase for all targets helps with keeping maintenance and development costs down. Java would meet this requirement if the UX/UI story was anywhere near as good as the Web's. I'd argue that UI has been the main driver of all of this.
For safely running an untrusted architecture- and operating-system-agnostic binary blob. If all operating systems could even run simple WASI cmdline blobs directly that would actually solve a real problem for me (of distributing a shader compiler executable for Linux, macOS, Windows across x86 and ARM, which is built from massively big 3rd party C++ libraries (so compiling on the user machine isn't really an option).
AFAIK Cosmopolitan is missing the sandboxing features of WASM runtimes which would allow to run untrusted code safely, and for x86 vs ARM it uses the universal binary approach (e.g. you'll either have the x86 or the ARM code as dead weight in the executable).
VSCode is an entire web browser (Electron packaged Chromium). It even ships with "Simple Browser" built in, which is just a web view.
Perhaps a more direct example is Node's/Bun's ability to package a JS/TS project into a single binary with only the JS engine browsers use rather than the whole thing.
I think WebAssembly could be amazing for taking chunks of existing programs and making them super portable (and sandboxed!), and it kind of is already, but boy, I was pretty surprised to just recently realize it's not really as polished or complete as I think you'd hope for this use case.
If you want to build something like libpng (or a myriad of other C libraries,) you need setjmp/longjmp. Not really a huge problem: Emscripten can handle this, it just needs a tiny bit of help via host functions. You can also use Wasm Exception Handling instead, in which case you don't need any hacks on the host side.
So far this sounds pretty good, but actually it isn't, because:
- Wasm Exception Handling is still not part of the standard. They are supported by browsers and runtimes based on browsers, but they are unsupported by lots of other runtimes (Wazero doesn't seem to support them, for example.)
- When you're using Emscripten outside of a browser, you can use the Emscripten method for sjlj support even in a "standalone" build, calling into some simple host functions, which is handy. The problem is... standalone builds with Emscripten don't really work that well. A lot of the syscalls don't really go anywhere: https://github.com/emscripten-core/emscripten/blob/main/syst...
A non-standalone build is possible, but even though Emscripten does use WASI for many things automatically, a lot of host support is required to make this work properly, so outside of a browser environment I reckon this will take a lot of work, and it seems also that it will be hard to properly implement those functions in many of the standalone Wasm runtimes.
You can compile with a Clang/WASI toolchain instead, which will implement much more of the syscalls via WASI, but I don't think this supports the Esmcripten method for handling Wasm Exception Handling, which means you need to have a runtime with Wasm Exception Handling support.
I guess the Clang/WASI toolchain is doing the right thing here, but it's still somewhat frustrating that Wasm Exception Handling is still not a part of the standard or many of the non-browser runtimes.
Thankfully it's not a myriad, but pretty much only a handful libraries which had been derived from libjpeg one way or another (and libjpeg - and by extension libpng - is a huge pile of excrement, and not just because of its weird "poor man's exception handling via setjmp/longjmp").
If you want to load image files with minimal effort, use stb_image.h instead.
Well, I didn't do a detailed survey into the ecosystem, but I think you might be underestimating the prevalence of setjmp/longjmp a little bit. For one thing, tons of stuff hard depends on libpng, and libpng only has limited support for environments without it, so that alone is a pretty hard limiting factor.
But also, I already ran into two different very common libraries that need it. FreeType also needs setjmp/longjmp!
> - Wasm Exception Handling is still not part of the standard. They are supported by browsers and runtimes based on browsers, but they are unsupported by lots of other runtimes (Wazero doesn't seem to support them, for example.)
...yet! :p
EDIT: I realized this comment might be too terse. I contribute to Chicory and wazero, I have recently worked on tail calls for wazero and EH would be the next item on my personal todo list. Let's see!
I also strongly enjoyed Daniel Ehrenberg 's recent tour of WebAssembly over time: When Is WebAssembly Going to Get DOM Support? Or, how I learned to stop worrying and love glue code.
Talking some of the technics of integrating with the web, and how component model might someday be a facility to make that reasonable, but how the browser folks are waiting to see how it goes server-side first, & might not be interested at all.
I don't really understand what limitations using reference types brings, how much glue code is left. I should try & compare some different language's toolchains, see what glue code each relies on!
Regarding the submission here... Nothing but respect for Andy here. And yes finding fit is always so critical. But I do think we are on the cusp on much more, and I especially think the actual web, the front end, would/will be getting millions of miles more out of WebAssembly when async wasm components arrive.
> To answer these questions, we adopt an aesthetically unsatisfying device: the market. Which Wasm deployments have stuck around? Where are people happily using Wasm? Which deployments failed? These are all real indicators by people with skin in the game.
Right now it there are countless constraints on who can use wasm and how. To look at who has been trying today, who has had success today, it kind of ignores that wasm has become an increasingly niche harder to use server side only system. As the number of specs grows less and less runtimes are competitive. Shooting for the moon, but maybe, if async wasm components (wasi preview 3) ship and are good, it could radically expand the ball game.
> TypeScript works better for Figma's needs, then, over time, new features will be written in TypeScript instead. Indeed, looking at the breakdown of Figma over time would seem to reveal that is what has occurred; Wasm is still used for some per-pixel operations, where its greater control over data layout makes it a win, but the application is composed of relatively more JS than Wasm...
>...if you are building an organization to create a web experience, generally speaking, you would rather pull from the deeper pool of JS developers than the more rarified C++/Wasm skill set
This is ultimately answering the reason why above, but it's important to point out the most critical parts of Figma and the reason Figma is worth what it is are the WASM/GPU accelerated parts which make all the interaction snappy and fluid, even the multiplayer stuff is downstream from this.
But also because it's a huge company now and a lot of the developers they hire could never create those critical parts of course the rest of it will bloat out as developers justify their existence.
At Restate.dev (workflow as a code engine) we use Rust/WASM to code-share the implementation of the durable execution protocol between the restate-server and the SDKs to develop workflows. This code is essentially a "pure" state machine: events in, events out, no side effects.
We use WASM in some cases:
* Our Typescript SDK uses wasm-bindgen to compile and release the Rust part of the code. We have chosen WASM over Node native extensions because we wanted to support deno, cloudflare workers, bun, and potentially other runtimes. We've stumbled on few issues related to packaging, but except that it was a smooth process.
* Our Golang SDK uses WaZero + manual bindings using protobuf's. It was a bit of a manual process to set it up, especially surrounding concurrency issues wrt accessing the WaZero runtime plus you need some wasm runtime pooling to get decent performance, but at the end it works well and reliably.
My lesson learned from our experience is that Rust is the real player here, because it delivers on the promise that you can develop libraries that can be easily embedded in high level languages. It's really "write once, bind everywhere".
WASM is just a "packaging"/"distribution" detail in our case, and we picked it just for lack of alternatives. For example in our Python SDK, we could have used WASM but we didn't, instead we went with PyO3 which is an amazingly well done Python -> native code bindgen, and it works without hassle for users as opposed to, for example, CGO in Golang. If Golang had a PyO3-like solution without CGO/any hassle for users, I would have taken it as opposed to doing the WASM bindings myself.
Plus, from what I've tried myself, the whole WASM experience is great only when used in combination with TS/wasm-bindgen, in the other scenarios it's a lot of manual tedious memory moving code involved. Maybe when WIT gets more broadly adopted, and there will be bindgens available in most languages/engines, this will be different.
Majority of my phone usage outside of reading HN is through dedicated apps. News, social media, chats and even substack. If I was building a product today, web would be quite low on the priority list outside of SEO capture.
I don’t know what the state is on Android, but on iOS (and macOS) unblockable notifications aren’t really a thing (notifications need permissions that you manage on a per-app basis) and many app ads can also be blocked (1Blocker does it), though it’s not as powerful because it’s essentially domain blocking.
I’m not disagreeing with you, merely providing more context. Companies like Reddit and Facebook definitely push you more to the apps so they can extract more value out of you.
> Then that’s a shitty company and perhaps you should consider not using their service anymore.
That's not always possible. There might not be enough quality competition and I don't see others following my example to beat the shitty company into submission and make them change their ways if I do that.
> Either way I don’t see how that’s relevant to the point. It’s not like the web is any different in that regard.
Web is very different in that regard. You can pry any app open and change basically anything with a single press of F12. Most of the time, people already did that for you and submitted an ad blocking filter for everyone to use. This isn't even close to the crapware of a typical app store.
It used to be that cli tools were the power users preference but now I feel like that's shifted to web apps (over native). The ability to have multiple tabs/views, load extensions to customize behavior, adjust sizing, etc.
As an example: an absolutely vital tool for me is the Vimium keyboard control extension for navigation, which unfortunately can't be used in dedicated apps.
I'm wondering which of us is the outlier, because I heavily use browser apps on my phone and tablet and ignore vendors' prompts to install their native apps.
The problem with dedicated apps is that you often have to fight with the OS vendor for basic functionality in your app just to distribute it and these days you don't actually gain much with a dedicated app since modern sandboxing is so aggressive and web apis are relatively complete.
Some of what you gain is pretty important though. For example, well written native apps integrate better with the platform’s accessibility features and they typically consume less power, storage, and memory.
That seems... weirdly indirect, when you can run binaries directly on the server. If it's a VM or isolation you need, there's Docker. It feels just like "server-side rendering" of front-end UI libraries/frameworks like react and co. But maybe I'm missing something.
What I get is isolation, so I can run untrusted customer code as a Wasm component knowing it runs in a secure sandbox.
Also, scaling across clouds, edge, on-prem with minimal effort.
Another benefit I enjoy now is changing links between components at runtime. I can for example deploy v2.0.0 of a component and send traffic to it by simply updating a link - and reverse it should things break.
All that comes at a much lighter cost in terms of actual $, but also size (kilobytes/megabytes vs megabytes/gigabytes with Docker containers)
> they did not translate into massive adoption of Wasm by the gaming industry
This is more about monetization and less about technology, and nobody has figured out how to monetize web games beyond hyper-casual 2D games. And you don't need WASM to move a handful 2D sprites around.
Personally I'm quite happy what WASM allows me to do, e.g. the browser has become "just another runtime target" for my C/C++ hobby projects:
...also the actual problem to run game-y stuff in browsers is not WASM, but the terrible state of web APIs, WebGL and WebGPU are both quite okay-ish, but beyond that it's an absolute mess (but OTH, people also cope with game development for Android, which is even worse).
I'm interested in WASM for "plugin extensions" on embedded system, where (if?) it would guarantee me a kind of "sandboxed VM" experience, where I know that the resources for the plugins are limited, and that if it crashes, my own code is not affected.
I'm trying to use that through Rust on ESP32 with "wamr" but so far I've had quite a few compilation and runtime issues
if someone has some experience with that I'm interested :)
I've been building my entire back-end with WASM for several months now, and I can share some thoughts:
1. WASM on the Web: Just don't do it. It's not there yet. WASM actually has overhead compared to regular JavaScript, so it only makes sense for specific operations like video transformations. Otherwise, you're better off with a React stack. React isn't inherently slow—it just makes it easy to write slow code. Plus, most WASM frameworks (like Yew) are still immature with limited ecosystem support.
2. "Lightweight virtualization" sounds great in theory, but reality is different. The promise is "compile once, deploy everywhere," but if you can deploy everywhere, you probably can't deploy anywhere effectively. That's because once you remove networking, time and multi-threading, you are left with pretty much nothing. There is also a no consensus standard. There is WASI but it's a kind of a work-in-progress. Implementation will depend on your host.
I went with Cloudflare Workers, which meant learning their specific environment. The problem with these newer platforms is they don't have the documentation or community support you get with something like Linux. While Cloudflare runs workers on V8 at the edge (which helps), they have restrictions that you only discover as you go. For example, there's no "time" concept available inside a Cloudflare Worker's execution context.
3. Target support is genuinely terrible. Don't assume libraries will compile to wasm32-unknown-unknown—assume the opposite. Most libraries don't separate computational tasks from networking, and Rust's async ecosystem (Tokio) does not play well with WASM, breaking your code. I've had to fork two libraries and submit patches to several others. As a solo developer, this maintenance burden becomes expensive. Making libraries WASM-compatible could be a full-time job.
4. On Scalability: Just because you have a worker, doesn't translate to having "infinite" scalability. Here's the thing - as soon as your application does anything meaningful, you need state. Now your "infinitely scalable" architecture is only as scalable as your state (ie: RDS database) can handle. There isn't really a good server-less database offering and Databases are not the only thing that will bottleneck you here (ie: I have a keycloak server for signups).
> The aim is to build systems with the fine-grained interoperation of shared libraries, specified in a way to allow isolation but without requiring the overhead of an operating system process or a container.
Add time and networking to this mix, and you've basically described an operating system.
> For plug-in and extension use cases, Wasm can be a good option if the host needs isolation from the guest
This is actually WASM's sweet spot. These extensions run in the host environment (like Shopify), and WASM provides JavaScript-like capabilities with language choice and better isolation.
> The cloud Wasm space is a bit of a Wild West
It absolutely is—still in its infancy with little interest from major players to adopt this model.
In conclusion, I'm still torn on the whole thing. Some mornings I wake up to a broken build and wonder what the hell I was thinking. But then there are moments when everything clicks. My worker—27k lines that squeeze down to 3MB—feeling like a jet engine.
The constraints make you want to tear your hair out; but they make you think twice about everything. You can't just throw another dependency at a problem. You need to consider and weigh in any additional code. The worker model makes the request flow clearer and gives you a better understanding of your application life-cycle.
> WASM on the Web: Just don't do it. It's not there yet. WASM actually has overhead compared to regular JavaScript
That's really not what I'm seeing, my WASM home computer emulators (written in plain C) run at about the same performance as their native counterparts (give or take 15%). Just don't switch between the JS and WASM side too often, and use WebGL or WebGPU for rendering (with proper batching).
...of course if you want to have a DOM-based UI framework in WASM, don't do that, but who would come up with such a stupid idea in the first place ;)
It seems like Game UI is its own isolated world that doesn't tell you much about its suitability for regular apps. How often do games support or even need cut-and-paste?
If you really need a DOM based UI I would write a hybrid application, do the UI completely on the JS side via the DOM, and the logic on the WASM side, with a minimal interface to communicate between the two and which doesn't need tons of roundtrips each frame.
Games often need to do at least some DOM work though, like rendering a login dialog or integrating a 3rd party in-app-payment solution (or the obvious one: displaying ads). For this I would also do most work on the JS side.
With Emscripten, such mixed JS/WASM apps are really not that hard, you can even embed JS code snippets right into the C/C++ code.
>"Wasm works well where isolation is needed between different program parts written by different people."
Nailed it. We have JS in the browser, and (particularly with TS) it's a great language for building applications on the web. What's great about WASM is the interop layer we have now between other systems. Our company has a mountain of legacy C++, encoding many years of hard-won business logic, and the ability to tap into that on the frontend (locally, in-client) has been amazing. No more hacky transpilation or maintaining separate codebases; just write your FFI and compile the binary to WASM.
> As far as applications go, the most prominent WasmGC deployment is Google Sheets. This spreadsheet app used to evaluate per-cell spreadsheet formulae using Java code, compiled to JS; Sheets has now fully switched to WasmGC (web.dev) instead. There are precious few other prominent examples, however.
Amazon switched the Prime Video app to WebAssembly and doubled its performance. They support 8,000 device types: https://www.amazon.science/blog/how-prime-video-updates-its-...
A recent talk on it with transcript: https://www.infoq.com/presentations/prime-video-rust/
Sounds like they compile rust to wasm, so regular wasm instead of WasmGC is probably enough for them.
> Wasm-compiled SQLite is so successful that it actually replaced a part of the web platform, causing Chrome to remove WebSQL entirely
The causual inference here is almost certainly incorrect. According to Chrome Blog [0], WebSQL turned out to be a non-starter as early as November 2010, which is before Webassembly was released, and before it became known that SQLite could be ported to Webassembly to run in web browser.
[0] - https://developer.chrome.com/blog/deprecating-web-sql
I'm currently developing a WASM app in C#. (Via in-browser Blazor). We chose this stack because we're a small team with a lot of C# knowledge, and our server-side is C#.
As a result, with a small team we can make a much prettier and slicker app; and it's easy for everyone to be "full stack" without the learning curve that comes with two languages. It's also nice to share code between the server and browser, for things like contracts and small bits of logic that are easily isolated.
One of the more frustrating aspects of WASM via C# is the slow load time because the binary is large. Another frustrating aspect is that, for tight integration with the DOM, it still is best to use JavaScript. As a result, we end up spending time writing wrappers for "best of class" JavaScript libraries instead of using C# libraries.
---
In our case, with hindsight, I think server-side Blazor (with pure JavaScript or TypeScript for logic that needs to happen in the browser,) would be better for our purposes. (It basically moves a lot of the state that would be in the browser to the server. This is really helpful for small teams.) There's reasons why I don't think we'll switch any time soon.
I'm always dubious on claims like these. JavaScript and the web platform are synonymous in discourse but much different in reality. Even with transpired languages or WASM, you still have to use the platform, but now in a non standard language. JavaScript isn't that hard, and I really question if not having to learn it really saves time.
It's not that learning JS is hard, it's that JS is a very unsafe and unergonomic language. Which is why we have TS... but TS has other problems. People want to use C# or what have you because these are languages that are simply better to develop large applications in. JS, like most dynamically typed scripting languages, becomes more and more of a liability as application size grows.
JS was always supposed to be a scripting language. That you could build whole applications in it was a neat hack but never supposed to be serious. I think a lot of people have forgotten that.
> Even with transpired languages or WASM, you still have to use the platform, but now in a non standard language.
That's the entire point of WASM: To program in the browser using any language you want.
IMO, the big flaw is WASM is that browser APIs aren't "first class." IE, all calls to the browser APIs have to go through JavaScript.
That's my point, it's still calling JS at the end of the day. Unless you have some computationally expensive functionality that needs optimization like a large Canvas or Excel-esque table, what's the advantage? Just avoiding JS is not enough of a reason for me.
In principle I support WASM, but in actuality I think it falls short for the majority of applications. It's much easier to learn JS than the web platform. Might as well learn it in the primary language.
> It's much easier to learn JS than the web platform.
Just because I know JavaScript doesn’t mean I want to use it. It’s an ugly and cumbersome language.
I disagree; language choice for a project has a lot of factors: Team familiarity, the need to compile or not, ect, ect.
This is why there are also languages like TypeScript, but they wouldn't work in our case because we want to keep the corpus of languages small.
IMHO no platform should force a specific programming language on the programmer, and JS is a lousy compilation target (compared to WASM at least).
But the biggest problem of the web isn't actually JS or WASM, but the inflexible DOM and the (for the most part) poorly designed web APIs.
Blazor generates HTML, but doesn't allow direct manipulation of the DOM unless you start jumping through a lot of hoops. It's generally "good enough" until you get to things like maps or charts with 1000s of datapoints.
If I have learned anything in decades of developing is that adding layers never short times or make life easier
So you went back to writing assembly...?
If someone suggests that 9 layers is perhaps a touch too many, that doesn't imply that the correct solution is necessarily go back to one layer.
> If someone suggests that 9 layers is perhaps a touch too many (but 8 layers is better than 1)
> adding layers never short times or make life easier
Pick one.
Anyway when people say they don't like abstraction layers what they mean is always they don't like abstraction layers except their favorite ones.
I'm willing to consider there being a happy medium. That doesn't mean more is always better, and it doesn't mean that this particular one is good.
> I think server-side Blazor (with pure JavaScript or TypeScript for logic that needs to happen in the browser,)
Do you mean server side rendering or interactive server mode?
Server-side rendering. I haven't tried interactive mode yet. (It wasn't available when we started our project.)
It's a tale of bureaucracy.
The tech community simply wants DOM access for web apps, but the committee is focused on trying to effectively rewrite the JVM in Rust because Rust seems trendy these days.
So the web features languish while the committee still can't agree on how to send strings between two functions on Linux. And the committee moves at a slower pace than the federal government.
The JVM reference keeps being done, although bytecode based systems exist since 1958.
> And the committee moves at a slower pace than the federal government.
As for that, I for one would ask that the federal government revert to going a bit more slowly.
In general I'd agree but not having string interop after 10 years is a killer (not a feature).
> As for that, I for one would ask that the federal government revert to going a bit more slowly.
so ppl can be stuck in immigration queue for even longer ?
But I have heard it is worst place to be. So why would any immigrants be lining up?
The money you can make here can be worth it despite the, ah, societal dysfunction and risk of persecution that you must accept.
boring tangent.
As an alternative to being pulled off the street and indefinitely detained? Yes?
As someone who went through the US immigration system I'm not deluded about its flaws. But the current situation is absolutely worse.
i am guessing you personally don't have family stuck overseas waiting for immigration paperwork to move. Its ok separate those ppl from their families?
Indefinitely detained. How can paperwork be worse than that?
Similar to why you don't care about starving kids in africa but care a lot when your own kids skips a meal.
The DOM is a very weird, complex datastructure built around a very particular programming paradigm. Building a nice interface for it to pretty much anything that can't be 1:1 mapped onto JS is very hard. That's why there are so few browser engines.
> focused on trying to effectively rewrite the JVM in Rust because Rust seems trendy these days.
Rust isn't 'trendy' it's established itself as a leading language.
It's also not controlled by a single corporate like Google (go) or Sun (java) or Microsoft (C#,F#) or Apple (Swift) so a better place to be.
‘Leading’ is still a bit of a stretch. It’s still relatively niche in industry. It’s in the ascendant for sure, but there’s a ways to go yet.
Compared to what? Do you see "niche" and "a leading language" as mutually exclusive? Most languages have their niches.
In it's class, it's definitely leading for future development. The thing is we can't compare Rust to Python or C# (can't compare Python and C# to each other either, frankly). The only language that competes with Rust genuinely is C++.
Rust is a fantastic C++ replacement but I doubt it will replace much else.
Why do you think that? I wrote a webhook recieving API the other day in Rust.
And it's my go-to for anything that isn't front end/web framework.
It has lots of packages now. And can be extended further as it can call other languages modules such as Python.
For me, it's just a question of ergonomics.
Can Rust do what C# does? Yes, unquestionably. But there is a value to a runtime and GC. It makes writing application code a bit easier, more assumptions can be made, and less care needs to be given to memory.
It's suboptimal, but usually doesn't matter. I'd rather write a backend in C#, and the performance is usually more than good enough.
Has VsCode support for c# improved or are you still paying $1k a year or so for Visual Studio?
We use JetBrains products at work, and I don't foot the bill.
You can do anything in it. Go is better for webhooks though IMO. How many dependencies (including transitives) do you have?
I would agree.
Photoshop for the web isn't a "port" of the application. It was rewritten with web components for the UI and WASM for the image processing routines.
The most notable thing about PS in the browser is web components, not WASM.
Adobe describes it as a port https://web.dev/articles/ps-on-the-web#webassembly_porting_w... largely because most of the work in doing so was not related to the updated UI front end. As such, the use of Web Components is just one section of many notable things.
I have yet to encounter a scenario where Web Components or Shadow DOM are important for a big app like that where you own the stack. Their value is in creating components third parties can use, which can operate in a moderately hostile environment successfully. First parties have no need of them: React/Svelte/Vue/flavour-of-the-month is strictly better for first party components, and Shadow DOM is quite inappropriate.
That's strange because all the notable implementations of web components that I'm aware of are first party. YouTube, Discord, Slack, Adobe. MS and Alaska Airlines released libraries (in Lit) but does anyone use them?
I think the real value is for first-party complex UIs. The other folks are using React & Friends.
I will go on a record that I never really liked WebAssembly. Google's Native Client allowed people to run safety screened native assembly at like 95% native speed and virtually no startup time, while having a tiny fraction of the engineering complexity.
Accessing browser native classes is still an open issue - in fact, you have to go through JS to do anything, with all the associated performance issues. I don't get it why it's so bad - for every native JS class you find on MDN, there's an equivalent C++ class in the Chrome codebase, which somehow gets bound to the JS JIT. Couldn't we expose all the API through a marshalling/validation layer? Memory leaks are a non-issue, since you can leak native objects in both JS and in C, with the only difference being that in JS, the object is still reachable through a gc root.
Another huge issue is the crappy multithreading support. First, the multithreading solution of JS workers + SharedArrayBuffer is horrible, second you aren't allowed to do it without draconian and impractical security measures, due to the security theather around side channel attacks. Which makes running heavy apps, like modern video games, practically impossible.
I remember Epic demoing Unreal in the browser in the early 2010s and a lot of people predicted that in the future, most games will be playable via a website. Yeah, that didn't come to pass.
Instead of becoming the default way of writing and distributing web apps, with the convenience of web deployment and the power of real desktop apps, it became a curiosity and a way of gaining tech clout.
> Google's Native Client allowed people to run safety screened native assembly at like 95% native speed and virtually no startup time, while having a tiny fraction of the engineering complexity.
I worked both with NaCl and PNaCl, and they both had their own share of problems, like:
- any interaction with the browser side had to happen via message passing (e.g. the people who today complain that WASM has no DOM access would have a complete mental breakdown if each interaction with the DOM had to go through message passing instead of direct WASM-to-JS calls).
- NaCl had to invent its own APIs for 3D rendering, audio, and pretty much anything else which required any sort of performance (since the only alternative was the above mentioned slow message passing)
- The 'main thread' was basically just an event loop, to get continuous rendering you had to spawn a separate thread (much like what you need to do on the Android NDK)
- They had their own frigging build system which wasn't compatible with anything else. Good luck getting NaCl/PNaCl integrated with something more common like cmake (it works, but it was basically the same PITA like trying to integrate the Android NDK with a proper build system today).
- PNaCl (which was essentially LLVM bitcode) had an enormous startup time, even slower than the very first WASM experiments which used AOT.
Also, NaCl was quickly deprecated in favour of PNaCl, but PNaCl suffered from much worse problems than WASM ever had (especially in startup time and runtime performance was at best comparable to WASM).
Another example of Wasm in the browser is: ZetaOffice, which is LibreOffice in the Browser [1]. They recently joined Collabora, which is used for example in OpenDesk[2], which is a replacement for Office365.
ZetaOffice talk[3] about the challenges porting Libreoffice to run client-side in the browser. With topics like GUI Event Handling, Debugging or Multi-Threading, File- System & Size to topics such as CI/CD and dependency handling and upstream.
[1] https://github.com/allotropia/zetajs / https://zetaoffice.net/
[2] https://www.opendesk.eu/en
[3] https://media.ccc.de/v/clt23-249-libreoffice-technology-and-...
No mention of Orca[0]? WebAssembly Apps Without the Web. A brand new stack for cross-platform applications.
https://orca-app.dev/
I like the idea, but it does not support Linux, making it a non-starter.
I just don't understand why you'd want this, or any of the JS server-side nonsense. WebAssembly is designed for the web--why would you want to use it outside the browser, when there are dozens of much more mature frameworks out there that were designed to work on your machine?
It seems to me like a lot of the JS outside the browser stuff out there is motivated by JS people not wanting to learn something different. Meanwhile for those of us who have been doing dev outside the browser, all this is worse solutions to problems we've already got solutions for.
> WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
While the primary target for WebAssembly is indeed the web there are surely plenty of applications for a cross-platform stack-based virtual machine.
> It seems to me like a lot of the JS outside the browser stuff out there is motivated by JS people not wanting to learn something different.
Well that certainly can't be the case here because WebAssembly specifically isn't JavaScript. It's a well specified, reliable platform for different languages to target for cross-platform execution. Is that really so bad? To turn it on its head, if you're going to build a cross-platform application framework, why not use WebAssembly, aside from the fact that it has "web" in the name?
Sandboxing alone is a very important reason.
Sandboxing 3rd party code inside existing applications for example. Like plugins for Photoshop-like applications or game mods. Portability is also a big plus for this kind of thing too.
Agreed. Wasm let's you just revoke network access from things that don't need it. I know you can also do that with docker but its an awful big hammer for the job.
Yeah exactly, it is kinda insane how deep open source tech stacks have gone.
We need a world where we can seamlessly synchronously (no IPC, no network) call a function from a 3rd party and be sure it doesn't make any network requests, read the disk (or any other type of I/O) or read non-assigned RAM.
If we could do that the amount of scrutiny you need for your 3rd party code goes down massively. WASM is a step to get there.
One possible use-case is a system like Inferno[0] (the plan9-like operating system). Since, on that OS, you can "mount" CPUs from other machines over the network[1], you either need to make sure all of your machines have the same CPU architecture (including additional instruction sets lest you end up with AVX512 code trying to run on an Intel processor), or you use a non-compiled language. Inferno went with the latter and introduced Limbo[2] for that purpose, but with webasm we could use any language and still leverage all the great tooling being written for it.
Because people need to run their Apps on multiple targets and having one codebase for all targets helps with keeping maintenance and development costs down. Java would meet this requirement if the UX/UI story was anywhere near as good as the Web's. I'd argue that UI has been the main driver of all of this.
> WebAssembly is designed for the web--why would you want to use it outside the browser?
I'm not involved in Orca, but I can think of 2 reasons:
1. WebAssembly has really fine-grained sandboxing for untrusted code.
2. WebAssembly has good support for starting the program as parts of it are still being downloaded / compiled.
For safely running an untrusted architecture- and operating-system-agnostic binary blob. If all operating systems could even run simple WASI cmdline blobs directly that would actually solve a real problem for me (of distributing a shader compiler executable for Linux, macOS, Windows across x86 and ARM, which is built from massively big 3rd party C++ libraries (so compiling on the user machine isn't really an option).
I guess https://github.com/jart/cosmopolitan might just be the WebAssembly for the command line then.
AFAIK Cosmopolitan is missing the sandboxing features of WASM runtimes which would allow to run untrusted code safely, and for x86 vs ARM it uses the universal binary approach (e.g. you'll either have the x86 or the ARM code as dead weight in the executable).
Suddenly the front-end coders become full-stack coders.
VSCode is JS outside the browser. It seems that companies such as Microsoft, Saleforce, want to leverage their existing JS tools.
VSCode is an entire web browser (Electron packaged Chromium). It even ships with "Simple Browser" built in, which is just a web view.
Perhaps a more direct example is Node's/Bun's ability to package a JS/TS project into a single binary with only the JS engine browsers use rather than the whole thing.
Same reason Docker was a success - packaging and distribution of apps becomes easier. That's my guess.
So are we inventing JVM again?
Yes. But with manual memory management this time.
Java inside the browser was a thing too, right?
You gave me a 90’s flashback…
Staring at a gray box waiting for something to happen.
I can only remember minecraft
I think WebAssembly could be amazing for taking chunks of existing programs and making them super portable (and sandboxed!), and it kind of is already, but boy, I was pretty surprised to just recently realize it's not really as polished or complete as I think you'd hope for this use case.
If you want to build something like libpng (or a myriad of other C libraries,) you need setjmp/longjmp. Not really a huge problem: Emscripten can handle this, it just needs a tiny bit of help via host functions. You can also use Wasm Exception Handling instead, in which case you don't need any hacks on the host side.
So far this sounds pretty good, but actually it isn't, because:
- Wasm Exception Handling is still not part of the standard. They are supported by browsers and runtimes based on browsers, but they are unsupported by lots of other runtimes (Wazero doesn't seem to support them, for example.)
- When you're using Emscripten outside of a browser, you can use the Emscripten method for sjlj support even in a "standalone" build, calling into some simple host functions, which is handy. The problem is... standalone builds with Emscripten don't really work that well. A lot of the syscalls don't really go anywhere: https://github.com/emscripten-core/emscripten/blob/main/syst...
A non-standalone build is possible, but even though Emscripten does use WASI for many things automatically, a lot of host support is required to make this work properly, so outside of a browser environment I reckon this will take a lot of work, and it seems also that it will be hard to properly implement those functions in many of the standalone Wasm runtimes.
You can compile with a Clang/WASI toolchain instead, which will implement much more of the syscalls via WASI, but I don't think this supports the Esmcripten method for handling Wasm Exception Handling, which means you need to have a runtime with Wasm Exception Handling support.
I guess the Clang/WASI toolchain is doing the right thing here, but it's still somewhat frustrating that Wasm Exception Handling is still not a part of the standard or many of the non-browser runtimes.
> (or a myriad of other C libraries)
Thankfully it's not a myriad, but pretty much only a handful libraries which had been derived from libjpeg one way or another (and libjpeg - and by extension libpng - is a huge pile of excrement, and not just because of its weird "poor man's exception handling via setjmp/longjmp").
If you want to load image files with minimal effort, use stb_image.h instead.
Well, I didn't do a detailed survey into the ecosystem, but I think you might be underestimating the prevalence of setjmp/longjmp a little bit. For one thing, tons of stuff hard depends on libpng, and libpng only has limited support for environments without it, so that alone is a pretty hard limiting factor.
But also, I already ran into two different very common libraries that need it. FreeType also needs setjmp/longjmp!
> - Wasm Exception Handling is still not part of the standard. They are supported by browsers and runtimes based on browsers, but they are unsupported by lots of other runtimes (Wazero doesn't seem to support them, for example.)
...yet! :p
EDIT: I realized this comment might be too terse. I contribute to Chicory and wazero, I have recently worked on tail calls for wazero and EH would be the next item on my personal todo list. Let's see!
Oh cool, that would be a nice improvement for the ecosystem.
I also strongly enjoyed Daniel Ehrenberg 's recent tour of WebAssembly over time: When Is WebAssembly Going to Get DOM Support? Or, how I learned to stop worrying and love glue code.
Talking some of the technics of integrating with the web, and how component model might someday be a facility to make that reasonable, but how the browser folks are waiting to see how it goes server-side first, & might not be interested at all.
I don't really understand what limitations using reference types brings, how much glue code is left. I should try & compare some different language's toolchains, see what glue code each relies on!
https://queue.acm.org/detail.cfm?id=3746174
Regarding the submission here... Nothing but respect for Andy here. And yes finding fit is always so critical. But I do think we are on the cusp on much more, and I especially think the actual web, the front end, would/will be getting millions of miles more out of WebAssembly when async wasm components arrive.
> To answer these questions, we adopt an aesthetically unsatisfying device: the market. Which Wasm deployments have stuck around? Where are people happily using Wasm? Which deployments failed? These are all real indicators by people with skin in the game.
Right now it there are countless constraints on who can use wasm and how. To look at who has been trying today, who has had success today, it kind of ignores that wasm has become an increasingly niche harder to use server side only system. As the number of specs grows less and less runtimes are competitive. Shooting for the moon, but maybe, if async wasm components (wasi preview 3) ship and are good, it could radically expand the ball game.
For writing Visual Basic 6 on the web:
https://bandysc.github.io/AvaloniaVisualBasic6/
> TypeScript works better for Figma's needs, then, over time, new features will be written in TypeScript instead. Indeed, looking at the breakdown of Figma over time would seem to reveal that is what has occurred; Wasm is still used for some per-pixel operations, where its greater control over data layout makes it a win, but the application is composed of relatively more JS than Wasm...
>...if you are building an organization to create a web experience, generally speaking, you would rather pull from the deeper pool of JS developers than the more rarified C++/Wasm skill set
This is ultimately answering the reason why above, but it's important to point out the most critical parts of Figma and the reason Figma is worth what it is are the WASM/GPU accelerated parts which make all the interaction snappy and fluid, even the multiplayer stuff is downstream from this.
But also because it's a huge company now and a lot of the developers they hire could never create those critical parts of course the rest of it will bloat out as developers justify their existence.
At Restate.dev (workflow as a code engine) we use Rust/WASM to code-share the implementation of the durable execution protocol between the restate-server and the SDKs to develop workflows. This code is essentially a "pure" state machine: events in, events out, no side effects.
We use WASM in some cases:
* Our Typescript SDK uses wasm-bindgen to compile and release the Rust part of the code. We have chosen WASM over Node native extensions because we wanted to support deno, cloudflare workers, bun, and potentially other runtimes. We've stumbled on few issues related to packaging, but except that it was a smooth process.
* Our Golang SDK uses WaZero + manual bindings using protobuf's. It was a bit of a manual process to set it up, especially surrounding concurrency issues wrt accessing the WaZero runtime plus you need some wasm runtime pooling to get decent performance, but at the end it works well and reliably.
My lesson learned from our experience is that Rust is the real player here, because it delivers on the promise that you can develop libraries that can be easily embedded in high level languages. It's really "write once, bind everywhere".
WASM is just a "packaging"/"distribution" detail in our case, and we picked it just for lack of alternatives. For example in our Python SDK, we could have used WASM but we didn't, instead we went with PyO3 which is an amazingly well done Python -> native code bindgen, and it works without hassle for users as opposed to, for example, CGO in Golang. If Golang had a PyO3-like solution without CGO/any hassle for users, I would have taken it as opposed to doing the WASM bindings myself.
Plus, from what I've tried myself, the whole WASM experience is great only when used in combination with TS/wasm-bindgen, in the other scenarios it's a lot of manual tedious memory moving code involved. Maybe when WIT gets more broadly adopted, and there will be bindgens available in most languages/engines, this will be different.
If you wanna check out the projects and see how it works: https://github.com/restatedev/sdk-shared-core/, https://github.com/restatedev/sdk-go/ and https://github.com/restatedev/sdk-typescript/
Majority of my phone usage outside of reading HN is through dedicated apps. News, social media, chats and even substack. If I was building a product today, web would be quite low on the priority list outside of SEO capture.
I absolutely hate this state of affairs. Apps don't allow me to open multiple tabs, as an example.
Some do, MacOS has builtin support to add tabs to any application: https://support.apple.com/my-mm/guide/mac-help/mchla4695cce/...
But they do allow showing unblockable ads and notifications, so some 'people' absolutely love that state of affairs because they benefit from it.
I don’t know what the state is on Android, but on iOS (and macOS) unblockable notifications aren’t really a thing (notifications need permissions that you manage on a per-app basis) and many app ads can also be blocked (1Blocker does it), though it’s not as powerful because it’s essentially domain blocking.
I’m not disagreeing with you, merely providing more context. Companies like Reddit and Facebook definitely push you more to the apps so they can extract more value out of you.
What if you want to see some notifications but not others? But the developers are scammy and didn't separate ads into their own channel?
Then that’s a shitty company and perhaps you should consider not using their service anymore.
Either way I don’t see how that’s relevant to the point. It’s not like the web is any different in that regard.
> Then that’s a shitty company and perhaps you should consider not using their service anymore.
That's not always possible. There might not be enough quality competition and I don't see others following my example to beat the shitty company into submission and make them change their ways if I do that.
> Either way I don’t see how that’s relevant to the point. It’s not like the web is any different in that regard.
Web is very different in that regard. You can pry any app open and change basically anything with a single press of F12. Most of the time, people already did that for you and submitted an ad blocking filter for everyone to use. This isn't even close to the crapware of a typical app store.
Web is the last democratic platform we have left.
It used to be that cli tools were the power users preference but now I feel like that's shifted to web apps (over native). The ability to have multiple tabs/views, load extensions to customize behavior, adjust sizing, etc.
As an example: an absolutely vital tool for me is the Vimium keyboard control extension for navigation, which unfortunately can't be used in dedicated apps.
All the more reason to stand up against it and choose the web.
I'm wondering which of us is the outlier, because I heavily use browser apps on my phone and tablet and ignore vendors' prompts to install their native apps.
(Other than Google apps, that is.)
The problem with dedicated apps is that you often have to fight with the OS vendor for basic functionality in your app just to distribute it and these days you don't actually gain much with a dedicated app since modern sandboxing is so aggressive and web apis are relatively complete.
> you don’t actually gain much
Some of what you gain is pretty important though. For example, well written native apps integrate better with the platform’s accessibility features and they typically consume less power, storage, and memory.
I'd contest the storage point pretty strongly.
Well written web apps can be very accessible too and some companies do actually go out of their way to ensure this.
IMO as an end user - aggressive sandboxing is a feature, not a bug
A browser is a sandbox.
Browsers already do this much better. If you don't trust something that's where it belongs, not as a local app.
I’d suggest looking at some of the ideas from Wasm I/O
https://m.youtube.com/@wasmio
One talk seems to claim they have a tool that auto converts docker containers to wasm for huge efficiency gains
Another proposed faster OSes based on wasm’s safety promises
Ps: not claiming either of these will work just interest to consider
> Indeed, looking at the breakdown of Figma over time would seem to reveal that is what has occurred
Where can one look at that breakdown?
I hadn't really been interested in WebAssembly until I read about the component model and the fact that I can run Wasm components on the server.
That led me to wasmCloud[1]. As the article says, Wasm on the server isn't a winner yet, but it has a chance.
[1] https://wasmcloud.com
That seems... weirdly indirect, when you can run binaries directly on the server. If it's a VM or isolation you need, there's Docker. It feels just like "server-side rendering" of front-end UI libraries/frameworks like react and co. But maybe I'm missing something.
What I get is isolation, so I can run untrusted customer code as a Wasm component knowing it runs in a secure sandbox.
Also, scaling across clouds, edge, on-prem with minimal effort.
Another benefit I enjoy now is changing links between components at runtime. I can for example deploy v2.0.0 of a component and send traffic to it by simply updating a link - and reverse it should things break.
All that comes at a much lighter cost in terms of actual $, but also size (kilobytes/megabytes vs megabytes/gigabytes with Docker containers)
> they did not translate into massive adoption of Wasm by the gaming industry
This is more about monetization and less about technology, and nobody has figured out how to monetize web games beyond hyper-casual 2D games. And you don't need WASM to move a handful 2D sprites around.
Personally I'm quite happy what WASM allows me to do, e.g. the browser has become "just another runtime target" for my C/C++ hobby projects:
- https://floooh.github.io/sokol-html5/
- https://floooh.github.io/tiny8bit/
- https://floooh.github.io/doom-sokol/
...also the actual problem to run game-y stuff in browsers is not WASM, but the terrible state of web APIs, WebGL and WebGPU are both quite okay-ish, but beyond that it's an absolute mess (but OTH, people also cope with game development for Android, which is even worse).
I liked the convention of putting the TLD in parentheses after each link.
Browser-plugins are a better idea than web assembly. They should have just improved on that than introducing this crap into the core browser engine.
I'm interested in WASM for "plugin extensions" on embedded system, where (if?) it would guarantee me a kind of "sandboxed VM" experience, where I know that the resources for the plugins are limited, and that if it crashes, my own code is not affected.
I'm trying to use that through Rust on ESP32 with "wamr" but so far I've had quite a few compilation and runtime issues
if someone has some experience with that I'm interested :)
I've been building my entire back-end with WASM for several months now, and I can share some thoughts:
1. WASM on the Web: Just don't do it. It's not there yet. WASM actually has overhead compared to regular JavaScript, so it only makes sense for specific operations like video transformations. Otherwise, you're better off with a React stack. React isn't inherently slow—it just makes it easy to write slow code. Plus, most WASM frameworks (like Yew) are still immature with limited ecosystem support.
2. "Lightweight virtualization" sounds great in theory, but reality is different. The promise is "compile once, deploy everywhere," but if you can deploy everywhere, you probably can't deploy anywhere effectively. That's because once you remove networking, time and multi-threading, you are left with pretty much nothing. There is also a no consensus standard. There is WASI but it's a kind of a work-in-progress. Implementation will depend on your host.
I went with Cloudflare Workers, which meant learning their specific environment. The problem with these newer platforms is they don't have the documentation or community support you get with something like Linux. While Cloudflare runs workers on V8 at the edge (which helps), they have restrictions that you only discover as you go. For example, there's no "time" concept available inside a Cloudflare Worker's execution context.
3. Target support is genuinely terrible. Don't assume libraries will compile to wasm32-unknown-unknown—assume the opposite. Most libraries don't separate computational tasks from networking, and Rust's async ecosystem (Tokio) does not play well with WASM, breaking your code. I've had to fork two libraries and submit patches to several others. As a solo developer, this maintenance burden becomes expensive. Making libraries WASM-compatible could be a full-time job.
4. On Scalability: Just because you have a worker, doesn't translate to having "infinite" scalability. Here's the thing - as soon as your application does anything meaningful, you need state. Now your "infinitely scalable" architecture is only as scalable as your state (ie: RDS database) can handle. There isn't really a good server-less database offering and Databases are not the only thing that will bottleneck you here (ie: I have a keycloak server for signups).
> The aim is to build systems with the fine-grained interoperation of shared libraries, specified in a way to allow isolation but without requiring the overhead of an operating system process or a container.
Add time and networking to this mix, and you've basically described an operating system.
> For plug-in and extension use cases, Wasm can be a good option if the host needs isolation from the guest
This is actually WASM's sweet spot. These extensions run in the host environment (like Shopify), and WASM provides JavaScript-like capabilities with language choice and better isolation.
> The cloud Wasm space is a bit of a Wild West
It absolutely is—still in its infancy with little interest from major players to adopt this model.
In conclusion, I'm still torn on the whole thing. Some mornings I wake up to a broken build and wonder what the hell I was thinking. But then there are moments when everything clicks. My worker—27k lines that squeeze down to 3MB—feeling like a jet engine.
The constraints make you want to tear your hair out; but they make you think twice about everything. You can't just throw another dependency at a problem. You need to consider and weigh in any additional code. The worker model makes the request flow clearer and gives you a better understanding of your application life-cycle.
shamless plug (ps: it's nowhere near ready): https://codeinput.com
> WASM on the Web: Just don't do it. It's not there yet. WASM actually has overhead compared to regular JavaScript
That's really not what I'm seeing, my WASM home computer emulators (written in plain C) run at about the same performance as their native counterparts (give or take 15%). Just don't switch between the JS and WASM side too often, and use WebGL or WebGPU for rendering (with proper batching).
...of course if you want to have a DOM-based UI framework in WASM, don't do that, but who would come up with such a stupid idea in the first place ;)
It seems like Game UI is its own isolated world that doesn't tell you much about its suitability for regular apps. How often do games support or even need cut-and-paste?
If you really need a DOM based UI I would write a hybrid application, do the UI completely on the JS side via the DOM, and the logic on the WASM side, with a minimal interface to communicate between the two and which doesn't need tons of roundtrips each frame.
Games often need to do at least some DOM work though, like rendering a login dialog or integrating a 3rd party in-app-payment solution (or the obvious one: displaying ads). For this I would also do most work on the JS side.
With Emscripten, such mixed JS/WASM apps are really not that hard, you can even embed JS code snippets right into the C/C++ code.
> Wasm still has no shared-memory multithreading
Um, yes it does? Sure, you have to set some single-source or whatever flag in some header, but it works just fine - I've tested it myself.
>"Wasm works well where isolation is needed between different program parts written by different people."
Nailed it. We have JS in the browser, and (particularly with TS) it's a great language for building applications on the web. What's great about WASM is the interop layer we have now between other systems. Our company has a mountain of legacy C++, encoding many years of hard-won business logic, and the ability to tap into that on the frontend (locally, in-client) has been amazing. No more hacky transpilation or maintaining separate codebases; just write your FFI and compile the binary to WASM.
> We have JS in the browser, and (particularly with TS) it's a great language for building applications.
This is .. debateable. A large part of the push for WASM is people who believe that other languages should be allowed to exist in the browser.