crypto VS component-model

From my recent experience with WebAssembly developing a cryptographic library for Nodejs and the browser [1], I have to say that once someone needs to use memory allocation, typed arrays from JS to WASM (I did not manage to make the opposite work) etc. it quickly becomes obvious that there is lack of documentation and build system fragmentation that only hurts community growth IMO. If I was less motivated to finish the undertaking, I would just give up and go with libsodium-wrappers or tweetnacljs.

I started with clang targeting wasm32-unknown-unknown-wasm as my build system but this just did not work with malloc/free, unless I was targeting WASI, but if I targeted WASI I would not be able to run the module in the browser except with a polyfill that was hard to set up with C/TS stack. I ended up with emscripten because it was importing the module with all the right helper functions but there I was getting memory errors on debug mode but not in production. I needed to pass the Uint8Arrays from JS to WASM in a very specific way (with HEAP8), otherwise the pointers were not working properly, but I was not able to find this in the documentation. I only found out from a stackoverflow comment somewhere after two weeks of brain melting (why would Uint8Array(memory.buffer, offset, len).byteOffset not work?).

After I compiled the project successfully and the JS was giving the correct results, I decided to compile with -s SINGLE_FILE command in order to make the package as portable as possible, but this increased the size significantly because it translates the bytes into base64 that are then converted into WASM module from JS. A package manager of a compiled language that outputs cross-env JS that solves these problems automagically would be, IMO again, a game changer for the ecosystem. I believe this is what AssemblyScript tries to achieve but I honestly could not make it work for my project after experimenting with it for one or two days.

I get that a lot of the problems come from the incompatibility of browser and Nodejs APIs and different agendas from the various stakeholders, but I would very much like to see these differences be reconciled so that we can have a good developer experience for cross-platform WASM modules, which will lead to more high-performance components for JS, which is a programming language that affects so many people.

[1] https://github.com/deliberative/crypto

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