Comment by cm2187 | Hacker News Reader

Comment by cm2187 | Hacker News Reader

Parent Full thread

Thanks for this detailed answer.

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.

WASM isn't set in stone, in fact it is constantly evolving. But I doubt it will ever really let you do JIT compilation. WASM itself can be JIT compiled if you want to implement it that way, but executing memory just doesn't seem feasible given that the security model simply has to forbid executing machine code directly. I don't think the JIT>WASM>JIT again is the best way to go about things.

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.

JIT-Support is listed as a possible future feature for WASM: http://webassembly.org/docs/future-features/. Why shouldn't a WASM program not be able to generate WASM bytecode at runtime? The runtime-generated bytecode can be verified and then compiled by the WASM compiler, just like it is done for AOT-generated WASM bytecode. That said, I am not sure if WASM should support jitting. But if there is demand for it, then it will probably get done.

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.

Also JIT isn't necessary. You could have platform specific compilations. The important part is to have the same code base.

Reply on news.ycombinator.com