4 ms·

Your OS is multithreaded, JavaScript isn't. Scrolling in your browser is bad enough when JS/dom has to many allocations.

by pknopf 8y ago

GiorgioG 8y ago
What does WebAssembly have to do with JS? WebAssembly support for multithreading is in progress https://github.com/WebAssembly/design/issues/1073 https://github.com/WebAssembly/design/issues/1073 Look, you want to poo-poo on WebAssembly, that's fine, but the folks who build these browsers don't seem to be concerned enough about having GC'd langs running on their platform. Who has more at stake - you or them?
- pknopf 8y ago
  WebAssembly (currently) doesn't have direct access to DOM, so it has to use JS, hence the GC. Here is some of the JS for Blazor: https://github.com/aspnet/Blazor/tree/master/src/Microsoft.AspNetCore.Blazor.Browser.JS https://github.com/aspnet/Blazor/tree/master/src/Microsoft.A...
- pknopf 8y ago
  Also, even when WebAssembly gets proper threading, .NET/Mono still uses a "suspend the world" GC mode which will still halt your execution. Nobody is poo-poo'ing anything. It is what it is. .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical. I expect Rust to lead the way here.
  - GiorgioG 8y ago
    > .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical. I guess I don't understand what kind of 'high-scale applications where performance is critical' wouldn't be suitable for .NET but instead better suited to a systems programming language like Rust. If the bottleneck becomes the single-threaded JS interop, then what difference does it make which WASM language/runtime you choose as long as it's at least as fast as JS?
    - pknopf 8y ago
      Rust has no GC, .NET has a GC. Rust will be delivered with no runtime (minimal deployed size), Blazor will need the entire mono runtime and BCL.
      - GiorgioG 8y ago
        It won't require everything to be downloaded - https://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/ https://www.mono-project.com/news/2018/01/16/mono-static-web... Will it ever be as small as a systems language like Rust or C? No - never. But the productivity gains that C# & the .NET framework provide are a worthwhile tradeoff for 99% applications. The .NET team is actively working to optimize the payload to a manageable size. You haven't specified what evidence you're basing this statement on: > ".NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical." Because Javascript is a good fit? Facebook sends down 500k+ of JS and how many of their billion+ customers complain about it?

Your OS is multithreaded, JavaScript isn't. Scrolling in your browser is bad enough when JS/dom has to many allocations.

by pknopf 8y ago

Your OS is multithreaded, JavaScript isn't. Scrolling in your browser is bad enough when JS/dom has to many allocations.

GiorgioG 8y ago

What does WebAssembly have to do with JS? WebAssembly support for multithreading is in progress https://github.com/WebAssembly/design/issues/1073 https://github.com/WebAssembly/design/issues/1073 Look, you want to poo-poo on WebAssembly, that's fine, but the folks who build these browsers don't seem to be concerned enough about having GC'd langs running on their platform. Who has more at stake - you or them?

pknopf 8y ago
WebAssembly (currently) doesn't have direct access to DOM, so it has to use JS, hence the GC. Here is some of the JS for Blazor: https://github.com/aspnet/Blazor/tree/master/src/Microsoft.AspNetCore.Blazor.Browser.JS https://github.com/aspnet/Blazor/tree/master/src/Microsoft.A...
pknopf 8y ago
Also, even when WebAssembly gets proper threading, .NET/Mono still uses a "suspend the world" GC mode which will still halt your execution. Nobody is poo-poo'ing anything. It is what it is. .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical. I expect Rust to lead the way here.
- GiorgioG 8y ago
  > .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical. I guess I don't understand what kind of 'high-scale applications where performance is critical' wouldn't be suitable for .NET but instead better suited to a systems programming language like Rust. If the bottleneck becomes the single-threaded JS interop, then what difference does it make which WASM language/runtime you choose as long as it's at least as fast as JS?
  - pknopf 8y ago
    Rust has no GC, .NET has a GC. Rust will be delivered with no runtime (minimal deployed size), Blazor will need the entire mono runtime and BCL.
    - GiorgioG 8y ago
      It won't require everything to be downloaded - https://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/ https://www.mono-project.com/news/2018/01/16/mono-static-web... Will it ever be as small as a systems language like Rust or C? No - never. But the productivity gains that C# & the .NET framework provide are a worthwhile tradeoff for 99% applications. The .NET team is actively working to optimize the payload to a manageable size. You haven't specified what evidence you're basing this statement on: > ".NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical." Because Javascript is a good fit? Facebook sends down 500k+ of JS and how many of their billion+ customers complain about it?