Hacker News Reader

Comment by yougane | Hacker News Reader

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.

View on HN

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

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.

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

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

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.

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

Reply on news.ycombinator.com