wizer VS component-model

> once by the wasm runtime to compile the rust-python wasm

I'm not sure what you mean by that. The runtime doesn't compile WASM, it simply executes it.

There are tools for dealing with interpreter runtime overhead this by pre-initalizing the environment like Wizer[0]. ComponentizeJS[1] uses it to pre-initialize the Spidermoney engine it packages to gain fast startup times (and you can then prune the initialization only code with wasm-opt). As techniques like ComponentizeJS are also being applied for a specific set of interpreted files, you can even prune parts of the interpreter that would never be used for that specific program. If you want to go even further you could record specific execution profiles and optimize further by those.

[0]: https://github.com/bytecodealliance/wizer

[1]: https://github.com/bytecodealliance/ComponentizeJS

Edge functions are typically run intermittently, with their runtime stopped to free up resources between runs. Therefore a big factor is startup and shutdown speed. Containers are pretty bad there. Deno is better, and WASM is unbeatable, especially with things like Wizer[0].

[0]https://github.com/bytecodealliance/wizer

I imagine startup cost could be amortized by something like wizer: https://github.com/bytecodealliance/wizer

There are security benefits to running each request in its own instance, as it helps prevent accidental leaking of state between requests. To avoid doing lots of expensive initializations, we have a tool called wizer which lets users run their program's initialization once, create a snapshot, and then use that snapshot to do fast startups that don't rerun the whole initialization each time.

See https://github.com/bytecodealliance/wizer for an implementation of this approach.

It should probably be named "Making JavaScript to startup fast on WebAssembly", since the runtime speed is not really improved by the approach they exposed.

Besides that I think Wizer [1] is both an elegant and a simple solution to speed up startup speed with Wasm.

[1] - https://github.com/bytecodealliance/wizer#using-wizer-as-a-l...

A similar project, for WebAssembly so with limited scope is this: https://github.com/bytecodealliance/wizer. And somehow similar but limited on LLVM IR a colleague worked on this for Cheerp (the compiler used here as backend): https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-PreExecuter.

I don't think that's a very good goal. Jettisoning the DOM means jettisoning accessibility and being able to leverage everything that the browser gives you out-of-the-box. You have to render to a canvas and build everything from scratch. I think Wasm is great for supplementing a JS app, not replacing it (e.g. using a Wasm module to do some calculations in a Worker). I like to use the right tool for the job, and trying to use something other than JS to build a web app just seems a little janky to me.

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

Well the great thing about WebAssembly is that you can port QT or anything else to be at a layer below -- thanks to WebAssembly Interface Types[0] and the Component Model specification that works underneath that.

To over-simplify, the Component Model manages language interop, and WIT constrains the boundaries with interfaces.

IMO the problem here is defining a 90% solution for most window, tab, button, etc management, then building embeddings in QT, Flutter/Skia, and other lower level engines. Getting a good cross-platform way of doing data passing, triggering re-renders, serializing window state is probably the meat of the interesting work.

On top of that, you really need great UX. This is normally where projects fall short -- why should I use this solution instead of something like Tauri[2] which is excellent or Electron?

[0]: https://github.com/WebAssembly/component-model/blob/main/des...

[1]: https://github.com/WebAssembly/component-model/blob/main/des...

[2]: https://tauri.app/

While I don't necessarily agree with the unnecessary, unsupported casual, & cheap contempt culture here ("unshackle the web from the mess that is JavaScript", "places that don't really need these problems to be solved")...

WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements.

Long running effort, but it's hard work and there's just not that many hands available for this deep work. Some assorted links with more: https://github.com/WebAssembly/component-model https://www.fermyon.com/blog/webassembly-component-model https://thenewstack.io/can-webassembly-get-its-act-together-...

It's just hard work, it's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.

A. Sure, but it isn't sufficiently beneficial for the cost.

B. WebAssembly is immature for developing a plugin system because of the lack of a sufficient ABI: https://github.com/WebAssembly/component-model

C. There aren't any other languages that meet the criteria. Lua was a no-go from the start. The maintainers did not like the language, and it necessitated adding more C code to Helix which could complicate building even further. https://github.com/helix-editor/helix/discussions/3806#discu...

AFAIK GC is irrelevant for "direct DOM access", you would rather want to hop into the following rabbit hole:

- reference types: https://github.com/WebAssembly/reference-types/blob/master/p...

- interface types (inactive): https://github.com/WebAssembly/interface-types/blob/main/pro...

- component model: https://github.com/WebAssembly/component-model

If this looks like a mess, that's because it is. Compared to that, the current solution to go through a Javascript shim doesn't look too bad IMHO.

The wasm idl (called WIT) is actively being worked on here: https://github.com/WebAssembly/component-model/blob/main/des...

Being able to access DOM is definitely an objective. It's just taking a lot longer than folks guessed to build a modular wasm ABI.

The WASM Component Model

https://github.com/WebAssembly/component-model

Take a look at the python abi to see what the structure looks like for calling into components https://github.com/WebAssembly/component-model/tree/main/design/mvp/canonical-abi