Why aren't we standardizing on something like Java bytecode or LLVM IR or CLR?
What problems with those existing technologies could wasm solve better?
What problems with those existing technologies could wasm solve better?
What is WebAssembly going to be used for that isn't already handled well by Javascript? High-end video games is an important example. Those are almost exclusively written in C++. Lots of indie games are written in C# using Unity, but the Unity runtime library itself is C++.
So why not LLVM? The LLVM isn't actually well-defined, stable, or even platform-independent. That hasn't stopped both Google and Apple trying to use it for this kind of thing (PNaCl and Bitcode respectively). PNaCl failed to catch on, Bitcode is helped by the fact that Apple has complete control over their own platform.
Edit to add: from a game developer's point of view, a good question is why we need both this and the new "SPIR-V" thing in Vulkan...!
The return of Silverlight! (which I welcome by the way)
Also, there's this passage from the CLR docs (a.k.a. Book of the Runtime) that explicitly states its multi-language intentions[1].
[1] https://github.com/dotnet/coreclr/blob/master/Documentation/...
It seems like alternate languages on the CLR have never really caught on, even though in principle it's more flexible than the JVM. The only ones you hear much about are C# and F#. Compare to the JVM where you have Java, Scala, Clojure, Kotlin.
And neither the CLR nor JVM seems to have caught on for low-level, performance-critical code (game engines, scientific programming, deep learning). I guess people feel the garbage collection and bounds checking add too much overhead.
So the new fashionable approach seems to be portable machine code, very close to the way real hardware behaves. If you want bounds checking and garbage collection, do it yourself.
In a different domain from games, there were some very interesting apps I've seen that were very low-level, performance-critical written for the IoT before IoT was a term space in the old Micro-CLR.
I still of the opinion that a lot of the reason people don't use CLR/JVM and other runtimes more for low-level/performance-critical code has a lot less to do with "overhead" of garbage collection/bounds checking (whether it is as bad as critics often perceive it to be is another debate), and as much to do with stubbornness and job protection ("Of course my C and Assembly skills are still needed, because the CLR will never compete with my hand unrolled loops that are nearly impossible to debug and segfault the machine sometimes, which you should pay me to fix.").
MS managed to take their own excellent technology and turn it into a legacy nightmare. Am I targeting C#, the CLR, the CLI, or making a PCL, or what? Which PCL profile(s)? It's way worse than Java in that respect and Java's already pretty bad (not that anyone uses J2ME much any more).
The WASM FAQ has an entry about LLVM IR: https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
Web developers have been reinventing the wheel every 3-6 months and calling it innovation.
Apparently they aren't cool anymore so we need to spend another few thousand man years building another system in their image
They also, as you note in another comment, do not have the appropriate security model for web apps.
.NET 1.x introduced Managed C++.
.NET 2.0 replaced Managed C++ with C++/CLI due to feedback from C++ devs, regarding keywords and how GC types were declared. C++/CLI was submitted to ANSI C++ as standard proposal.
UWP introduced C++/CX, although it does compile to native code and interoperates with .NET Native instead.
Or Flash for that matter, which had a C++ compiler called FlasCC.
C++/CX is closer, but a) also still not the same language and b) doesn't run on the CLR, so isn't an argument for replacing wasm with IL.
WASM is assembly level just sandboxed and portable - direct memory access and basic instructions - it doesn't even have GC right now.
They are only superficially similar.
Providing a lower-level platform; directly exposing open web APIs. The first may not seem like an advantage, but it means more flexibility in the higher level systems (including runtimes like JVM or CLR, if you wanted to) that can be usefully run on top of it.
Maybe if we had a JS framework for reinventing the wheel...
Anyways you should take a look, it's a lot easier to pick up than RollCircle and nobody really uses Wheel.js anymore
npm elipse.js
It's based on circle, but I'm still working out some issues.