4 ms·

The fascinating thing about JS/TS UI frameworks is that they seem to grow out of a frustration with all the complexity, heaps and heaps of oddball syntax, impli

by bborud 2y ago

The fascinating thing about JS/TS UI frameworks is that they seem to grow out of a frustration with all the complexity, heaps and heaps of oddball syntax, implicit behaviors and things that need to happen in a particular order or things blow up in ways that take years to learn to avoid. So someone sets out to "fix" some aspect of this, discovers that their new design was incomplete, and then all of this weirdness seeps back in to "fix" the problems that arise, and then the cycle starts over. I had hoped that WASM would provide an opportunity to invite more disciplined designers to accomplish something in the browser, but that never happened. I've often wondered why. I've tried to make use of WASM on the server side, but I have to admit that it is limited and clumsy and leads to heaps of unpleasant and risky code.

rounce 2y ago
Lots of things use Wasm/WaSI as a plugin interface/runtime everything so I really question your closing point. It’s more intended that you compile to it from other higher level languages like C, C++, Rust, C# etc. than writing the text format for example. I suspect the reason it hasn’t become commonplace to build web UIs with it is because your average frontend dev isn’t too familiar with those languages or their UI libraries nor writing a browser compatible rendering backend for them.
- bborud 2y ago
  When I call WASM functions the types I have available to me are i32/64 and f32/64. There are not other options. Not even byte arrays. If I need to pass strings, structs, bytes etc I have to allocate memory inside the WASM instance, serialize the data into this memory, pass the memory offset as a parameter to the function that should operate on it, deserialize the data and then clean up the mess. This is awkward, error prone and risky. Yes, I do use WASM from a high level language that has automatic memory management. That's why this old fashioned messing about manually with memory allocation and doing pointer arithmetic seems like such a huge step back. Yes, there are people that make plugin frameworks. And yes, one of the things they have to do is to hold their nose and just accept that this is the ugly reality of using WASM. It doesn't mean that this isn't a terrible design flaw. It is.

by bborud 2y ago

rounce 2y ago

Lots of things use Wasm/WaSI as a plugin interface/runtime everything so I really question your closing point. It’s more intended that you compile to it from other higher level languages like C, C++, Rust, C# etc. than writing the text format for example. I suspect the reason it hasn’t become commonplace to build web UIs with it is because your average frontend dev isn’t too familiar with those languages or their UI libraries nor writing a browser compatible rendering backend for them.

bborud 2y ago
When I call WASM functions the types I have available to me are i32/64 and f32/64. There are not other options. Not even byte arrays. If I need to pass strings, structs, bytes etc I have to allocate memory inside the WASM instance, serialize the data into this memory, pass the memory offset as a parameter to the function that should operate on it, deserialize the data and then clean up the mess. This is awkward, error prone and risky. Yes, I do use WASM from a high level language that has automatic memory management. That's why this old fashioned messing about manually with memory allocation and doing pointer arithmetic seems like such a huge step back. Yes, there are people that make plugin frameworks. And yes, one of the things they have to do is to hold their nose and just accept that this is the ugly reality of using WASM. It doesn't mean that this isn't a terrible design flaw. It is.