Autodesk.

https://www.infoq.com/presentations/autocad-webassembly/

https://blogs.autodesk.com/autocad/autocad-web-app-google-io...

https://forge.autodesk.com/blog/load-encrypted-model-data-we...

BabylonJS plugins

https://babylonjs.medium.com/marker-tracking-in-babylon-js-c...

Blazor

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Uno

https://platform.uno/

The 90s called. They want their RAD tools back.

Hi 90s, this is 2020... OP can't take your call right now because they are busy building low-code environments to help companies keep their dozens of bootcamp hires productively building in-house line-of-business tools that will be a nightmare of maintenance and technical debt in 3 years.

Did you want to leave a message? Perhaps some kind of cautionary tale?

Let’s get them on the phone and negotiate a joint-custody deal, then, because I feel like RAD has only gone downhill since then.

Thinking back to how easy it is to open up VB5, drag-and-drop a UI, and ship an .exe that anyone could run (yes, because of MS’s OS monopoly, but still), the current mess required to build a similarly complex app for the web feels like a serious regression.

what about https://www.animaapp.com/ ?

Figma is written in C++, compiled to WebAssembly. Probably the most advanced web-based design tool in the world.

I think they have like 4-5M users, and a $2B valuation.

https://madewithwebassembly.com/showcase/figma/

Figma is an actual tool, written for the web. Lots of great engineering happening over there.

I know the Birth and death of JS gets mentioned quite a lot in WASM context (even as a joke) but I really don't see that being the case. Most web applications/sites are simple, and won't need to be compiled at a lower level in order to work. On average JS developers will be cheaper than C/C++/Rust developers to hire, so I don't see shops changing their personnel or stack anytime soon, especially if the job is to knock up a website that's a bit interactive.

It simply won't be viable to have low-level engineers do things like "build a dropdown nav" or "make an interactive carousel", and these sort of tasks will always be around.

WASM is there to augment JS in places JS isn't suitable for, rather than outright replace it. JS will definitely still exist.

To answer your Q there's also a comprehensive list of projects using Web Assembly on this site: https://madewithwebassembly.com/all-projects

The problem is that it's hard to use as a primary language because of a lack of direct Web API access. So basically right now it's not a casual decision to say "I prefer X over JS, so I'll just use that instead because it targets WASM!" Because there's this enormous cost of crossing that API barrier (which means you'll be using some JS regardless, directly or indirectly).

So for now the value-proposition only really makes sense for a fairly narrow subset of projects: mostly ones where client-side pure-compute is a bottleneck. Theoretically API access is being worked on, but I think it's still a ways out.

Direct access seems improbable and even undesirable. Libraries can be written and shared to expose what you want to the wasm you need to run.

Lots of people would like the web to become a language-agnostic platform. I don't hate JS the way some do, but even I'd be excited about that prospect. That can never really happen until WASM has direct API access.

That said, I tried just now to find where I read that this was on the long-term roadmap and I'm having trouble finding it. So maybe you're right that it isn't currently planned.

I'm also intrigued by the possibilities of WebAssembly. However I also have a nagging feeling "didn't we already do this with Java, 20 years ago?". Wondering what's different this time, or is this just a MySpace vs Facebook second-times-the-charm thing.

For one, no one needs to install WASM, nor are they going to run into versioning issues because the OS has a hard dependency on it. Every single person with a computer, from a smart phone to render farm workstations, will have WASM support because those devices will have a browser. The only browser that doesn't support it is the legacy IE line of browsers, of which only 11 is still supported, and which only runs on systems that will happily run Edge, instead.

Devs can rely on the fact that users won't need to install a single thing, and users can rely on the fact that they're not going to have to go through the insanity that is "trying to install the right version of Boobletech(tm) Meep(r)" or, hell: "trying to get their OS to even acknowledge that the preinstalled version of java is over a decade old and it needs to stop using it instead of the new version you installed".

If your compiler can target WebAssembly, and your users are on computers with operating systems that are still supported, your WASM application will work for them, because everyone has a browser.

Unless your user is using a iPhone.

Not unless your iphone is a hand-me-down from someone who themselves got it as a hand-me-down?

https://caniuse.com/?search=wasm

Safari has support for WebAssembly.

I’m not sure either. There are some technical differences. WASM is more low-level than JVM bytecode, which is important for some applications and makes it a more normal compiler target. It’s more integrated with the rest of the browser: it doesn’t come with its own rectangle like Flash and Java did, but instead manipulates the DOM just like (or at the moment, only through) JavaScript. And it’s a true open standard, not a corporate-controlled platform.

Do these differences really matter, or is it mostly just the timing?

WASM is definitely more low-level than JVM byte code right now... but I'm not sure it'll remain that way given the many proposals that are very likely to be implemented in the future (even though it's taking a long time for even simple ones, like multi-value returns, to get into the standard). For example, with WASI and GC, which will finally enable direct access to the DOM, how much lower-level will WASM be compared to JVM? Not much, I would say.

The big difference is that WASM, from the beginning, is supported by all the browsers natively (a consequence of it not being a proprietary technology, but an open standard), not as a plugin... If Java had started that way, the story would've turned out quite differently (but we know that at the time, the browser everyone was using was made by Microsoft, and Sun was a competitor so this would've never happened).

It starts immediately, while any embedded java applet took forever and looked really ugly. We've also done this with flash apps

The difference is that wasm is designed to be sandboxed, instead of the JVM which was designed to normalize disparate computing environments. In practice, this entails a lot of work to create runtimes to do anything interesting in wasm, but the behavior is secure by default (ignoring side-channel attacks, of course). Java applets run in a sandbox by default, of course, but the JRE itself has unmitigated access to the host system, so the security boundary isn't as well defined. Users can also be tricked to trust malicious applets, which is a built-in mechanism to escape the sandbox; browsers hopefully will not provide this feature for their wasm runtimes.

> the JRE itself has unmitigated access to the host system

As does the browser in which WebAssembly executes.

> Users can also be tricked to trust malicious applets

But the ability of applets to be trusted could have been eliminated entirely. To rewrite OP's question, then:

"If we had entirely gotten rid of trusted applets, couldn't we already do this with Java, 20 years ago?"

Of course, we didn't get rid of them, but that's still a valid question vs. inventing another technology.

Interesting thought experiment. However, you have to realize that Sun wasn’t a charity. At the time, platform vendors were were hoping to target intranet applications for the enterprise. Microsoft had a similar concept for trusted applications with IE’s “Active Scripting”, with very similar results in terms of (non)security.

Can't we just do this in sandboxed regular assembly running inside a virtual machine?!

/s

which assembly?

Ruffle - A Flash Player emulator over WebAssembly: https://github.com/ruffle-rs/ruffle

Shopify is using WASM in production [0]

[0] https://shopify.engineering/shopify-webassembly

We release a web-based ray tracer built with WASM that's integrated into our existing 3D/AR/VR platform: https://twitter.com/ksqio/status/1334962197324320768?s=20

Additional examples of WebAssembly being used at scale that I haven't seen others mention yet:

Microsoft - https://www.microsoft.com/en-us/garage/wall-of-fame/calc-ts-...

Adobe - https://medium.com/adobetech/acrobat-on-the-web-powered-by-w...

Fastly - https://www.fastly.com/blog/announcing-lucet-fastly-native-w...

Google Earth: https://earth.google.com/web/

Side note: Does anyone know why that video isn't on Youtube? I've tried to find it, but alas I can't. Copyright? Moral reasons? What?

https://www.youtube.com/results?search_query=gary+bernhardt+...

Twitch also appears to be using it, although I don't know what for.

Perspective is developed at JPMorgan https://github.com/finos/perspective/

There site which aggregate prod use cases: https://madewithwebassembly.com/

Unity, the very popular 3D game engine, can “export” games to run in the browser. WebAssembly is undoubtedly involved.

Google Duo's web client has some wasm code cached under the name 'wasm-clips'.