5 ms·

That would be a question for the Edge and .NET team, but unfortunately that does not seem to be an option. The IL Linker (tree shaking) is removing unused parts

That would be a question for the Edge and .NET team, but unfortunately that does not seem to be an option. The IL Linker (tree shaking) is removing unused parts of the binaries for the purpose of removing very large portions of code in the final binary. If binaries were to be bundled, or CDN hosted, we'd end up downloading extremely large unnecessary portions of code. Yet, this simple fact that a WebAssembly app needs to download everything its needing to run puts it at disadvantage with Javascript (you download a browser with all the base libraries only once, and that's not lightweight). For now, WebAssembly apps (in general and not just .NET ones) are more similar to mobile apps than websites, just because of this significant difference.

greggman3 6y ago
Just call into the browser to do any of those APIs and the problem is solved. The problem is you're taking your C# / .NET libraries for which solution already exist in the browser instead of building APIs around what already exists in the browser. To put it another way, instead of starting with wrapped native apis and doing wasm last. Start with browser apis and make native ports of those, then you'll get something that works well in the browser and (95% of the time IMO) will work fine in your native version as well.
lukevp 6y ago
Why don’t we push for first class wasm precaching in browsers? Right now wasm libs are limited in interop with JS and DOM. Could we have a .net/JVM like language-agnostic wasm standard lib bundled with all browsers, and target it like we do with .net standard? Then app makers could target a .wasm standard release and if the browser didn’t support it, polyfill in at app start the missing features?
- Spivak 6y ago
  “Please Update .NET to the latest version to access this website.”
  - emteycz 6y ago
    Surely you know that sites are chasing milliseconds as it has enormous influence on conversion rates?
- JoshTriplett 6y ago
  > Right now wasm libs are limited in interop with JS and DOM. Could we have a .net/JVM like language-agnostic wasm standard lib bundled with all browsers, and target it like we do with .net standard? There's already a plan to give WebAssembly direct access to DOM, and to any other API JavaScript would have access to, without needing a JavaScript shim. (This requires integration between WebAssembly and the JavaScript garbage collector, which is part of why it's taking time to develop.)
- ComodoHacker 6y ago
  >language-agnostic wasm standard lib Can such a thing even exist? I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
  - rictic 6y ago
    > Can such a thing even exist? Yes, cross-language code sharing is being worked on. > I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions. How would a site know what libraries are available? How would versioning work? This is a caching problem, best solved at the normal browser resource cache level IMO.

greggman3 6y ago

Just call into the browser to do any of those APIs and the problem is solved. The problem is you're taking your C# / .NET libraries for which solution already exist in the browser instead of building APIs around what already exists in the browser. To put it another way, instead of starting with wrapped native apis and doing wasm last. Start with browser apis and make native ports of those, then you'll get something that works well in the browser and (95% of the time IMO) will work fine in your native version as well.

lukevp 6y ago

Why don’t we push for first class wasm precaching in browsers? Right now wasm libs are limited in interop with JS and DOM. Could we have a .net/JVM like language-agnostic wasm standard lib bundled with all browsers, and target it like we do with .net standard? Then app makers could target a .wasm standard release and if the browser didn’t support it, polyfill in at app start the missing features?

Spivak 6y ago
“Please Update .NET to the latest version to access this website.”
- emteycz 6y ago
  Surely you know that sites are chasing milliseconds as it has enormous influence on conversion rates?
JoshTriplett 6y ago
> Right now wasm libs are limited in interop with JS and DOM. Could we have a .net/JVM like language-agnostic wasm standard lib bundled with all browsers, and target it like we do with .net standard? There's already a plan to give WebAssembly direct access to DOM, and to any other API JavaScript would have access to, without needing a JavaScript shim. (This requires integration between WebAssembly and the JavaScript garbage collector, which is part of why it's taking time to develop.)
ComodoHacker 6y ago
>language-agnostic wasm standard lib Can such a thing even exist? I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
- rictic 6y ago
  > Can such a thing even exist? Yes, cross-language code sharing is being worked on. > I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions. How would a site know what libraries are available? How would versioning work? This is a caching problem, best solved at the normal browser resource cache level IMO.