
Doing work locally minimizes problems with Electron apps - jlongster
https://jlongster.com/secret-of-good-electron-apps
======
jlongster
I'm the author of the post and I should also say that I don't love Electron.
It's a practical choice for getting an app of the ground, but I want something
more lightweight eventually.

I see it as a stop-gap until I can invest more resources into something more
lean. But I'm focused on the product right now, not rewriting the world and
wasting time because of engineering ideals.

~~~
ulfw
I agree with your statement but just have never really seen it work that way
in real life.

Slack is the best example. An app that just 'works' in Electron and the stop-
gap became the permanent solution for eternity et voila -> still huge
valuation and IPO.

I am afraid once you go Electron, most will stay Electron.

~~~
jlongster
Whatever it ends up being it has to be web-based. I'm definitely not going to
rewrite the app.

However, if something were to come along that uses the user's local webview
instead and provided a way to bundle a node server with it, I could absolutely
switch to it.

In fact, I've played with the idea of providing an app that only sits in your
menubar and runs the server, and opening the app just opens a tab in your
browser. But most users don't care as much about all this as we think and
would find that odd.

You're right though - if something is working well enough it probably will end
up sticking. Slack just goes to show that it's probably Good Enough despite
what we feel about it.

~~~
jorvi
Someone tried that with Electrino, but there hasn't been any activity in 2
years.

That only deals with memory and disk use though. CPU and battery use under
'load' will still be through the roof compared to native apps. I put load in
quotes because even entering text or scrolling creates massive energy
consumption spikes on Electron. Oh and your UI will still be sluggish too.

To be clear: I'm not hating on your app or choice of Electron, just be aware
most of the drawbacks are here to stay. Even Microsoft with all their
engineering prowess can't seem to fix them (see VScode vs Sublime), and they
are already using a heavily customized and optimized Electron.

------
mhd
The problem I see with many electron applications isn't just that they're
bloated (they probably are in about the same relation to average RAM that
Tcl/Tk apps were or early Gnome/Mono ones). [Edit: To clarify, I mean the
average RAM at the time they were accused of bloat]

It's that they're quite non-native. And not just in the "button borders are 1
pixel wider than usual" sense -- they're usually styled to resemble web
applications, with big data views, Material UI, etc.

Going from this to something more lightweight/native doesn't just require a
different API, it requires a completely redesign.

In other words: The Big Rewrite That We're Definitely Going To Do Someday(tm).

~~~
jlongster
I agree with this too but this problem can be addressed by caring. I care. You
can find a bunch of non-native interactions in my app but every time I work on
it I make it better and implement more of a native feel (like disabling
selecting text when you shouldn't be able to, etc).

It's a balance - personally I think apps that focus on a specific platform is
exclusionary. So accepting some non-native feel means more people can use my
app.

I agree that browsers make it hard though.

~~~
jpwgarrison
> like disabling selecting text when you shouldn't be able to

This is the worst thing in computers. Why would you EVER _block_ the ability
to select text? I am engaged enough to want to select something you made!
Embrace that, don't stop it!

~~~
robocat
Think of all the thousands of tiny snippets of text and single Unicode
characters that make up a UI. You definitely don't want to be able to select
snippets within most controls, because selection _interferes_ with using the
control.

Examples: the text in a menu item, the text in a button, the Unicode x in a
close icon, the bar between menus.

This is really noticeable in a few web applications where you can select the
wrong thing and it interferes severely with using the UI (I have experienced
this with Windows and Android).

Yes, you usually want to be able to select the main text. However many mobile
UI frameworks just disable all selection, because that is the easiest way to
also disable selection within UI controls (managing this issue is actually
quite difficult from my experience writing a HTML UI framework).

~~~
steve1977
In other words, HTML UI frameworks are still far behind native frameworks and
actually not really usable yet.

~~~
robocat
In other words, poorly written components don't work well: which happens in
other GUI toolkits and not just HTML.

Good HTML UI frameworks don't make this mistake.

~~~
steve1977
Are there any good HTML UI frameworks yet?

~~~
robocat
So long as you don't want an OS native UI, yes I think so.

For example I use Visual Studio Code every day and the UI seems pretty good to
me (panels, menus, tabs, check boxes, combos etc). I am presuming it uses a
component framework (although I admit I haven't looked at the source).

------
asdkhadsj
So, I love the role that Electron fits, but boy do I hate how much we discuss
Electron itself.

What we should be discussing is providing the functionality of Electron
without the cost. A protocol that behaves like React native. Ideally a spec,
which any language can implement and provide a native UX to the end user.

Some projects try (ProtonNative, for example), but I've not seen one go quite
far enough. I don't want to be forced to write a JS app to get benefits here.
After all, with ReactNative, it's basically a process RPC to a bunch of
widgets. `process <-> UI`. So why be forced to write JS? An open spec would do
wonders here.

I've not invested cycles on solving this problem, of course. Yet I can't help
but wonder why so many people are focused on solving UI issues with very
narrow solutions like Electron, ReactNative, ProtonNative and so forth.
They're great projects, but a slightly wider vision would make them amazing
projects.

Thoughts? Am I missing something obvious?

~~~
nexuist
>I don't want to be forced to write a JS app to get benefits here.

Although most major Electron apps are written in node, it's pretty easy to
have a backend in another (compiled) language. You can simply use the
subprocess module in node and build your own bridge, for example to a Go CLI
that accepts events from electron and does whatever you want it to do. It's a
workaround for sure, but the point is you could do it in a pretty stable way.

>After all, with ReactNative, it's basically a process RPC to a bunch of
widgets

>Yet I can't help but wonder why so many people are focused on solving UI
issues with very narrow solutions like Electron, ReactNative, ProtonNative and
so forth

I've used React Native in the past and I'm working on a Flutter app now. The
problem with RN is that every platform has its own unique widgets. It's neat
that you have one codebase, but you still need to build a separate UI (at
least for certain pages) for Android and iOS. It just doesn't look right
otherwise.

Flutter gets away with this because it owns the drawing layer as well as the
widget layer. I know that something drawn in Flutter is going to look exactly
the same no matter where I run it. This means that widgets fail gracefully by
default - in RN, things just straight up break or look weird. The worst that
can happen in Flutter is that the user has to deal with an iOS picker on
Android or vice versa.

Electron is more akin to Flutter than RN in this way. It controls the
drawing/rendering because of Chromium. Slack on Mac looks exactly like Slack
on Windows. That's more enticing than needing to build new UIs for every
platform you want to support.

The only way to solve this is to basically invent another cross platform
drawing layer. But why bother? HTML/CSS already exists. There's effort and
tooling and docs and community and everything else you'd need for a successful
framework. It's not worth the effort.

I think the best solution will be just embedding Electron at the OS layer, so
apps don't have to bring along their own Chromium runtime. This way it runs
closer to the metal, which should help alleviate RAM and storage concerns
(these seem to be the only major concerns most people have with it).

~~~
ilikehurdles
> Flutter gets away with this because it owns the drawing layer as well as the
> widget layer. I know that something drawn in Flutter is going to look
> exactly the same no matter where I run it.

Isn't this pretty unfriendly to users? As an iOS user, I occasionally
encounter apps written with Material guidelines in mind, and it's a bit
jarring because they don't fit the guidelines of the device I'm using.

These are all great solutions for developers, but for consumers, it all kind
of sucks to varying degrees.

~~~
lmm
> Isn't this pretty unfriendly to users? As an iOS user, I occasionally
> encounter apps written with Material guidelines in mind, and it's a bit
> jarring because they don't fit the guidelines of the device I'm using.

Personally I care a lot more about what app I'm using than what OS it's
running on; I'd far rather have Slack look the same on my phone as it does on
both my computers than have Slack on one computer look like apps on that
computer but different from Slack on the other computer. Sometimes we forget
that the OS exists to facilitate the apps, not the other way around.

~~~
zapzupnz
> Sometimes we forget that the OS exists to facilitate the apps, not the other
> way around

For OS where the base operating system didn't offer much functionality to apps
beyond the basic API for building controls and so on, this might be true.

For Apple's systems, especially macOS and iOS/iPadOS, this isn't quite true.
On iOS, apps need to be built according to system conventions and standards in
order to be able to take advantage of a lot of _services_ that the OS provides
(such as accessibility, automation, i10n).

When a macOS or iOS ignores system conventions, the result can range from
completely unnoticeable, a slight inconvenience, or the app being next to
unusable after the OS updates due to underlying features being changed without
the developer having updated their (needless) custom code to account for it.

I notice this with the Sensibo app which follows Material design guidelines.
It took me a long time to figure out how to edit a particular bit of
information because the icons that the app used were not what I was expecting.
On iOS, an editable table view should be accompanied by a button at the top
right that says "Edit"; Sensibo instead provided a pencil icon. After I
finished editing, I wasn't sure what to do — on iOS, I expect to see a "Done"
or "OK" button where the Edit button was; instead, Sensibo required me to
click on the pencil again even though it was greyed out and looked inactive.

When an app doesn't conform to the guidelines _and I have a choice about
whether or not to use that app_ , I'll generally prefer to find something else
where I'm not expected to memorise how to use it.

Sometimes we forget that apps exist to facilitate getting tasks done, not
forcing us to remember their deliberately-included inconsistencies compared to
every other app on the system (including third party ones).

------
Sahhaese
I'm not an electron hater, but when only using 300mb of memory while idle is
something to boast about, they may have a point.

~~~
CharlesW
It's relative. Outlook is using 2.37 GB of RAM as I type this.

~~~
Sahhaese
That's odd, OUTLOOK.EXE is using 44MB of ram as I type this and has been open
for 7 hours.

~~~
toyg
Maybe a Mac. My Outlook on mac is idling at 150MB.

~~~
CharlesW
Yes, this is Office 365 on macOS. Neither the computer nor Outlook have been
restarted in weeks, which is surely contributing to its current RAM footprint.

------
wlesieutre
Electron discussions often focus around the battery and memory impact, one
other thing I'd mention is the poor access to native features. You get the
stuff a web browser can do, but for anything else offered by the OS you might
need to wait a while.

For example, Apple shipped their first TouchID laptop in 2016, and Electron's
support for that landed in v6.0.0 beta 1 just last month.

[https://electronjs.org/releases/beta?page=2#6.0.0-beta.1](https://electronjs.org/releases/beta?page=2#6.0.0-beta.1)

I'd looked at switching off 1password to BitWarden and that's a pretty major
feature to be missing for three years.

Surprisingly, for as much as everyone craps on the touchbar, that got
supported by Electron a lot faster than TouchID did. I guess because not all
apps need authentication and they can rely on passwords instead, while it's
really obvious when an app doesn't have touchbar support.

~~~
jbverschoor
Not with nativescript.. you just use the brand new api

~~~
mthoms
Does nativescript do desktop? Their site seems squarely focused on mobile
(iOS/Android).

------
gfodor
If electron apps' claimed memory causes your computer to go slow due to
swapping, you should complain. But most complaints I see on this topic stem
from a discomfort over the reported figure by the operating system. With SSDs
and modern virtual memory systems the claimed memory figure is not a
sufficient measure to infer the resource utilization of a process. For
example, if slack has a bunch of allocated memory that is rarely accessed,
it's going to (at worst) land on your SSD and sit there, having no impact on
your user experience.

If you want to complain about applications' engineering, you should complain
not about claimed memory but about things that are directly affecting resource
utilization or user experience like power draw or excessive CPU utilization
due to poor programming. Claimed memory must be combined with a profile to
show that cold reads are common enough for the claimed memory figure to be
correlated with a performance hit. But of course, this often isn't readily
available without profiling for all but the most extreme cases, and so
engineering types fixate on easily visible measures like claimed memory that
likely have no actual resource utilization impact in most cases.

~~~
forgottenpass
>If electron apps' claimed memory causes your computer to go slow due to
swapping, you should complain. But most complaints I see on this topic stem
from a discomfort over the reported figure by the operating system.

I tried that once. But I'm sick of having to fight that my usecase is valid,
that my laptop isn't too old, and that it isn't broken/misconfigured in some
other way. It's 4 years old, and I can't run 2 electron applications and
firefox at the same time without swapping so hard I can't get anything done.
Fuck me for asking so much from a computer, right?

~~~
gfodor
I very specifically cited someone like you as being a person who has a valid
complaint. I'm calling out people who get upset at the idea of a computer
doing "wasteful" work, when that wasteful work has no meaningful impact on
latency, responsiveness, power draw, etc. This is common and is a form of
"visibility bias". For example, computers do not report their CPU cache miss
rates in a highly visible place. I'd imagine if they did, you'd have countless
people agonizing over them, despite the fact that in most cases a higher cache
miss rate would not result in perceptible difference when using the computer.

~~~
zapzupnz
> I'm calling out people who get upset at the idea of a computer doing
> "wasteful" work, when that wasteful work has no meaningful impact on
> latency, responsiveness, power draw, etc.

But who gets to make that call?

For every person out there who complaints that using voice chat in Discord on
a MacBook Pro on battery causes the chassis to heat up, fans to kick into
turbo boost, and the battery to dwindle — but __only __when using the .app,
not when using the website through Firefox, there 's another person who says
"oh, but my computer doesn't do that".

So then everybody who has a similar complaint as the first person is branded a
liar and whiner.

------
cpursley
Thanks for the post.

> I want something more lightweight eventually

Check out [https://github.com/revery-ui/revery](https://github.com/revery-
ui/revery)

~~~
jlongster
That's a very cool project (I've used OCaml before) and I hope it takes off. I
should try it, but I admit I'm a little skeptical because there are so many
details to get right like focus management, accessibility, and more.

Unfortunately since I can't rewrite my project entirely, I'm going to need
something that reduces bloat by using a local webview instead, so it's still
web-based.

~~~
ori_b
The local web view is the bloat. The rest of electron is not the problem.

~~~
jlongster
? A local webview usually means that it reuses the user's already installed
browser and uses that instead.

~~~
ori_b
The browser I have installed is the single most resource intensive program I
have on my computer.

~~~
iforgotpassword
Why? Because you picked a particularly bad one or because you have 200 open
tabs? Usually the browser is running anyways so adding another open tab or
window increases resource usage much less than another program shipping its
own browser engine.

~~~
hdfbdtbcdg
Do you know of a browser that isn't massively resource intensive?

------
toyg
300mb of memory to do a bit of money-counting, which you could probably do
equally well with MSVC in 2mb.

Such a wasteful world.

~~~
AlexandrB
My favourite example is Etcher[1] which is effectively a GUI for "dd" and
ships as a 227MB "app" that uses >200MB of RAM idling.

"dd" is 37KB.

[1] [https://www.balena.io/etcher/](https://www.balena.io/etcher/)

~~~
nexuist
I've used Etcher a bunch of times. It's pretty and gets the job done.

But it's also heavily recommended within the Raspberry Pi community, and used
by Balena's customers for starter IoT applications. We can assume most of the
users of this application are beginners.

So, do you think these beginners would care about the size of this "app" that
they'll probably delete as soon as it finishes? Do you think they'd care about
200MB of RAM when they're almost certainly running it on any modern PC instead
of some ancient EeePC from hell? As a beginner, would you feel more
comfortable in front of Etcher or dd?

The crux of your argument basically boils down to "a GUI takes up more RAM
than a CLI." Which is obviously true, but it doesn't invalidate the need for
more GUIs in the world. Could Etcher have been built with a native GUI? Sure,
but it's free software, there are no expectations. If you wanted to, you could
clone the repo and build it natively yourself.

But why would you? Etcher already exists, and it would save you from hundreds
of hours of debugging and learning new frameworks. Knowing HTML/CSS/JS, you
could build Electron Etcher in a fraction of the time it would take you to
build Qt4 Etcher, and the compromises are acceptable given the target
audience.

And now you understand why the Etcher devs chose Electron.

~~~
shaan7
> So, do you think these beginners would care about the size of this "app"
> that they'll probably delete as soon as it finishes

Well, looks like enough people care (or at least noticed)
[https://imgur.com/LV6AT7d](https://imgur.com/LV6AT7d)

~~~
nexuist
The dev's justification:

[https://github.com/balena-
io/etcher/issues/2365#issuecomment...](https://github.com/balena-
io/etcher/issues/2365#issuecomment-394702621)

------
m48
Obviously bundling nearly all of Chromium with an app is inherently
inefficient, but out of curiosity's sake, has there been any objective
analysis of _exactly_ what makes this use a seemingly disproportionate amount
of resources? Are JavaScript runtimes inherently inefficient? Is it Electron's
node.js part? Is it the huge amounts of code needed to parse and render HTML
and CSS? Is it the multimedia features, like WebGL and the video and audio
players? Is the problem actually just badly written code running on top of
Electron? And if so, what _exactly_ are are most Electron apps doing wrong
that one could avoid? Is it, as this blog post seems to suspect, that they
aren't sufficiently taking advantage of Electron's node.js integration?

In addition, once the actual bottleneck has been identified, doesn't this open
the door to fix things on the WebKit/Blink engine side of things? Before, when
Electron was managed by GitHub, one could say this would be unreasonably
difficult, but now that GitHub is owned by Microsoft, isn't tweaking Blink to
be more suitable for deployment environments outside of Chrome exactly the
type of thing they would have a vested interest in doing, and the resources to
actually pull off? After all, with VS Code, they are one of the highest-
profile Electron users, and using Blink in Edge presumably involves working
with the Blink code to some degree anyway.

It's always struck me that a lot of Electron apps likely never use a single
line of WebGL, while a lot of WebGL apps likely only use DOM APIs to pretend
the DOM doesn't exist by plastering everything in a huge <canvas> element, and
both likely don't want their binaries to include the Chrome devtools, but
Electron includes all of these things anyway. I'm not sure how much space or
resources it would actually save, but is Chromium/Blink refactoring their code
and build process to facilitate Electron building different Electron
"profiles" that include different sets of features even remotely a
possibility?

------
rmrfchik
Not only memory is the problem with electron, but also app feeling. Skype left
is the only electron app I'm using. And comparing to desktop messaging app
(telegram): 1\. Skype unresponsive. Opening chat takes up to few seconds. 2\.
I see how opened chat is literally updating -- messages, avatars, emoticons
emerges from dust 3\. Selecting messages as messages in native vs selecting
messages as text with surrounding artefacts (chat is a html page with all what
comes with it)

Summarizing, electron apps are just feels like foreigners.

------
olliej
I have never had an issue with electron apps being terrible because of
networking - although clearly there are apps that do push more work than is
necessary over the network, there’s plenty of native software that does too.

My problem with electron apps is that they use way more memory and cpu than
they should be - the architecture fix for that would be to not be a full
browser.

The problem I have is they lack basic app behaviors from the platform. My
experience is mostly for the Mac, but my experience using vscode on Linux has
been similar.

But here we go, for a Mac:

* cmd-e/f/g are so wide, not just app wide. Vscode goes even further and seems to achieve per-view behavior.

* document editors and viewers are expected to have an icon for the file being edited, either in the window or in the tab. That is a draggable link to the file, and a drop down on right click for the directory hierarchy.

* drag and drop of files into and out of the windows don’t work

These are basic behaviors that even the simplest apps manage to get right on
OS X, yet no electron apps seem capable of meeting this low bar.

------
adgasf
People love to bash Electron, but what is the alternative?

Is there any other platform that provides:

\- Support for the 3 major desktop platforms from one code-base;

\- A decent choice of high-level programming languages (there are excellent
compile-to-JS options now);

\- Reasonable tooling and community support;

\- MIT (or similar) license

~~~
danieldk
Qt. Supports Linux, macOS, and Windows. Supports at least one high-level
programming language very well (Python). Has good tooling and a lot of
support.

It's LGPL, which is fine for most cases. But you could always buy a commercial
license.

------
grecht
I use VS Code and it never felt sluggish. But it’s probably one of the best
Electron apps out there.

Honestly, if I had to develop a Desktop app today and wanted it to be cross-
platform, I’d probably use Electron. No need for hacky workarounds like in a
web app to make it run on every major browser.

~~~
0xffff2
I use VS Code too and it's extremely sluggish compared to a text editor like
Sublime. I use it only because the plugin experience is much better than
Sublime and the responsiveness is infinitely better than JetBrains' products.

~~~
hackandtrip
I find it not fair to compare VSCode to JetBrains' product: one of them is an
IDE, the other one is an editor, different features and different targets!

~~~
0xffff2
I disagree. VSCode is really a hybrid product. With plugins, it does
intellisense and debugging, which are really the two major value-add features
of an IDE for me. It's still light years faster than IntelliJ (and light years
slower than Sublime). I switched from IntelliJ to VSCode and it minimally
affected my workflow, so they're objectively not different targets in that
regard.

~~~
winrid
Are there are VS Code intellisense plugins that beat Webstorm?

------
jlarocco
I honestly don't know why people waste time building Electron apps.

It's the worst possible combination. All of the downsides of web apps (poor
performance, memory use, poor integration, etc.) and native apps (security
problems, hard to update, etc.), without the advantages of either one.

Why would I want to download your specially packaged browser, without adblock
or uMatrix or any of that, just to basically view a website anyway?

~~~
joefourier
Ah, but you don't waste time, that's the whole point of the idea. You just
repackage your existing web app and distribute it as a "native" app, no effort
required. You also have a cross-platform application with no extra work (the
auld "Write once, run anywhere" slogan), and can use web developers instead of
people who know QT/Java/what have you.

Then the user can run your chat/music/text editor in the background, have it
appear in the taskbar, and start boot, at the cost of requiring a few
gigabytes of RAM and 25% CPU utilization while idling.

Personally I'd rather have Progressive Web Apps but for some reason, those are
still in an awkward stage.

~~~
steve1977
> and can use web developers instead of people who know QT/Java/what have you.

Is that supposed to be an advantage? ;)

------
chasd00
I've never noticed Electron apps negatively impacting my computer. I use Slack
all the time and I don't notice a difference when I have it running vs when i
don't. Do most people not like Electron because the number seems high or does
it negatively impact their computer in some way? (I have a MBP with 8 gig RAM,
that doesn't seem out of the ordinary)

~~~
yoz-y
As for impact it depends. Slack is not that bad except that it is slow (for
example switching teams was sluggish when I was using it). But when I run
Slack, Skype, Insomnia and VS Code at the same time I definitely saw the
impact. I had 16Gigs of ram but half of that was eaten by a VM all the time.

------
edoceo
I am an electron hater but this is a really good setup. Server reloading with
that debugger is rad. I'm going to use these methods with a platform I don't
like.

------
geodel
Well to me it is thing that should not be done at all, instead of doing it
diligently.

I will put this in category of 'The secret of good user tracking on web', 'the
secret of doing quality journalism on ads supported model' or 'the secret of
nuanced political debate on Twitter' etc.

------
vijaybritto
Unrelated: I really hope software like [https://github.com/revery-
ui/revery](https://github.com/revery-ui/revery) becomes mainstream!

This node IPC debugging technique is pretty nice!

~~~
seddin
What's the size of the built binaries?

------
langitbiru
The hate for Electron is strong in this thread.

For Electron haters, here are the alternatives: OpenJFX (some people hate
Java), Qt5 (it can be pricey in some situations), wxWidgets (not popular
enough?).

However, I have a lot of hope for Flutter in desktop. I hope the developers of
Flutter framework can pull off the challenge.

In my case, for opensource projects, I definitely use Qt5 (using PySide2). But
for proprietary projects, I have to admit that most likely I will choose
Electron.

~~~
Narishma
AFAIK, as long as you don't modify Qt itself, you can use it just fine for
proprietary projects without having to buy a commercial license.

------
michannne
I'm building an application using Electron and I've found the majority of
memory consumption occurs when instantiating new components. When using a UI
framework like Material, this can happen frequently, such that the simple act
of hovering over a menu and showing an indicator can cause an increase of 3 MB
of RAM. I love Electron, it allows me to create applications in an intuitive
way using a language meant for building UIs, rather than slapping a library on
a native codebase, and I can deploy it wherever Chromium is supported, so I'd
like to make it efficient, wherever possible.

Two solutions I have found during my development:

1) Keep your components light. Most of what I used from Material can be done
completely with raw HTML and CSS in a simpler fashion without much going on in
terms of state, so I created my own components that serve my purposes. A lot
of libraries and frameworks are heavy because they are used on webpages viewed
by multiple different browsers and require complex logic to work across
different environments. Electron sandboxes your code in Chromium + node, you
code only for 1 browser engine, so I hope more devs take advantage of that
fact.

2) Load what you know you need in the beginning, and keep your cache to a
minimum. Most Electron apps do not have view transitions, they are built as
SPAs. One of the downsides of this is that you need to be mindful of your
cache since it is not cleared when you display a new component. Clearing the
things that don't matter to the view or data has been essential in keeping my
memory footprint small.

With a large app that does many things and loads many views, I'm able to keep
the RAM usage to under 200, most times around 150, which, while larger than
something like Excel running idle, is a small price to pay to have intuitive
design features and access to a large and constantly growing library of
reusable components and packages.

------
imtringued
The type of developer that chooses Electron isn't going to care about
squeezing out the best performance possible. They already made a conscious
trade-off to sacrifice performance and memory usage in exchange for
productivity. They won't do some hacky things like use Rust instead of nodejs.

------
fabiospampinato
It sounds like a generally good approach for keeping the UI process responsive
at all times. I wonder if the serialization cost behind all those IPC calls
becomes an issue at some point, especially when passing large structures back
and forth, have you found this to be an issue for your use case?

~~~
jlongster
I haven't noticed an issue - the only alternative would be to block the
renderer and do it in the same process. The IPC uses a local domain socket
which is very high performance (better than a web socket) so any overhead is
quickly made up for with UI responsiveness. There may be specialized cases
where it is a problem and you'll have to figure something out.

~~~
codesushi42
How do you secure the socket and prevent a malicious process from connecting
to it?

------
skrebbel
I feel like the key idea here is somewhat unrelated to writing Electron apps.
It's that you can set up any Node server app to run inside an Electron window
during development and then you get cmd+r and all the devtools for free. Kind
of like a node inspector on steroids. Pretty nifty!

------
ptx
If you need a background process to call Node APIs because "it's the only
place where it's safe to access them", what unsafe way is this meant to
contrast with? Does Electron normally (but unsafely?) call Node APIs from the
browser process?

~~~
jlongster
You can enable "node integration" with any renderer process and call node from
their. But you definitely should not enable it in your primary renderer
process if any untrusted code is running their (if you pull in any JS from
anywhere else)

------
chrisweekly
Thanks for sharing! Your post is full of things that might seem obvious in
hindsight, but all too likely to be ignored absent a compelling writeup like
yours. Bookmarked the linked repo, will revisit w/ my next Electron app.

------
fmakunbound
What are the 83 threads used for in that trivial budgeting application?

------
smith-kyle
I made something similar a couple years ago: [https://github.com/smith-
kyle/electron-process](https://github.com/smith-kyle/electron-process)

But I love the addition of defaulting to a node server for lower memory usage.

The Atom editor (the first Electron app) has slowly been rewriting a lot of
their modules in C++ for speed and lower memory usage, binding to them through
NodeJs. Kind of ironic since GitHub created Electron to build desktop apps
using web technologies.

------
UtahDave
Vote for Linux support in Actual here:

[https://trello.com/c/A7XzJgJX](https://trello.com/c/A7XzJgJX)

~~~
jlongster
Linux support was added in 0.0.99! See here (and download it):
[https://github.com/actualbudget/releases/releases/tag/0.0.99](https://github.com/actualbudget/releases/releases/tag/0.0.99)

Somehow that card didn't get moved to done, sorry! Let me know if it doesn't
work.

------
ulisesrmzroche
The argument about bloat is so weak tho. Engineering about trade-offs. If you
can’t tell why people use Electron, you’re not a good engineer.

------
falcolas
IMHO, good electron apps feel and behave like native apps. Or, in the worst
case scenario, they feel like an equivalent web app.

Specifically - I should not have to think of having to “ctrl-R” for a desktop
application.

Good electron apps do exist, but they feel like a vast minority. Most just
feel like a bloated version of their web application.

~~~
jlongster
I completely agree! Are you referring to the "ctrl-r" to reloading the server
in the article? That's only for development - the user never has to refresh
the app like that of course!

~~~
falcolas
I think you’re saying “a user should never have to refresh the app”. Because
ctrl-r has returned completely borked applications back to working.
Specifically, I’ve had to use it almost daily to make slack recover from a
freeze.

~~~
btsheehy
I'm not sure what the point is, here. Is it that Electron apps can lock up or
crash? That they can be refreshed seems pretty immaterial, given that any
application in any language can crash

------
sys_64738
My simple rule of thumb for reducing the memory usage of Electron apps is to
not run any of them. Problem solved. It's like why I never ever installed java
which was subpar garbage. Gosling has a lot to answer for.

------
z3t4
I would just skip Electron and make a PWA (add2desktop) instead.

------
emptyparadise
I miss native apps.

------
bfrog
The secret is don't use electron.

------
ionised
I find the problem lies with the trade-off you are making.

You are making your life as a developer easier in exchange massively
increasing the resource requirements and battery usage on end-user machines.

It's just bad practice and Electron encourages it.

I feel like if we ever want to be taken seriously as a profession the way
structural or mechanical engineers are for example, then efficiency and
reliability need to be primary considerations, otherwise we are basically
making toys.

~~~
jlongster
I would easily forego the niceties explained in the article if it meant there
were something better.

The main reason to use Electron is that I can have happy macOS, Windows, and
Linux users. Apps that focus on a single platform are exclusionary.

~~~
krzyk
You can have that already - use web, the real one, not Electron. Everyone then
can use their favorite browser for your app, not forced to use Chromium.

And if you want to make an efficient desktop app, look at telegram source
code.

~~~
jlongster
The web's offline support sucks, and don't tell me to use service workers.
Actual is a truly offline 100% local app. Most users love that they can simply
launch a desktop app and it always runs no matter their network connection.

------
IloveHN84
First rule: if you need Electron, change your requirements/design and move to
something more cross platform like Qt or libui/C++.

~~~
michannne
You forgot a number of additional tips:

\- Hire a C++ programmer

\- Learn C++

\- Adapt knowledge in your current language of choice to C++/Python

\- Find a designer who can use Qt

\- Adapt common tools normally found in npm to C++

\- Rewrite your application logic to run in C++

Should be simple for any dev to do considering the pay off is lower RAM and
"native" look and feel

------
makkesk8
Some people seem to think that unused ram is good, quite the contrary
actually. If you have 50 of these apps running doing work while playing a game
while having a pc from 10 years ago, then I can actually see a problem. Laptop
and battery-driven devices is a whole other matter though.

I like to think the reusability and speed of development with electron is just
terrific and is a trade-off that is worth it in the end.

~~~
falcolas
Unused RAM _is_ good. It lets the OS do things like pre-fetching and caching
disc reads. That is, it speeds everything up to not be using all of your RAM.

Plus, when you do fill your RAM, you have to start contending with swapping,
which slows everything down significantly.

~~~
makkesk8
Swap is not enabled by default by any OS that I know of. And I doubt any OS
requires you to have several gbs free in order to work smoothly.

My point being is, we are not stuck with 2 gbs of ram anymore and like games,
apps will scale to use more resources for ease of development or better
features.

~~~
michaelmrose
Literally every major OS in existence has swap enabled by default. Linux, Mac,
windows.

The alternative is for things to start crashing when you run out of memory
rather than swapping out.

~~~
0815test
> Linux, Mac, windows.

But not Android, iOS or iPadOS. (And for good reason - these OS's run on
devices that use bottom-of-the-barrel flash storage and can't sustain the
wear-and-tear that comes with using swap.) That's not "literally every major
OS"!

~~~
falcolas
Instead, they suspend applications to the self-same flash storage when the the
application is not being actively used and there is memory pressure.

Doesn't seem a lot different from swapping the memory to disc until its
accessed again.

Not to mention, it's kinda irrelevant to a discussion of electron
applications.

~~~
0815test
They don't "suspend applications". They can _prompt_ an application to
serialize an image of its "core" memory for storage on the flash media and to
subsequently restore its state from the serialized memory dump, but very few
applications are written to do the job properly.

