4 ms·

It's great to see WASM taking off! In this context, see also Blazor, which runs C#/.NET code on WASM. https://github.com/aspnet/blazor https://github.com/aspn

by m_st 8y ago

It's great to see WASM taking off! In this context, see also Blazor, which runs C#/.NET code on WASM. https://github.com/aspnet/blazor https://github.com/aspnet/blazor

steveklabnik 8y ago
What’s the binary size like? One interesting thing about wasm is the difference between libraries and apps; Rust’s small binary size here can make it useful for this infrastructure work, but for languages that need to bring along the runtime, it’s much more complex. This is one reason why we’re pursuing stuff like wasm-pack. I’m glad to see more and more languages compiling to wasm though! Exciting times.
- wvenable 8y ago
  The original Blazer was based on the DotNetAnywhere runtime and the binary size was actually very reasonable. Now that they're using the Mono runtime it's significantly larger and it seems their main task now is finding ways to remove unused code from that runtime to get it back to reasonable.
  - deleted 8y ago
    [deleted]
  - yougane 8y ago
    The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used side-by-side with other languages.
    - Dayshine 8y ago
      >The original runtime was about 60kb in size, that's still unreasonable to add to a library What? What kind of bubble are you working in?
      - deleted 8y ago
        [deleted]
      - yougane 8y ago
        Web applications nowadays depend on hundreds of dependencies. If each one of these dependencies were to have a size of 60kb or more that would be very bad.
    - coldtea 8y ago
      >The original runtime was about 60kb in size, that's still unreasonable to add to a library. In which planet? Not only will most frameworks and standard JS libs dwarf this, but the average web page size has upped to ~ 3MB these days...
      - yougane 8y ago
        >Not only will most frameworks and standard JS libs dwarf this The original runtime that was used by Blazor was already a compact .NET runtime, and no matter how much you minify it (or any other runtime, such as the JVM), it will always have a considerable size. >the average web page size has upped to ~ 3MB these days... This is not an excuse to make web pages' sizes even larger :). Btw, I'm not against the idea of using a managed language that targets WebAssembly for front-end development. On the contrary, I'm very excited about Blazor and I'm following its development, and I would love to see similar frameworks for other languages such as Kotlin or Swift. But while I think the size of a runtime won't be an issue for web applications that use such frameworks, I don't like the idea of shipping large runtimes with wasm packages that might be used with other languages.
        wvenable 8y ago
        There is an idea that the runtime could be hosted from a common CDN and then cached by the browser across applications so you only have to download the runtime once. Combined with browsers caching the compiled versions of the wasm modules, the cost of the large runtime might be pretty minimal in practice.
        Klathmon 8y ago
        That was tried and failed already with JavaScript libraries. Look at something like jQuery. Let's assume for the sake of discussion there are 50 versions of jQuery (that's a low estimate), and 6 majorly used CDNs. That's 300 distinct cachable items. Now add in that most people now use multiple devices, and that caches are generally completely full and evicting things constantly. The chances of having a specific version from a specific CDN on the specific device is actually pretty low. Now multiply that whole thing by another 100 libraries that all want to be the next jQuery. It's just not going to happen. And cross-domain or content based caching isn't a solution either as it's opens an extremely large security hole (basically being able to probe your cache checking if a specific hash or content exists in it). I'd much rather spend our collective time improving dead code removal tools and optimizing tightly linked bundles of libraries to give each web application it's own customized, small, optimized, and easily cachable "bundle". It avoids the reliance on 3rd party CDNs, it gives control over caching behavior back to the original website, it improves security, and can be faster (both in download speed and runtime speed).
- kodablah 8y ago
  > What’s the binary size like? I asked this same question[0]. Appears mono.js is 166kb in release mode, but it downloads/uses the DLLs directly as a system would, so those sizes are the same as they are for desktop apps (not sure off the top of my head what that is for ASP.Net stuff or the stdlib). 0 - https://github.com/mono/mono/issues/7820 https://github.com/mono/mono/issues/7820
  - steveklabnik 8y ago
    Ah nice, thank you! The recent work with emscripten to get sizes down will help them too, I’m sure.
kodablah 8y ago
It should be noted, I believe this is currently more of an interpreter than AOT-compiled like LLVM bitcode is. Mono is compiled via WASM that then interprets CIL DLLs.

by m_st 8y ago

It's great to see WASM taking off! In this context, see also Blazor, which runs C#/.NET code on WASM. https://github.com/aspnet/blazor https://github.com/aspnet/blazor

steveklabnik 8y ago

What’s the binary size like? One interesting thing about wasm is the difference between libraries and apps; Rust’s small binary size here can make it useful for this infrastructure work, but for languages that need to bring along the runtime, it’s much more complex. This is one reason why we’re pursuing stuff like wasm-pack. I’m glad to see more and more languages compiling to wasm though! Exciting times.

wvenable 8y ago
The original Blazer was based on the DotNetAnywhere runtime and the binary size was actually very reasonable. Now that they're using the Mono runtime it's significantly larger and it seems their main task now is finding ways to remove unused code from that runtime to get it back to reasonable.
- deleted 8y ago
  [deleted]
- yougane 8y ago
  The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used side-by-side with other languages.
  - Dayshine 8y ago
    >The original runtime was about 60kb in size, that's still unreasonable to add to a library What? What kind of bubble are you working in?
    - deleted 8y ago
      [deleted]
    - yougane 8y ago
      Web applications nowadays depend on hundreds of dependencies. If each one of these dependencies were to have a size of 60kb or more that would be very bad.
  - coldtea 8y ago
    >The original runtime was about 60kb in size, that's still unreasonable to add to a library. In which planet? Not only will most frameworks and standard JS libs dwarf this, but the average web page size has upped to ~ 3MB these days...
    - yougane 8y ago
      >Not only will most frameworks and standard JS libs dwarf this The original runtime that was used by Blazor was already a compact .NET runtime, and no matter how much you minify it (or any other runtime, such as the JVM), it will always have a considerable size. >the average web page size has upped to ~ 3MB these days... This is not an excuse to make web pages' sizes even larger :). Btw, I'm not against the idea of using a managed language that targets WebAssembly for front-end development. On the contrary, I'm very excited about Blazor and I'm following its development, and I would love to see similar frameworks for other languages such as Kotlin or Swift. But while I think the size of a runtime won't be an issue for web applications that use such frameworks, I don't like the idea of shipping large runtimes with wasm packages that might be used with other languages.
      - wvenable 8y ago
        There is an idea that the runtime could be hosted from a common CDN and then cached by the browser across applications so you only have to download the runtime once. Combined with browsers caching the compiled versions of the wasm modules, the cost of the large runtime might be pretty minimal in practice.
        Klathmon 8y ago
        That was tried and failed already with JavaScript libraries. Look at something like jQuery. Let's assume for the sake of discussion there are 50 versions of jQuery (that's a low estimate), and 6 majorly used CDNs. That's 300 distinct cachable items. Now add in that most people now use multiple devices, and that caches are generally completely full and evicting things constantly. The chances of having a specific version from a specific CDN on the specific device is actually pretty low. Now multiply that whole thing by another 100 libraries that all want to be the next jQuery. It's just not going to happen. And cross-domain or content based caching isn't a solution either as it's opens an extremely large security hole (basically being able to probe your cache checking if a specific hash or content exists in it). I'd much rather spend our collective time improving dead code removal tools and optimizing tightly linked bundles of libraries to give each web application it's own customized, small, optimized, and easily cachable "bundle". It avoids the reliance on 3rd party CDNs, it gives control over caching behavior back to the original website, it improves security, and can be faster (both in download speed and runtime speed).
kodablah 8y ago
> What’s the binary size like? I asked this same question[0]. Appears mono.js is 166kb in release mode, but it downloads/uses the DLLs directly as a system would, so those sizes are the same as they are for desktop apps (not sure off the top of my head what that is for ASP.Net stuff or the stdlib). 0 - https://github.com/mono/mono/issues/7820 https://github.com/mono/mono/issues/7820
- steveklabnik 8y ago
  Ah nice, thank you! The recent work with emscripten to get sizes down will help them too, I’m sure.

kodablah 8y ago

It should be noted, I believe this is currently more of an interpreter than AOT-compiled like LLVM bitcode is. Mono is compiled via WASM that then interprets CIL DLLs.