The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved.

The difference in perf without glue is crazy. But not surprising at all. This is one of the things I almost always warn people about, because it's such a glaring foot gun when trying to do cool stuff with WASM.

The thing with components that might be addressed (maybe I missed it) is how we'd avoid introducing new complexity with them. Looking through the various examples of implementing them with different languages, I get a little spooked by how messy I can see this becoming. Given that these are early days and there's no clearly defined standard, I guess it's fair that things aren't tightened up yet.

The go example (https://component-model.bytecodealliance.org/language-suppor...) is kind of insane once you generate the files. For the consumer the experience should be better, but as a component developer, I'd hope the tooling and outputs were eventually far easier to reason about. And this is a happy path, without any kind of DOM glue or interaction with Web APIs. How complex will that get?

I suppose I could sum up the concern as shifting complexity rather than eliminating it.

▲

eqrion 2 days ago | parent | next [-]

I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.

▲

davexunit 2 days ago | parent | next [-]

I am excited by the prospect of booting Wasm binaries without any JS glue, but when I've looked at the documentation for the component model and WIT it says that resources are references passed using a borrow checking model. That would be a serious downgrade compared to the GC-managed reference passing I can do today with Wasm GC. Do you know if there are any plans to resolve this mismatch?

	▲	bloppe 9 hours ago \| parent [-]
		Relevant: https://github.com/WebAssembly/component-model/issues/525 In my experience people are often disappointed by the shared-nothing architecture of the component model. I guess that shared-nothing architecture makes it impossible to properly share GC objects across component boundaries. But they can still be shared across core module boundaries.

▲

elestor 17 hours ago | parent | prev | next [-]

What do you mean by churn in this context?

▲

j45 2 days ago | parent | prev [-]

The tooling has been in it's early days for a long time. As quickly as that can improve, so will the uptake. The technology itself is quite capable.

▲

NohatCoder 17 hours ago | parent | prev [-]

The whole WASM thing just went sideways from the start. It feels like the property of being practically unreadable and unwritable for humans was a design criterium, it is certainly the primary "feature" enabled by the stack approach.

Then there is the single array of memory that makes modern memory allocators not really work, resulting in every WASM compiler scrounging up something that mashes the assumptions of the source language into a single array.