Hacker News Reader

Comment by jlaban-uno | Hacker News Reader

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.

View on HN

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.

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?

“Please Update .NET to the latest version to access this website.”

Surely you know that sites are chasing milliseconds as it has enormous influence on conversion rates?

> 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.)

>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.

> 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.

Reply on news.ycombinator.com