Assembly script is pretty interesting as a language. It's close enough to type script that the transition from that should be relatively easy for people already using that. And performance wise it gets them a lot of benefits.
There are a lot of other languages coming to wasm. It looks like garbage collection is stabilizing. E.g. jetbrains released an experimental wasm compiler for Kotlin recently that uses that. Currently that only works if you launch Chrome with some experimental flags to enable the feature. But at some point that will be generally available there, and in other browsers.
So, whether you are using C#, Kotlin, Swift, Crystal, or any other garbage collected modern language, chances are there will be a wasm compiler for it soon (if not already) and rich ecosystem of libraries and tools. I see this as a matter of time. Right now it's all a bit cutting edge. So, the whole space is dominated by languages not in need of garbage collection (C, C++, Rust, etc). However, that will change pretty soon.
E.g. Swift and Kotlin are already used for modern UI development on mobile. Using those languages in a browser makes total sense. Kotlin actually has a js transpiler and there are some Kotlin specific web frameworks that I've used. With wasm and the inevitable emergence of new UI frameworks targeting wasm and browsers, there might be a little renaissance in web ui development. Things like Figma prove that web uis don't have to be laggy, limited, and driven by css & dom trees.
Why would you need that hardware support? It's not like javascript interpreters need any hardware acceleration for garbage collection. Relative to javascript, wasm with GC is going to be the same or faster.
Runtime size can be an issue; though arguably WASM is going to outperform minified javascript probably for the same code.
Typical SPAs only manage to stay small by simply not using a lot of run-time dependencies. The same trick will work with wasm. If you don't need it, don't depend on it. Simple. Or alternatively, trade off not having to reinvent the wheel against a few MB of dependencies. In an age where people watch 4K youtube videos, pulling in a few MB is not that big of a deal anymore.
And incidentally, the lack of any sizable run-time dependencies also makes replacing those not that big of a deal. E.g. most of the React ecosystem involves a lot of compile time dependencies (hundreds of MB typically) but not a whole lot of run-time dependencies that people actually ship with their applications. A few hundred kilo bytes typically. I've used alternatives for React that only measured a few thousand lines of code. There's not a whole lot that those run-time libraries actually do that is that essential.
I've noticed with Kotlin js that there isn't a whole lot that I need or miss. Actually, even just having the Kotlin standard library is already a big upgrade relative to what browsers and Javascript have without any dependencies added. Add co-routines to the mix and few other multi platform libraries (e.g. kotlinx.serialization, kotlinx.datetime, ktor client) and it starts feeling like any other modern Kotlin stack that I've worked with. Except it all works in a browser. Is there a size penalty. Yes. Does it matter that much. Not really.
> And performance wise it gets them a lot of benefits.
I am not convinced about that for two reasons:
1. Good money has been invested into making JS fast. If you look at actual benchmarks it is currently quite easy to end up in a situation were your WASM-based solutions might perform WORSE. So at least for now the performance advantages are not that great to begin with.
2. On the frontend, you still need JS to use the DOM. Getting data back and forth from JS to WASM can become a bottleneck. Plus rare processing speed is rarely an issue on the frontend and IO-bound stuff is something JS is already good at.
If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support. (Edit: If you are after performance mainly and don't care about sandboxing and other advantages.)
Yes, if you need to do some image processing on the frontend or want your users to mine crypto for you, yes WASM has already uses but generally I am a bit skeptical.
Now WASM is awesome for getting you the C/C++/Rust world in the browser, sure. The performance improvements might be overrated though considering the additional development costs compared to just using JS.
(That was more a dig at the WASM hype in general, of course. Not meant to throw any specific shade at AssemblyScript. Still an interesting project regardless.)
1. While true, in practice what I have tested it is that the performance is very, very rarely worse (although often it is negligible difference). The thing is wasm performance is predictable. This is really important for graphics and games since there is no JIT going on, JS (and python, ruby, etc) performance can vary widely based on how often a codepath is used
2. This is planned to change with Interface Types which will let you call any DOM method from any wasm code without without custom bindings and performance hit as well as, for example, calling a python module from golang for example (as long as both are compiled to wasm)
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support.
the main point of wasm outside of browsers is sandboxing and compatibility, a whole set of applications become possible when you have that. A simple example are SaaS application that let users upload wasm plugins that run on the SaaS application servers
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support.
wasm is just one part of the puzzle, the other one is WASI which is poised to become a standard interface for OS interaction. With it you could conceivably have a single binary for any OS+processor architecture (as long as there is wasm runtime + the parts of WASI required by your app implemented). This is huge for embedded development, I myself spent insane amounts of time trying to get shit compiled to different OS+architecture
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support.
- Cross-compiling is perhaps easier these days, but it's still a pain to set up and takes time to compile
- WASM has compelling sandboxing abilities, I can see myself choosing a slower sandboxed client tool vs native binary, in particular to try out new stuff
There are a lot of other languages coming to wasm. It looks like garbage collection is stabilizing. E.g. jetbrains released an experimental wasm compiler for Kotlin recently that uses that. Currently that only works if you launch Chrome with some experimental flags to enable the feature. But at some point that will be generally available there, and in other browsers.
So, whether you are using C#, Kotlin, Swift, Crystal, or any other garbage collected modern language, chances are there will be a wasm compiler for it soon (if not already) and rich ecosystem of libraries and tools. I see this as a matter of time. Right now it's all a bit cutting edge. So, the whole space is dominated by languages not in need of garbage collection (C, C++, Rust, etc). However, that will change pretty soon.
E.g. Swift and Kotlin are already used for modern UI development on mobile. Using those languages in a browser makes total sense. Kotlin actually has a js transpiler and there are some Kotlin specific web frameworks that I've used. With wasm and the inevitable emergence of new UI frameworks targeting wasm and browsers, there might be a little renaissance in web ui development. Things like Figma prove that web uis don't have to be laggy, limited, and driven by css & dom trees.