4 ms·

>The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow. I doubt this is entirely true. VS

>The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow. I doubt this is entirely true. VSCode is frequently cited as an example of a good, performant Electron application. Its performance is generally acceptable (I use it as my primary text editor), but it absolutely chugs sometimes. Sublime is light-years ahead in terms of performance.

rolleiflex 7y ago
That is true and as a user of Sublime myself, I agree. However, VSCode is still a JS app that has to do its computation on a single thread, on a largely interpreted language. If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary speed and real multi-thread capabilities.
- tybit 7y ago
  I really hope this is the sort of thing products like VSCode will start turning to WASM for. Performance is their Achilles heel for the time being even though they’ve done a relatively good job considering.
  - rolleiflex 7y ago
    That would be helpful. Go can compile to WASM natively, so if I could just compile it down to that, I wouldn't even have different Go binaries for different platforms. That said, some things I use (like SQLite, gRPC) will probably forever remain a C dependency, so I'm not sure if WASM would help with that.
  - nobleach 7y ago
    A couple of things here. WASM isn't necessarily more performant than vanilla JS. For the web, it'll open the door to the JS engine as a compile target, and that's great.... but it's still not super fast. Secondly, in the case of an application, WASM is of little use since (with node and almost any programming language) you have an FFI available. One could simply shell out computationally heavy things to C++ or whatever else. This is what many folks do with their Electron apps already (via node-ffi).
    - tuananh 7y ago
      true that. native module is still quite a lot faster in my experiencee
  - pjmlp 7y ago
    The Microsoft's React Native for Windows/macOS team keeps comparing how Electron sucks to React Native, so I am hoping that they eventually manage to pull Viscose into their direction.
- wwright 7y ago
  JS doesn’t have to do computation on a single language. Web workers an option, and I believe Node has additional tools as well. It definitely can’t compete with true threads for work that needs true threads, but you probably don’t have much work that needs true threads (rather than just workers and channels).
hajile 7y ago
MS has already proven that canvas is faster and better than HTML for text when they converted the terminal to canvas and it got an order of magnitude faster. I wonder why they haven't expanded on this with Rust and WASM taking events and returning a canvas buffer. This seems like the best of both worlds. They get the responsiveness and performance of native code for the hard bits while retaining the ease and flexibility of HTML for the rest of the UI.

rolleiflex 7y ago

That is true and as a user of Sublime myself, I agree. However, VSCode is still a JS app that has to do its computation on a single thread, on a largely interpreted language. If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary speed and real multi-thread capabilities.

tybit 7y ago
I really hope this is the sort of thing products like VSCode will start turning to WASM for. Performance is their Achilles heel for the time being even though they’ve done a relatively good job considering.
- rolleiflex 7y ago
  That would be helpful. Go can compile to WASM natively, so if I could just compile it down to that, I wouldn't even have different Go binaries for different platforms. That said, some things I use (like SQLite, gRPC) will probably forever remain a C dependency, so I'm not sure if WASM would help with that.
- nobleach 7y ago
  A couple of things here. WASM isn't necessarily more performant than vanilla JS. For the web, it'll open the door to the JS engine as a compile target, and that's great.... but it's still not super fast. Secondly, in the case of an application, WASM is of little use since (with node and almost any programming language) you have an FFI available. One could simply shell out computationally heavy things to C++ or whatever else. This is what many folks do with their Electron apps already (via node-ffi).
  - tuananh 7y ago
    true that. native module is still quite a lot faster in my experiencee
- pjmlp 7y ago
  The Microsoft's React Native for Windows/macOS team keeps comparing how Electron sucks to React Native, so I am hoping that they eventually manage to pull Viscose into their direction.
wwright 7y ago
JS doesn’t have to do computation on a single language. Web workers an option, and I believe Node has additional tools as well. It definitely can’t compete with true threads for work that needs true threads, but you probably don’t have much work that needs true threads (rather than just workers and channels).

hajile 7y ago

MS has already proven that canvas is faster and better than HTML for text when they converted the terminal to canvas and it got an order of magnitude faster. I wonder why they haven't expanded on this with Rust and WASM taking events and returning a canvas buffer. This seems like the best of both worlds. They get the responsiveness and performance of native code for the hard bits while retaining the ease and flexibility of HTML for the rest of the UI.