4 ms·

I think a big part of what people perceive as being Electron’s fault actually comes down to how the app code is written. Beyond the regrettable (but hard to av

I think a big part of what people perceive as being Electron’s fault actually comes down to how the app code is written. Beyond the regrettable (but hard to avoid) baseline memory usage, startup time, and bundle size, at the end of the day it’s just a browser. Native code might be faster than JS on benchmarks but at the level of clicking a button to perform an action, there’s no technical reason that the latency should be any different, certainly not at the level of 100s of milliseconds. It’s just slow UI code at that point. I daresay the bigger problem is the huge prevalence of slow UI code. It reminds me of this article on why NetNewsWire (a native Mac RSS reader) is fast - turns out it takes a lot of work beyond just being native! (and a bunch of these strategies have analogs in the JS world too) https://inessential.com/2020/05/18/why_netnewswire_is_fast https://inessential.com/2020/05/18/why_netnewswire_is_fast

claytongulick 4y ago
I think this is the thing. Web apps get a bad rap, and justifiably so. But the blame frequently lies with the bloated frameworks developers choose to use. Developers choose these frameworks because web development is pretty complex. When done properly, light-weight responsive web apps can be smooth as butter and an amazing user experience. I do think that it requires a higher degree of technical expertise and more development effort to achieve this on the web vs native, though. In some cases, depending on the business model and audience, it's worth it.
- robgibbons 4y ago
  Just the other day I did an experiment while writing a new Electron app. I created a Hello World -- once using React, and another with just static HTML & Vanilla JS. The React version, literally just the default Hello World page, was already noticeably slower and jankier at startup than the static HTML version. Tack onto that experience however many NPM packages the average React app imports, maybe some hastily written synchronous calls that play fast and loose with your main thread, and it's not difficult to see why Electron and web apps in general get a bad wrap. It's not unavoidable, it's just lazy practices.
- dceddia 4y ago
  Yeah, and honestly I don't think it's even down to the framework all the time either, but some frameworks make it easier than others. React, for instance, is famously the opposite of bloated ("it's just the V in MVC") and leaves it up to the user to shape it how they like. I think the trouble is that it's not really fast by default. You end up needing to be pretty careful to avoid excessive rendering, which in practice means thinking about referential equality a lot, and trying to make sure renders only happen when you mean them to. React can be plenty fast though, with care. I think Svelte does a better job of being fast by default, and part of that is because it's more truly "reactive". Change a variable, and that specific part of the page is updated; if other variables depend on that one, then those parts are re-rendered too. It needs a lot less babysitting to avoid extra CPU cycles. I've thought about this a bunch because I'm building a video editor with Svelte and Tauri. (Tauri is a Rust-based alternative to Electron that uses the system webview instead of Chromium). Of the things I'd expect to be hampered by being web-based, "video editor" is pretty high on that list! But I've yet to run into a performance problem that came down to the browser being just too slow. It has so far been something under my control, whether that's needing to optimize some canvas drawing, or finding the most efficient way to get video frames on the screen, or minimizing the messages I'm sending between Rust and the UI. There are certainly inefficiencies that wouldn't be a problem with a native app, but it's been possible to work around them so far. And as the sole developer on the project, it's nice to be able to serve a larger market without having to keep 2 code bases in sync.
  - claytongulick 4y ago
    I like what I've seen of svelte, but it's going to be hard to drag me away from vanilla web components with lit-html as a renderer. Super lightweight, blazing fast, and straightforward to develop with. Class property setters that call render() are the reactivity. In some cases it does take more time to reason about lifecycle and rendering than the equivalent react component, though.

claytongulick 4y ago

I think this is the thing. Web apps get a bad rap, and justifiably so. But the blame frequently lies with the bloated frameworks developers choose to use. Developers choose these frameworks because web development is pretty complex. When done properly, light-weight responsive web apps can be smooth as butter and an amazing user experience. I do think that it requires a higher degree of technical expertise and more development effort to achieve this on the web vs native, though. In some cases, depending on the business model and audience, it's worth it.

robgibbons 4y ago
Just the other day I did an experiment while writing a new Electron app. I created a Hello World -- once using React, and another with just static HTML & Vanilla JS. The React version, literally just the default Hello World page, was already noticeably slower and jankier at startup than the static HTML version. Tack onto that experience however many NPM packages the average React app imports, maybe some hastily written synchronous calls that play fast and loose with your main thread, and it's not difficult to see why Electron and web apps in general get a bad wrap. It's not unavoidable, it's just lazy practices.
dceddia 4y ago
Yeah, and honestly I don't think it's even down to the framework all the time either, but some frameworks make it easier than others. React, for instance, is famously the opposite of bloated ("it's just the V in MVC") and leaves it up to the user to shape it how they like. I think the trouble is that it's not really fast by default. You end up needing to be pretty careful to avoid excessive rendering, which in practice means thinking about referential equality a lot, and trying to make sure renders only happen when you mean them to. React can be plenty fast though, with care. I think Svelte does a better job of being fast by default, and part of that is because it's more truly "reactive". Change a variable, and that specific part of the page is updated; if other variables depend on that one, then those parts are re-rendered too. It needs a lot less babysitting to avoid extra CPU cycles. I've thought about this a bunch because I'm building a video editor with Svelte and Tauri. (Tauri is a Rust-based alternative to Electron that uses the system webview instead of Chromium). Of the things I'd expect to be hampered by being web-based, "video editor" is pretty high on that list! But I've yet to run into a performance problem that came down to the browser being just too slow. It has so far been something under my control, whether that's needing to optimize some canvas drawing, or finding the most efficient way to get video frames on the screen, or minimizing the messages I'm sending between Rust and the UI. There are certainly inefficiencies that wouldn't be a problem with a native app, but it's been possible to work around them so far. And as the sole developer on the project, it's nice to be able to serve a larger market without having to keep 2 code bases in sync.
- claytongulick 4y ago
  I like what I've seen of svelte, but it's going to be hard to drag me away from vanilla web components with lit-html as a renderer. Super lightweight, blazing fast, and straightforward to develop with. Class property setters that call render() are the reactivity. In some cases it does take more time to reason about lifecycle and rendering than the equivalent react component, though.