|
|
|
|
|
|
by bin0
2539 days ago
|
|
|
This is misleading as all get-out. "JavaScript assembler" is WASM, I assume? Running it in a browser still includes the overhead of a browser. The slowness is not from the wasm runtime (which has been implemented standalone and is fast), but in the browser-y gui stuff (which is what electron is good for). Also, WASM has less tooling etc. around it than JS, so JS is used for now. And jS is slow, but it's what is used by electron. Your saying "electron could be made faster if we did all these huge things" is like me saying "but the c could be faster if we did great threading, really efficient code, inline ASM, and used intel's crazy compiler for maximum optimization". I get there's hope for the future, but not currently. In any case, implementing a custom graphics stack (like the web) will always be a heavy-weight task compared to one application. |
|
|
Not entirely true: In representative benchmarks, WASM has only 65% of the performance of native code. Of course, everything gets much worse the moment you interact with browser mechanics—WASM is only this fast while doing raw computations.
https://www.usenix.org/conference/atc19/presentation/jangda