21–30 of 151 posts
Earlier quoted context omitted.
Does browsers support wasm with dynamic linking?
Yes.
This article is very correct: Wasm has a code size problem. This is a problem in browsers because all that code has to be downloaded to start the site. It's also a problem for serverless architectures, where code is often loaded from cold storage to a specific server on-demand while a client waits. Tree-shaking might help, but I feel like it's only an incremental optimization. Fundamentally the reason Wasm programs a…
That sounds a lot like the idea from some years past that commonly used JavaScript frameworks would be served from a few common CDNs and would be widely enough used to be almost always in cache in the browser, and therefore won't need to actually be downloaded for most pages (hence, the size of the js frameworks shouldn't matter so much)
I'm no expert but from what I understand, that didn't really work out very well. A combination of too many different versions of these libraries (so each individual version is actually not that widely used), and later privacy concerns that moved browsers toward partitioning cache by site or origin. Maybe other reasons too.
Of course, you didn't mention caching and perhaps that's not what you had in mind, but I think it's a tricky problem (a social problem more than a technical one): do you add baseline browser support for increasing numbers of language runtimes? That raises the bar for new browsers even further and anyway you'll never support all the libraries and runtimes people want. Do you let people bring their own and rely on caching? Then how do you avoid the problems previously encountered with caching JS libs?
As things go along, I’m more and more mystified by WASM’s apparent design. It feels like 1996 Java for applets, but without the built-in GC, stdlib, or even the most basic hooks into the browser. Which means it’s basically useless for what I assume its goal is, of letting you use languages other than JavaScript to code a web page. Without trivial DOM access, what’s the point? Other proposed usages like for FaaS-style…
But I thought WASM was to replace .NET and JAVA VM's. But, without a VM, to be more a pass through to the underlying CPU. So much faster. So compile down to a 'byte code' like thing, that does not run on a VM, but runs on the underlying HW.
So goal was speed.
And to allow other languages to compile to it.
Tree-shaking is such a bad misnomer. Virgil's compiler calls this "reachability analysis" and it's built into the compilation model. The compiler will parse and typecheck a program's (and libraries' code), and run initializers, but after that the compilation proceeds by exploring from the main entrypoint(s) and only reachable code is analyzed and ends in the final binary. It will happily generate a program (without r…
How so? There is lots of code (tree). Some of the code is not connected to the entry point (trunk). Tree shaking removes the disconnected parts (loose leaves, dead branches).
I agree that tiny binaries will open up new use cases for wasm! And WasmGC definitely helps.
As more context, Java and Kotlin can do fairly well there today, around 2-3 K:
https://developer.chrome.com/blog/wasmgc
https://twitter.com/bashorov/status/1661377260274720770
Though as Andy says, it depends which APIs you use - I am sure there are Java/Kotlin APIs that would pull in large amounts of code, so you do need to be careful there. But these languages are already doing a lot better than C++ and Rust on code size, thanks to WasmGC (no need to bundle several K of memory management code, in particular).
This article is very correct: Wasm has a code size problem. This is a problem in browsers because all that code has to be downloaded to start the site. It's also a problem for serverless architectures, where code is often loaded from cold storage to a specific server on-demand while a client waits. Tree-shaking might help, but I feel like it's only an incremental optimization. Fundamentally the reason Wasm programs a…
I think I agree overall, just want to point out that with Wasm, you still end up using a fair bit of the built-into-browser js to accomplish things not purely computational. Especially in this context with Hoot [1], where things like appendChild are external functions you call inside the scheme. One could theoretically do this for much of the js standard library in any kind of wasm context. 1. https://spritely.instit…
But browsers are understandably hesitant to create a whole parallel API surface designed specifically for Wasm callers. That's a lot of work.
I am not totally convinced that this is a real problem, vs. just something that makes people feel bad. Like, if you are coding Rust, the idea that all your "system calls" are calling into a layer of JavaScript feels disgusting. But is it a real problem? Most of these calls are probably not so performance sensitive that this FFI layer matters that much.
If it is a real problem, I'd guess the answer is for browsers to come up with a more efficient way to expose WebIDL-defined APIs to Wasm, but without reinventing any individual APIs. Being derived from WebIDL, they are still going to have JS idioms in their design, but maybe we can at least skip invoking actual JavaScript.
Earlier quoted context omitted.
Yes.
Do you happen to know where can I check out the cutoff version for each browser? https://caniuse.com/?search=wasm doesn't have it (or other things like WasmGC for that matter)
(But, language toolchains have to actually be designed to use this feature. Most aren't.)
Tree-shaking is such a bad misnomer. Virgil's compiler calls this "reachability analysis" and it's built into the compilation model. The compiler will parse and typecheck a program's (and libraries' code), and run initializers, but after that the compilation proceeds by exploring from the main entrypoint(s) and only reachable code is analyzed and ends in the final binary. It will happily generate a program (without r…
Personally, I think it’s an amazing name. The first time I saw the term, I knew exactly what it was without any further research.
You shake a tree to remove the loose things. In this case, it was clear that unused packages are being “shaken” from the tree.
Maybe off-topic. But can't you use WASM to create GUI's like Photoshop, with no JavaScript or DOM? Isn't the bigger goal of GUI's on WASM is we can jettison JavaScript/DOM and go back to writing GUI's like 10-20 years ago, with simpler libraries. Like SKIA, or something. Using non-web GUI libraries, since they could be compiled to WASM and run in web. EDIT: Native. I mean pre-web, when GUI libraries were native, ever…
At one point, there was a Host Bindings proposal that would enable you to do DOM manipulation (it looks like it was archived and moved to the Component Model spec [1]). That would probably be the ideal way to avoid as much JS as possible. However, browser vendors have been heavily optimizing their JS runtimes, and in some cases, Wasm may actually be slower than JS.
I've been following Wasm's progress for several years, which has been slow, but steady. Ironically, I think the web is actually the worst place to use it. There's so much cool non-web stuff being done with it and I'm more interested to see where that goes.
[1] https://github.com/WebAssembly/component-model?tab=readme-ov...
As things go along, I’m more and more mystified by WASM’s apparent design. It feels like 1996 Java for applets, but without the built-in GC, stdlib, or even the most basic hooks into the browser. Which means it’s basically useless for what I assume its goal is, of letting you use languages other than JavaScript to code a web page. Without trivial DOM access, what’s the point? Other proposed usages like for FaaS-style…
I might not be understanding. But I thought WASM was to replace .NET and JAVA VM's. But, without a VM, to be more a pass through to the underlying CPU. So much faster. So compile down to a 'byte code' like thing, that does not run on a VM, but runs on the underlying HW. So goal was speed. And to allow other languages to compile to it.
I think you may be confusing "system" virtual machines and "process" virtual machines. The VM here is the thing executing the WASM bytecode; it works the same was as .NET and JAVA VMs.