by 0xmohit on 9/8/22, 6:09 AM with 38 comments
by lifthrasiir on 9/8/22, 6:37 AM
by syrusakbary on 9/8/22, 7:11 AM
Oh dear lord. This is such a twisted narrative. The Component Model is a proposal that is only supported by one runtime out of the 20 used in production, none of them in the browser (don't look for it in v8, SpiderMonkey or Javascript Core, Wazero, Wasmer, Wizard Engine, WAVM, ...). So if there's anything that actually locks you in... is probably that!
Even when Wasmer tried to add support for it on wit-bindgen (precursor for the Component Model), the same people from the Bytecode Alliance who are working on the Component Model proposal rejected it [1]. Do they really want collaboration and not lock-in? One begins to wonder.
It gets even more funny when you continue reading the article and you also realize that all people in the WasmDay committee that decides what get's in our out their CNCF conference are also part of the Bytecode Alliance. When the only competition they "cheer" is the one that comes from their approved friends.
I would highly encourage everyone to read some of the practices of the Bytecode Alliance that the AssemblyScript community has redacted, it might be eye opening! [2]
[1] https://github.com/bytecodealliance/wit-bindgen/issues/306
[2] https://www.assemblyscript.org/standards-objections.html
by fuzzc0re on 9/8/22, 11:13 AM
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.
by ilaksh on 9/8/22, 5:45 PM
Maybe there can be some kind of universal device driver plugin or something.
It's weird to me that there wasn't initially an organized effort to escape the web browser by coming up with some sort of UI system or ways to integrate other devices etc. Don't know if that has changed.
by max_ on 9/8/22, 11:23 AM
by westurner on 9/8/22, 2:18 PM
IIRC, it's possible to check resource utilization in e.g. a browser Task Manager, but there's no way to do `nice` or `docker --cpu-quota` or `systemd-nspawn --cpu-affinity` to prevent one or more WASM tabs from DOS'ing a workstation with non-costed operations. FWIU, e.g. eWASM has opcode costs in particles/gas: https://github.com/ewasm/design/blob/master/determining_wasm...
by vardump on 9/8/22, 9:36 AM