4 ms·

Smallest compared to any of current capable compile-to-wasm langs. How dare you bring up React, when it's already lose to Solid which is apple-to-apple (js). Re

Smallest compared to any of current capable compile-to-wasm langs. How dare you bring up React, when it's already lose to Solid which is apple-to-apple (js). React is freakin bloat. Numbers of functionality is the problems produced by itself and then solve its own problems. If you ask me to compare to React for todo app, wasm with gc + interfacing with DOM, is going to blow React out of water in both size and performance (logic wise). DOM-wise, thing like "signal" already won anyway. I honestly don't understand why you bring up React.

yawaramin 4y ago
Any actual numbers from an actual comparison? Also, 'how dare you', lol, calm down dude.
- Existenceblinks 4y ago
  Sorry about that I was saying in kidding tone. We're all good. Here is the wasm binary size number (2019): https://stackoverflow.com/questions/55135927/how-do-webassembly-binaries-compiled-from-different-languages-compare-in-size https://stackoverflow.com/questions/55135927/how-do-webassem... I didn't bookmark Zig and other for the number, it's over here and there on HN threads and Github issues. --- I think you conflated "wasm binary size from AssemblyScript" with AssemblyScript size itself, that's why you brought up React to compare with AssemblyScript. AssemblyScript doesn't compete with React. And comparing React with the others is also tricky because of paradigm difference. React view and logic are very coupled. Compile-to-wasm langs only compete with js/ts part excluding the DOM part .. at least for now because wasm can't even share string ref right now (the "stringref" proposal is currently phase-1 ), let alone DOM access. Wasm-gc proposal is already in phase-3. I think languages that used to also compile their runtime with app code could be smaller because wasm host manage collect the garbage for you in terms of "struct" and "array" (you can check out https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md#requirements https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...)

yawaramin 4y ago

Any actual numbers from an actual comparison? Also, 'how dare you', lol, calm down dude.

Existenceblinks 4y ago
Sorry about that I was saying in kidding tone. We're all good. Here is the wasm binary size number (2019): https://stackoverflow.com/questions/55135927/how-do-webassembly-binaries-compiled-from-different-languages-compare-in-size https://stackoverflow.com/questions/55135927/how-do-webassem... I didn't bookmark Zig and other for the number, it's over here and there on HN threads and Github issues. --- I think you conflated "wasm binary size from AssemblyScript" with AssemblyScript size itself, that's why you brought up React to compare with AssemblyScript. AssemblyScript doesn't compete with React. And comparing React with the others is also tricky because of paradigm difference. React view and logic are very coupled. Compile-to-wasm langs only compete with js/ts part excluding the DOM part .. at least for now because wasm can't even share string ref right now (the "stringref" proposal is currently phase-1 ), let alone DOM access. Wasm-gc proposal is already in phase-3. I think languages that used to also compile their runtime with app code could be smaller because wasm host manage collect the garbage for you in terms of "struct" and "array" (you can check out https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md#requirements https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...)