FYI, AssemblyScript is a TypeScript variant targeted to WASM. If someone would ask why you want to use another JS to use WASM, it is not a scripting language. AssemblyScript produces WASM binaries with minial runtimes so its WASM binary size is very small, even smaller than C outputs (with Emscripten) most of times.
So if you want to write a low-level WASM code in WebAssembly text format (WAT), it is probably a good idea to use AssemblyScript instead.
So we're on our way to finish the re-creation of Java, by unifying the JavaScript and foreign code into a single bytecode format.
Honestly I'm all for it, and wouldn't change much since most JavaScript written today goes through compilation anyway (TypeScript and/or Babel). Only executing bytecode and taking out JavaScript parsers/interpreters would simplify browser implementations too. Just... what a roundabout trip it has been.
I suppose it is, but Java applets never took off because they were horrible. Half the time they wouldn't work, and when they did they never felt like they were part of a page, and generally felt bloated and slow. Much more like a bad version of Flash than something that felt like part of a page.
I seem to remember that they eventually fixed the problem with slow startup for applets but it was long after people had stopped using them.
Let’s not forget that when applets were a thing Java was a proprietary, although liberally licensed, from Sun Microsystems and the only JVM available was though them. I don’t even know what the status of it is to this day even though there are far more options than there were then.
I didn’t touch Java for years because it was risky to invest time and energy into a language were the owner, Sun and now Oracle, could just yank it or start charging for the JDK at any time. It only became safe when it was successful enough that it became unlikely that thy would do something like that and there started to be viable alternatives. It’s easy to forget that Java had a huge cloud over its head foe many years.
There are plenty of languages other than this AssemblyScript that compile to Webassembly whereas only Java code compiled to Java bytecode. It's no more another Java than another C or Lua or any other language that just happens compiles to a binary or bytecode.
There are far more languages that compile to Java bytecode then to javascript or Webassembly and it has been a thing for far longer. The Java virtual machine has a good jit-compiler(at least for java but often for other languages too) and a good garbage collector. It offers access to many useful libraries especially for desktop guis so its long been a target. Most popular languages targeting java include groovy, scala, clojure, Kotlin. Also Jruby is a fairly popular alternative ruby implementation on top of the JVM
You're probably thinking of something like cpythons bytecode which is unstable internal only thing (breaking compatibility with minor python versions). Java bytecode has to be stable since it had to be shared by multiple jvm implementations. And even then a famous ruby hacker made a ruby-to-python-bytecode-compiler(now probably broken by version changes).
Not only syntax, but also standard library, ecosystem and etc. You could easily transpile AssemblyScript project to JavaScript via tsc if use portable glue code. From C it I guess it borrows AOT compilation, ability to use low-level intrinsics and more granular and sound types. Btw many people still thought AS has manual memory management, but it's not true. By default it use hybrid ARC and GC approach called PureRC:
https://github.com/dcodeIO/purerc/blob/master/papers/Bacon03...
You can easily transpile any C-syntax subset into C, if you use the right libraries. Same with Python, or Java, or MIT Scratch, or any other language I can think of.
This looks great. I’ve been playing a lot with WASM lately (working on a tiny frontend MP4/H264 encoder[1]) and using huge programming tool chains like C/C++ or Rust is not that appealing for building small WASM/web-centric modules. AssemblyScript on the other hand seems very web-first.
I'm curious how this works in terms of interoperability with Javascript but I couldn't understand that from reading their website. Does anyone here know how the interop works, by any chance?
* Can JS functions call Assemblyscript functions?
* Can AssemblyScript functions call JS functions?
* Can Assemblyscript manipulate Javascript objects? Or is the communication restricted to low-level types such as integers, WASM byte arrays, and so forth?
Thanks, but the WASM ecosystem is a bit foreign to me so some of what you said went right over my head. Would it be correct to say that:
1. AssemblyScript functions can be exposed to Javascript via the loader utility. If the arguments are primitive types then calling them is straightforward. Complex types like strings and arrays must be converted between the JS version of the type and the AS version of the type.
2. AssemblyScript code cannot call Javascript functions or directly manipulate Javascript objects. However, Javascript objects and functions can be passed around as an opaque anyref.
Opaque anyref (externref) or reference-types WebAssembly proposal not yet in all browsers, but after it interop will become much easier. At least you don't need glue code for JS side any more.
I've been trying to use the AssemblyScript compiler in a Rust project compiled with MSVC. So far, my best solution is calling QuickJS[0] on the command line. Is there any obvious solution I'm missing? Perhaps NectarJS[1]?
Just a small education platform that'll likely never see the light of day. AssemblyScript is a simple enough language that non-programmers should be able to use and understand it, and it compiles to WASM (which runs sandboxed) so it's reasonably safe to throw around. I'm using it to describe the educational resources (basically, interactive / generalised flashcards).
I guess AssemblyScript isn't self-hosted (yet)? Seems like your life might be easier if you could compile the compiler to WASM.
Would a JavaScript interpreter be too slow for your use case? I can find a few of those written in Rust (e.g. https://github.com/boa-dev/boa), although some look abandoned and others seem incomplete.
A JavaScript interpreter would be brilliant, but I can't find a complete one written in Rust. NectarJS (mentioned upstream) seems to compile to WASM (by embedding a JavaScript runtime environment), so I'll probably use that for prototyping.
Can someone explain why I would want Web Assembly versus just writing in another language?
Serious question: I feel like I am missing the use case for something like this - is it primarily useful for multi-tenant scenarios where you want to sandbox the workload or ??
Webasm is something you compile to, not write in. It can be run in a web browser at near native speeds. I don't understand the rest of your question or what your question marks allude to.
It's great if you're already using TypeScript for the server and browser (non-WebAssembly) parts of your system. That way you can harmoniously share some of the same code and data structures.
It can be used when you just want native, low-level WASM features. It is often better when you don't want complex WASM interoperability interfaces of other languages. This help your code keep clean.
Its minimal runtime can be run outside of browser easily. Even Rust requires complex interfaces, requires big runtime binaries to run on WASM, and it sometimes is not portable that it can run only on browsers.
> It's not quite a subset, not quite a superset, but rather a variant.
So it sounds like it's not aligned-enough to take advantage of TS's expansive ecosystem? It's more just "a high-level language designed for WASM, with syntactic decisions familiar to people who know TS but which don't actually make it compatible". That's a much less compelling proposition
TS seems like a great choice syntactically for WASM because it’s familiar to developers who are writing WASM, ie frontend programmers. Compared to rust WASM, this seems to be much better for on boarding.
However, because it’s not actually compiling to JavaScript like typescript is normally, this means there must be quirks and differences that must be understood to solve harder problems. Depending on how friendly the compiler is, this can be very painful or intuitive.
I’m guessing it’s infeasible to compile TS to WASM since they’re targeting very different outputs - a ahead of time, dynamic weakly typed scripting language can’t possibly be compatible with an ahead of time, strongly typed, binary output.
And if someone tells you it is, I suspect they’re doing a lot of magic that’s hiding problems that only become obvious after writing nontrivial programs.
I think the developer base still remains to be seen. As long as WebAssembly doesn't provide significant speedups over tuned JS, it seems likely we'll continue to mostly see it used for porting code from platforms and languages that don't natively target the web.
On Firefix and Safari we have the same missing optimizations. Basically wasm in all browsers reuse the same codegen from JS. But this will improved in the future.
Also, don't forget about SIMD, multi-threading with stared buffers and atomics and multi-values, a lot of special instructions like popcnt, ctz, clz, rotl/rotr and etc which not supported by JS and usually emulate not in the best way that complicates or make impossible to optimize this by the JS compiler.
In some points JS is really fast, so much that it is not inferior, for example, to the C language with the LLVM compiler without vectorization (-O2). Obviously
WebAssembly can't outperform JS in such cases.
AssemblyScript is a great idea, and has some excellent people working on it. I posted about this earlier, and Aaron Turner replied. His "wasmboy" Gameboy emulator is a perfect example of just what AssemblyScript is good for, and he gave an interesting talk about it too.
>AssemblyScript compiles strictly typed TypeScript (basically JavaScript with types) to WebAssembly using Binaryen. It generates lean and mean WebAssembly modules while being just an npm install away.
Since you can compile AssemblyScript into JavaScript with the TypeScript compiler as well as into WebAssembly, you can compare the speed of JavaScript -vs- WebAssembly on the same source code. Aaron did some interesting benchmarks using wasmboy, in the great tradition of using GameBoy emulators to benchmark JavaScript engines:
A function that calculates Fibonacci is used as an example. Just a reminder that if you want to calculate the nth Fibonacci number you can use Binet's formula.
This is a temporary limitation which mean you can't capture free vars from outer scope (except global scope). One of the main goal of AS is performance but closure elimination required some extra efforts like Middle IR, eta/beta-reductions, lambda lifting / dropping. Without all of this closures will produce significant overhead. So at first need to implement all this things
So if you want to write a low-level WASM code in WebAssembly text format (WAT), it is probably a good idea to use AssemblyScript instead.