Yeah, large file sizes and some RAM overhead is a drawback that comes with Electron apps.
However, it would never have been possible for me to make Heynote for all of Mac, Windows and Linux, on my spare time and within a reasonable timeframe, without Electron.
Also, the CPU usage overhead for Heynote is minimal. It's one of the apps I use the most, and it's never among the programs that have used the most CPU. Yes, 200+ MB of RAM seems quite excessive in theory, but in practice it's less than 1% of the total RAM memory of my laptop (24 GB).
> However, it would never have been possible for me to make Heynote for all of Mac, Windows and Linux, on my spare time and within a reasonable timeframe, without Electron.
I'm confused - browsers already do this for you - From what I can tell you aren't using any specific APIs necessitating electron?
You also could easily have a live demo since it's a client side app.
> Yes, 200+ MB of RAM seems quite excessive in theory, but in practice it's less than 1% of the total RAM memory of my laptop (24 GB).
You should consider that people would be adding this to their workflow. So it's not not 200MB/Total RAM but instead it's 200MB/Remaining memory
Mine has 32GB Total total but less then 2GB free (and the only reason it's free is because it was swapped), which would make this ~10% of my free memory. This means when I run webpack or other things like that it swaps even worse.
This feels like one of those situations where a PWA with local storage might be a winning play. Since it doesn't actually need filesystem access or some of the other integrations electron provides. In my case, at least, I do pretty well always have at least one chromium-type browser running, so that would cross off the download objection (which was mild) and the RAM overhead (which was more serious, today at least).
Consider Tauri[1] as well. It uses the native WebViews on the various platforms instead of bundling Chromium.
FWIW, we also have an Electron app, in part because the integration with native APIs (which we use) is fairly full-featured with Electron. But if I was greenfield starting an app today I'd probably try Tauri. For your app it looks like you're not trying to do too much outside the WebView so might be worth checking out.
Could it have been a PWA? I have seen some progressive web apps give an option to install as an app when you open them in your browser. Have thought about making a PWA for my kid which I could then install on my phone.
You might consider Flutter for desktop apps next time, as they are compiled to machine code and won't be nearly as heavy as Electron, plus you get automatic mobile and web support.
My experience with apps built with Flutter is bad. Appflowy, for example, has extremely poor performance. Both in terms of loading large files and RAM usage. See my performance comparison of block editors[1].
I've built a block editor using Qt C++ and QML that is vastly more performant[2].
I recall that the app Rows had their desktop version written in Flutter and it was extremely fast, able to render billions of rows as a spreadsheet, so I don't think it's a framework limitation but it is likely that Appflowy is not very well implemented.
Well, I'm yet to see a fast block editor implemented in Flutter (with proper RAM use as well). Another one is Super Editor[1] which is the editor from the Superlist app[2]. I didn't properly test it cause there are no builds. But the web version[3] hangs when I try to paste the text of War and Peace. I would like to test it properly one day.
However, it would never have been possible for me to make Heynote for all of Mac, Windows and Linux, on my spare time and within a reasonable timeframe, without Electron.
Also, the CPU usage overhead for Heynote is minimal. It's one of the apps I use the most, and it's never among the programs that have used the most CPU. Yes, 200+ MB of RAM seems quite excessive in theory, but in practice it's less than 1% of the total RAM memory of my laptop (24 GB).