The interesting question is whether it's a good universal language runtime, and what kind of languages it's best for.
Today, WASM doesn't support GC, which means it's unlikely to be a good runtime for any language that wants to automatically manage memory and interact with the DOM (which needs to have its own GC).
Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Hell if we use one of those bytecode formats we could reuse the runtime too!
I'm sure there's probably 20+ bytecode formats and I'm rolling my eyes that we need yet another for the web....
None of those platforms' security models are as good as the web's, either, nor are their runtimes able to work well in that context.
This basically means that programming languages usually have to be specially designed for them. There's ironpython, but it's not fully compatible with python for instance.
LLVM IR is designed as a compiler IR and hardly useful for this usecase, as it is unstable, target-specific and has a complicated largely undocumented bitcode format (I don't know any reimplementations). It has been tried with PNaCl and the original SPIR, but both projects abandoned LLVM-IR/ were abandoned.
Because the major browser devs that designed WebAssembly are not smart enough to have thought this
/s
It sucked.
The reality is that WASM has to target the existing JavaScript backends in every popular browser. And now you can't use LLVM, because the backends in question typically only handle reducible control flow, etc. Conversion from LLVM to a form that your JavaScript backend supports is relatively expensive and not something you want to do on every load.
Is that really a problem considering most languages already implement a VM with GC?
That's true for now, but they're [planning][1] on adding support for that in the near future.
[1]: https://github.com/WebAssembly/design/blob/master/GC.md
If you want to get an idea of where GC is on the priorities list, have a look at the [roadmap][2]. There are still other things they have to deal with before they start working on GC support, but it's coming.
The difficulties for language developers are on two fronts really. #1 is producing WASM in a compiler backend, instead of LLVM IR / Java bytecode / bare machine code. #2 is getting the language small enough to be possible and not wasteful to implement in wasm. You don't have a filesystem, or really anything a regular OS provides, so you have to be able to strip those language / stdlib features away.
Rust is often cited as a go-to because it can already do #2 easily: #![no_std] strips out the os-dependendent standard library and essentially all of the already tiny stack-unwinding 'runtime'. #1 can be done with an LLVM backend, though it's still a bit of a hack and Rust would prefer to skip LLVM and that whole redundant optimisation phase entirely.
Most importantly, CLR and .NET are just too heavyweight for anyone to bother writing any wasm code in. What are the uses for wasm as it stands? There's basically no DOM interaction yet, so just really fast optimised code that has no OS interaction for crypto and other CPU-heavy tasks. You can't write a game targeting wasm, but you could outsource your ray-tracer there. Plain C++ and Rust are good at that. CLR/.NET is pretty quick when JITing x86 but wouldn't be worth the tremendous effort to port to wasm when you already have C++ and Rust, and they'd still be quicker in the end anyway.
Lastly there's the question of how to run a JIT at all within wasm. I don't think there is a way of creating executable memory regions (ie x86) within wasm, because wasm is independent of who's running it. You would have to instead generate executable wasm regions, which would need to be parsed again... all of which sounds fairly impossible too, as far as I know.
But is WASM set in stone already? I would have thought there would be a strong interest in seeing higher level languages made available through the browser. Are there fundamental reasons why WASM would never implement the features required to run a CLR (not necessarily a file system but for instance the threading model you mentioned).
The case for using c#/vb/java in WASM is I think strong.
First this would allow developers to write truly cross platform apps, using a lot less hacks than a solution like Xamarin.
The UI could be HTML but I would think that a CLR would ship with a version of WPF (think silverlight).
In a intranet/corporate environment, it would make the deployment of internal applications trivial.
You could have webapps with the same code base that run on mobile and desktop. The download time is not necessarily relevant. The code would be stored on the machine like any other webapp.
I think there is a reason why c#, python or java are so widely used over c++ outside of performance critical code. It is a lot easier, faster and safer to develop. I don't think c++ is a reasonable alternative to c# or java. As for rust, I don't have an opinion on its merit as I am not familiar enough with it, but its developer base is a small fraction of each of the vb/c#/java developer base.
If you tried to implement a new WASM backend for Roslyn or javac or something, it would be impossible simply because of how much the behaviour of these languages depends on their VM. Stuff like `synchronized` and introspection (esp in CLR managed classes / reflection APIs). You need the VM for that. Projects like Scala Native work because you still have an entire OS to work with on the target platforms.
You would have to implement very low level virtual-machine-like features in WASM to support something like that. And even if you did, the scope of WASM isn't big enough to support all the features of something like Silverlight running in it. I don't think they will ever support a graphics API you could do that in, for example.
At a higher level, trying to run a heavy framework on top of WASM is just silly. You already have a heavy framework, in the DOM and other browser APIs. They are essentially all you could possibly need to do anything useful in a browser. They are the only way to display anything to the user. You can't run an HTTP server inside WASM, but you wouldn't want to. You can't implement a custom interface technology in WASM, because you can't draw anything, but you can do all that with the DOM APIs or WebGL/canvas/etc so why would you want to? All these things you would need to hack together a Silverlight are already available, and your wasm would need to include an implementation of all of them. These are all things you kinda want to dynamically link against... which wasm doesn't support...
The focus for WASM (after it properly nails down the spec on a whole lot of basics) will be memory management and enabling access to GC'd JS objects. Then using JS APIs would follow. We're a long way off both of those, let alone providing VM-like features you could target a managed language at, or enough native-like APIs to allow building something like Silverlight on top of it.
I say we, but it's definitely not me working on this stuff, and it's not half the engineering talent from Microsoft either.
What I would really like to see is GC support in WASM. That would make it possible to AOT-compile managed languages like C#/Java to WASM. You wouldn't need to port the whole VM, "just" translate e.g. *.class-files to WASM which would seem a lot more feasible for the moment. That would sure only allow a subset of C#/Java, but since the web environment is distinct enough and the subset is large enough that would IMHO be acceptable.
The silver lining, is that many things usually get better the second time around. Let's see what WASM hold - it's pretty limited in its current form.
FTFY.
The second time around is usually so troubled by politics that there's an entire Wikipedia page about the topic of the second-version syndrome.
And WebASM is in every way inferior to Java still.
If the sandbox didn't have so many holes in it Java applets were arguably better for webapps than the unholy mess we've cobbled together over the last ten years to replace them.
It's sad to me that Java fell out of the browser and was replaced with a slow non standardized single threaded shit language for almost ten years just because Java didn't have DOM access.
JavaScript is just nearing Java feature parity and still not anywhere close for performance.
And I'll tell you what Java didn't have. A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems. God dammit what have we done.
Shakes cane at neighborhood kids
If Java were our only option I assure you we'd have come up with all kinds of crazy alternative systems of doing things.
Plus, targeting the JVM for weird transpiled language was what all of the cool kids did before doing it in JS became cool. This isn't unique to JS. It's probably unique to any language with that much adoption.
Pretty much. If Sun had made a decent plugin instead of expecting every browser to roll their own VM, and if AWT had been a lot less buggy, it could have worked.
A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems.
Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment.
It's not just JS: https://en.wikipedia.org/wiki/List_of_JVM_languages
Java ran pretty damn good for what it pulled off back then. It would have been orders of magnitude easier to make Java into what we have today than it was to bastardize HTML and JS to be usable.
Java these days uses native UI which looks nicer and is much faster than in-browser rending. Graceful degredation is only needed because some browsers are such crap. This was never a big problem in Java and still isn't. If a JVM supports JDK 8 you can expect it to run java 8 apps reliably
Java seems like a resource hog because it will use spare ram when you've got it, but most apps run fine on around 15mb of ram. Less if you use AOT compilation. Modern webapps use around 50-100.
> had weird clunky UIs that were out of place in the host OS and the browser
Just like web apps, the may be prettier, but they look just as out of plus with custom widgets everywhere and complete disregard for the desktop theme. Hell, for some reason chrome added that shitty task bar color attribute that allows a web page to alter the desktop (well mobile top) theme.
So, Java wasn't ahead of its time, and it was much much worse than Flash (which, despite numerous efforts to kill it, is still alive, unlike Java Applets which have essentially been dead for years).
Too be fair though, it's a hard comparison, applets were generally apps while flash was fancy graphics.
My memory from the mid/late nineties is that Microsoft wanted to balkanise Java with J++ (or was it J# ?) and got into a big argument with Sun, and because of this and the fact they eventually came to own the browser market there was no way they'd embed a JVM in the browser.
Java is slow on the first run (even if you admit it is just the JVM running your already compiled code). Try running a different java code in every site and you will understand why JS is prefered to it.
Also JS has a foot in functional programming and is much less verbose, it also has evolved to be even leaner. e.g. The current lambda syntax (fat arrows) is a treat
I wanted to point out, however, that Java 8/9 has excellent support for basic functional programming features, with an equally-nice syntax for lambdas, but with a good type system (via Functional interfaces) to boot.
The thing that I get hung up time and again, with ES6/7, is lack of a type system. We write some complex ES6/7 + Immutable JS apps (e.g. in the financial services domain), and haven't managed to extract full value from Flow or TypeScript just yet, due to library constraints etc.
I would like to look into the Java functional approach. Is there any reference you recommend ?
I've always been deeply into it, and using it for years at work, so no good off-hand reference. I'd be picking one as random as any web search that you'd perform, sorry!
I should never have learnt Haskell. It messes with your mind [1] whenever you write in any other programming language, yet you can hardly ever use it in practice. Well, certainly here in South Africa.
[1] Obligatory link: http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441...
It is amazing the amount of stuff that JS does if you don't follow the trends blindly and think a bit about your usage and tools.
Webasm still can't manipulate the DOM, so it's still not very useful as a replacement for JS, but it is planned. To really replace JS though, we'd need webasm to support garbage-collected languages for ease of use. Probably, some dynamically typed languages as well.
Well... see https://en.wikipedia.org/wiki/NPAPI#LiveConnect
Now it's true that it involved more hoops, especially for someone who just knew Java but not DOM bits, so implementing a GUI using Swing or whatever was a path of least resistance. But it wasn't the only path.
> Webasm still can't manipulate the DOM
Not directly, but via FFI to JS it can.... Pretty similar to LiveConnect in some ways.