4 ms·

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

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

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