I don't think that will be feasible in the near future, because in order to run another language in the browser (say, Python) through wasm, you will need to bundle the entire runtime with your app, which is an unacceptable amount of overhead for most apps.
I don't think anyone is suggesting that people do this. The idea is to save time by compiling JavaScript ahead of time and shipping the results of the compilation, which I think I understand to be a binary version of an AST.
IIRC one of the bigger reasons behind wasm is to cut out the parsing time for JS (which is currently a pretty big bottleneck to startup time and memory, especially on mobile devices)
How would you draw the line on which languages/runtimes deserve to get bundled/cached? You could make the same argument for JavaScript libraries—shouldn't web browsers just bundle jQuery?—but there's ultimately no good way to do that.
I feel like this shouldn't be the end of the world. If everyone uses the same CDN for a given language's runtime (with subresource-integrity to ensure security), even a 1MB download should be... tolerable. Not great, but tolerable. Load time is also an issue, but WebAssembly is designed to greatly improve initial load time compared to asm.js.
That has been tried and failed with JavaScript libraries in the past.
Even if you can get everyone to agree on one canonical CDN (you can't), you also need to get everyone to agree on one version of the file at the CDN.
Plus cache sizes on most platforms are laughably small (a heavy page can completely blow out your cache on mobile devices).
IIRCthere was a "study" while back that found by using the most common CDN at the time to host jQuery, you only got like a 5% cache hit rate. This was because of multiple CDNs, multiple versions, multiple ways to reference the version (1.2.3 vs 'latest'), and http/HTTPS.
In my past experience, we had more trouble with people blocking our CDN via corporate networks or something.
One of the problems with JS is the unbelievable amount of churn. It's not uncommon to see libraries have version half-lives in the days or weeks.
The firewall issue is always going to be a problem on corporate networks. I don't think we're ever realistically going to get away from having to self-serve dependencies if you want to ensure that things are going to work, particularly if it's software that is deployed in on-premise, internal servers.
But this isn't a js churn problem. Even if updates only happen every 6 weeks, that means that unless the majority of devs update their links every 6 weeks the distribution of links out there will be spread out enough to be nearly worthless.
And while updates every 6 weeks might seem crazy to you, unless we just don't version the links (which seems like a terrible idea), even simple bugfxes blow the whole system.
Plus CDN hosted systems come with a bunch of other downsides. Lack of http2 pushing, tree shaking and bundling doesn't work, being able to compile with your own settings, and more.
CDNs aren't the solution here, something like using service worker and/or an "install" process for web apps will solve all of these and more.
I wonder why browsers don't use subresource integrity to share cached items across origins. Maybe they do? If hash collisions is a problem, they could limit it to certain hash algorithms.
IIRC there has been a little bit of work in this area, but there are a lot of downsides.
First of all, it's dangerous because you could "probe" the user's cache cross-domain by offering files with a specific checksum and seeing if they take it or not. Letting evil-example.com figure out if you have visited pornhub recently by offering up their javascript file with the subresource hash attached and seeing if you download it is a massive privacy violation and can cause issues much worse than just knowing you were on pornhub.
Second, Cache sizes are already too small, and while a content-addressable-cache might help with that a bit, it won't really change all that much. You'll still have 100 versions of jquery out in the wild at any time, you'll still have 10,000 different versions of react bundled with other things. You'll still have the version with a UTF-8 BOM and one without, or one with \n and one with \r\n.
Finally, (and this one is just my opinion) it's a solution that encourages worse behavior. It's going to be easier to include that 300kb of jquery when you think that your users will have it cached already. And that just "loosens the belt" around an area where we should be cutting back. Now users that are arriving for the first time will get a significantly worse experience, and that is the starting to go against a fundamental strength of the web, that you can get the same experience on any device, anywhere, any time, whether it's your computer, your cousin's desktop, your friend's phone, or your damn car. Making devices that don't have that in their cache download a massive "basically binary" blob before they can use it is against what the web is, and content-based caching really encourages the behavior of including entire libraries (so they'll be cached) instead of compiling down only the code you need.
While most of this can be mitigated, this just isn't something that's sorely needed. There is an MDN document floating around somewhere that they were talking about something like this, but I can't seem to find it right now.
I'm currently working on a large-ish code based designed primarily to run via Emscripten. Current optimized .js size is 3MB. While the WASM size is noticeably smaller <2MB, startup time is actually worse due to browsers compiling everything ahead of time.
> startup time is actually worse due to browsers compiling everything ahead of time.
On an upside, with WASM browsers can potentially save a snapshot of the compiled code to speed up re-runs. I recall the idea was promoted back when Dart was expecting to get its own VM, and one of the things that it would be capable of was this snapshot using.
