Yes, but that's the point, if the user has it installed by default then there won't be much of a penalty if a website chooses to use another language than JavaScript.
Right now, WASM interpreters only really make sense for teaching and exposition with REPLs, where the user probably won't mind large downloads in order to do something out of the ordinary. Shipping interpreters would instead make that ordinary.
It's still a big penalty, you're just changing who pays the penalty, when they pay the penalty, how often they pay the penalty.
Personally, I'm pretty happy that we have WASM at all, and I think there's a lot of work we can do (over the next years) to make interpreters that work well in WASM.
For comparison, pulled up a computer that's running Windows and has Edge installed (which will be indicative of a large part of the population that doesn't care much about the intricacies of their installs):
Edge: almost 500 MB
EdgeCore: almost 400 MB
EdgeUpdate: about 20 MB
In the grand scheme of things, 20 MB is indeed nothing, because many browsers out there (that cannot be uninstalled without crippling the OS in some regards) are already pretty bloated, use bunches of plugins anyways and just generally have untold amounts of cruft in a variety of other software (e.g. just compare MS Office vs LibreOffice and look at how much space professional software like Photoshop or Blender or whatever takes up).
What i'd like:
- to optionally be able to maximize the browser size install to minimize the amount of data that would have to be fetched over the network (e.g. one bundle for Python, one for .NET/Blazor, one for Rust, one for Go etc., based on what you need, maybe just all of them), the same way that plugins work
- to have these bundles support being toggled (or even downloaded, if allowed) on a case by case basis, as they become necessary (e.g. enabled in daily driver device, disabled and not installed in a Firefox/Chrome/... install inside of a Docker container for testing)
- somehow have the industry force everyone to slow down - e.g. you'd have new updates for all of these come out perhaps once a month instead of every other day, as you already do with front end plugins and needless updates of JS bundles
- so, since CDNs were crippled and browser caching is impossible for common resources across different sites, re-introduce that mechanism in some capacity with these bundles that'd be installed locally
- enjoy the ensuing hell that'd be like the Java Applet idea which was brilliant for rich content but had untold flaws in regards to sandboxing and other things (similarly to how Flash was later also killed off, really torn about that one)
So obviously we cannot win and will never have that.
Alternatively:
- build more static sites
- realize that you can't implement everything you need without JS
- reinvent your own minimalist framework/library, badly; though hopefully use something like Svelte or Alpine.js for cases like that
What we'll realistically have instead:
- unique bundles of resources for every site, no caching across sites, no proper ways to utilize CDNs in a cross-domain context due to fears of being spied on
- fast development velocity with lots of updates, continuation of needing to download hundreds of KB or even multiple MB of JS assets to keep browsing the same content in almost the same way
- the problem will only be made worse by developers pursuing larger WASM bundles, like Blazor in .NET, with few advantages for developers but many disadvantages for everyone else
- this problem generally will not be regarded as serious, because most don't care about how much bandwidth they waste, a la Wirth's law
> it's just that now you're redownloading it every time your browser updates
There's no reason browsers couldn't have a persistent cache for this. Think of it more as an integrated dependency manager and VM that just happens to use web infrastructure. No one would blink at downloading 20MB of dependencies anywhere else, after all.
If you're downloading it on-demand and caching it, why would it need to be integrated in the browser at all? Why not just stick it in a CDN and treat it like a regular file, the way it works right now?
Different origins don't share a cache anymore. A Google Font on one origin doesn't benefit from it being cached after it's used on another origin.
The browser handling this as a special feature by default avoids cache isolation issues. It also makes it trivial to avoid leaning on even more third parties (CDNs, package managers) to run your code: as long as your browser is supported, code won't stop working in it.
And yet whenever this comes up, someone always insists that you'd have to re-download the entire runtime with every request, as if caching wasn't a thing.
As far as shipping vs caching goes, I see no reason not to do both. Maybe ship with the latest version of a few popular languages including javascript already pre-cached and allow for downloading others as required. I don't know what would be more optimal. Maybe when you download a browser, you can select language support options.
My point is, this is just an implementation detail, it doesn't have to be awkward or inefficient.
