[flohofwoe]

> Including much better dev-ex, which is not great as you can see in the OP.

IMHO the developer experience should be provided by compiler toolchains like Emscripten or the Rust compiler, and by their (standard) libraries. E.g. keep the complexity out of the browser, the right place for binding-layer complexity is the toolchains and at compile time. The browser is already complex enough as it is and should be radically stripped down instead instead of throwing more stuff onto the pile.

Web APIs are designed from the ground up for Javascript, and no amount of 'hidden magic' can change that. The component model just moves the binding shim to a place inside the browser where it isn't accessible, so it will be even harder to investigate and fix performance problems.

[bloppe]

The dev-ex issues largely occur at the boundaries between environments. In the browser, that's often a JS-Rust boundary or a JS-C++ boundary. On embedded runtimes, it could be a Go-Rust boundary, or a Zig-Python boundary. To bridge every possible X-Y boundary for N different environments, you need N^2 different glue systems.

You're probably already thinking "obviously we just need a hub-and-spoke architecture where there's a common intermediate representation for all these types". That kind of architecture means that each environment only has to worry about conversions to and from the common representation, then you can connect any environment to any other environment, and you only need 2N glue systems instead of N^2. Effectively, you'd be formalizing the prior system of bespoke glue code generation into a standardized interface for interoperation.

That's the component model.

[flohofwoe]

> "obviously we just need a hub-and-spoke architecture where there's a common intermediate representation for all these types"

I'm perfectly happy with integers and floats as common interface types (native ABIs also only use integers and floats: pointers are integer-indices into memory, and struct offsets need to be implicitly known and compiled into the caller and callee).

The WASM Component Model looks like a throwback to the 1990s when component object models where all the rage (COM, CORBA, and whatnot).

[bloppe]

> I'm perfectly happy with integers and floats as common interface types

Most people at least want strings too. And once you add strings, you need to make sure the format is correct (JS uses UTF-16, C uses NULL-termination, etc). So even if you don't allow a complex object model, you would still need N^2 glue systems just for strings.

Then you might as well add arrays too.

Before you know it, you end up with the component model.

[flohofwoe]

...all way too high level for my taste and those problems are not WASM specific yet still have been solved outside WASM via operating-system/platform ABI conventions which compilers and 'user code' has to adhere to without requiring a 'component model'.

Some operating systems might want their strings as UTF-8 encoded, some as UTF-16. It's the job of the caller to provide the strings in the right format before calling the OS function. In the end it's up to the caller and callee to agree on a format for string data. There is no 'middleman' or canonical standard format needed, just an agreement between a specific caller and callee.

The good and important part of such an agreement is that it is unopinionated. As long as caller and callee agree, it's totally fine to pass zero-terminated bytes, other callers and callees might find a pointer/size pair better. This sort of agreement also needs to happen when calling between native Rust and C code (or calling between any language for that matter). My C code might even prefer to receive string data as pointer/size pairs instead of zero-terminated bytes when all my string-processing code is built on top of strings as pointer/size pairs (e.g. apart from string literals there is not a single feature in the C language which dictates that strings are zero-terminated bags of bytes - it's mostly just of convention of the ancient C stdlib functions).

IMHO the WASM Component Model is solving a problem that just isn't all that relevant in practice. System ABIs / calling conventions don't need a 'component model' and so shouldn't WASM.

[bloppe]

Luckily, the CM exists as a well-decoupled layer on top of core modules, which are just basic numeric types. So people can pretty easily just ignore the whole thing if they don't like it.

But for the other 99% of devs who just want to exchange strings across various language boundaries without quadratic glue complexity, we have the CM.

[swiftcoder]

> operating-system/platform ABI conventions which compilers and 'user code' has to adhere to without requiring a 'component model'

I don't think there's a huge distinction here - the component model is more or less just a (standardised) ABI convention.

[josephg]

How would a compiler toolchain ship a debugger for webassembly? It’s kind of impossible. The only place for a debugger is inside the browser. Just like we do now with dev tools, JavaScript, typescript and webassembly languages.

> The browser is already complex enough as it is and should be radically stripped down

I’d love this too, but I think this ship has sailed. I think the web’s cardinal sin is trying to be a document platform and an application platform the same time. If I could wave a magic wand, I’d split those two used cases back out. Documents shouldn’t need JavaScript. They definitely don’t need wasm. And applications probably shouldn’t have the URL bar and back and forward buttons. Navigation should be up to the developers themselves. If apps were invented today, they should probably be done in pure wasm.

> Web APIs are designed from the ground up for Javascript

Web APIs are already almost all bridged into rust via websys. The APIs are more awkward than we’d like. But they all work today.

[azakai]

> How would a compiler toolchain ship a debugger for webassembly?

You can integrate external debuggers, like Uno documents here:

https://platform.uno/docs/articles/debugging-wasm.html

I assume that uses some browser extension, but I didn't look into the details.

You can also use an extension to provide additional debugging capability in the browser:

https://developer.chrome.com/docs/devtools/wasm

[flohofwoe]

FWIW, it's possible to setup an IDE-like debugging environment with VSCode and a couple of plugins [1]. E.g. I can press F5 in VSCode, this starts the debuggee in Chrome and I can step-debug in VSCode exactly like debugging a native program, and it's even possible to seamlessly step into JS and back. And it's actually starting faster into a debug session than a native macOS UI program via lldb.

[1] https://floooh.github.io/2023/11/11/emscripten-ide.html

[pjmlp]

Inside the browser hardly matters if it isn't maintained, Google has done almost nothing to their DWARF debugging tooling since it was introduced as beta a few years ago.

[flohofwoe]

> Google has done almost nothing to their DWARF debugging tooling since it was introduced as beta a few years ago

WASM DWARF debugging works perfectly fine though?

The 'debugger half' just moved from Chrome into a VSCode debug adapter extension where debugging is much more comfortable than in the browser:

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

I use that all the time when working on web-platform specific code, with this extension WASM debugging in VSCode feels just like native debugging (it actually feels snappier on macOS than debugging a native macOS exe via LLDB).

[pjmlp]

More like it mostly works.

[flohofwoe]

...'mostly works' describes pretty much every debugging experience outside Visual Studio. But I really can't complain, I've set up 'F5-debugging' in VSCode, pressing F5 starts a local web server, starts Chrome with the debuggee, and starts a remote debug session in VSCode and stops at the first breakpoint (and interestingly all this happens 'immediately', while debugging a native Cocoa macOS app via LLDB easily takes 5 to 10 seconds until the first breakpoint is reached).

TL;DR: It works just fine (early versions of the DWARF extension had problems catching 'early breakpoints' but that had been fixed towards the end of 2024.