3 ms·
The entire article boils down to one specific problem: string marshalling overhead can be optimized to be about 2x faster. Integrating the component model into
by flohofwoe 8mo ago
The entire article boils down to one specific problem: string marshalling overhead can be optimized to be about 2x faster. Integrating the component model into browsers is overkill for that (and everything else belongs into the toolchains without touching the browser guts).
- hmry 8mo ago> The entire article boils down to one specific problem: string marshalling overhead No, I don't think so at all. 80% of the article is about other problems (JS bindings are complicated to generate and a leaky abstraction, additional tools beyond the compiler are required, compiler authors don't want to deal with them, they increase the friction for getting started, they're hard to debug, ...)
- flohofwoe 8mo ago...all those problems should be fixed in the toolchains, not in the browser. Emscripten exists, DWARF debugging support exists and works (I can step from C/C++ code into JS code and back with the WASM DWARF debugging extension for VSCode), other language ecosystems just need to catch up.
- troad 8mo agoYou're implying the only solution to unnecessary friction is reams of unnecessary lubricant. Someone had to spend time building those unnecessary toolchains. Imagine if this time were spent developing cool libraries or use cases for WASM, instead of building out plumbing.