9 ms·

WebAssembly is not a universal language runtime. Currently it really only handles C style Ahead-Of-Time compiled languages. e.g. if you wanted to implement a JS

WebAssembly is not a universal language runtime. Currently it really only handles C style Ahead-Of-Time compiled languages. e.g. if you wanted to implement a JS JIT or really any other kind of JIT on top of WebAssembly you're going to have a really bad time.

cm2187 10y ago
What's the problem with running a CLR within webassembly?
- jeswin 10y ago
  I don't think it has GC at the moment. It might be alright if the GC doesn't show up for a few years; languages like Rust can demonstrate bare-metal, stutter-free performance on the Web.
  - cm2187 10y ago
    But wouldn't the CLR run its own GC?
    - cormacrelf 10y ago
      You'd have to compile the CLR itself into wasm first, which I'm guessing wouldn't necessarily run that well. Language runtimes often provide stuff like os-independent threading or green threads, which have to be implemented all over again for wasm's threading model (I'm not sure it even exists yet). Some CLR features would be redundant, like the security model or the profiling API... and then you'd need to compile your C#/VB/F# down to managed CLR code without using the .NET Framework at all, since so much of .NET depends on having stuff wasm can't provide (not even .NET Core has few enough features to run on wasm). Either you make '.NET Core Core Web Edition Preview 3' and make library developers explicitly target this new framework subset so you can use it, or you just give up and recognise that without most of .NET it's not that worthwhile having C# in the browser. 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.
      - cm2187 10y ago
        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.
        cormacrelf 10y ago
        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.

cm2187 10y ago

What's the problem with running a CLR within webassembly?

jeswin 10y ago
I don't think it has GC at the moment. It might be alright if the GC doesn't show up for a few years; languages like Rust can demonstrate bare-metal, stutter-free performance on the Web.
- cm2187 10y ago
  But wouldn't the CLR run its own GC?
  - cormacrelf 10y ago
    You'd have to compile the CLR itself into wasm first, which I'm guessing wouldn't necessarily run that well. Language runtimes often provide stuff like os-independent threading or green threads, which have to be implemented all over again for wasm's threading model (I'm not sure it even exists yet). Some CLR features would be redundant, like the security model or the profiling API... and then you'd need to compile your C#/VB/F# down to managed CLR code without using the .NET Framework at all, since so much of .NET depends on having stuff wasm can't provide (not even .NET Core has few enough features to run on wasm). Either you make '.NET Core Core Web Edition Preview 3' and make library developers explicitly target this new framework subset so you can use it, or you just give up and recognise that without most of .NET it's not that worthwhile having C# in the browser. 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.
    - cm2187 10y ago
      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.
      - cormacrelf 10y ago
        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.