
Electron is Harmful - wannabedevelopr
https://medium.com/@caspervonb/electron-is-bad-b066108e6c32
======
lewisl9029
Any reason why there's not more support for the Progressive Web Apps standard
on desktop browsers [1]?

It seems to me that many Electron apps these days (most chat apps: Slack,
WhatsApp, Discord, etc) are super-thin wrappers around a web app that don't
actually need the full desktop access offered by Electron (things like local
filesystem access, multi-process execution, multi-window management, arbitrary
node APIs, etc).

They just need a way for users to "install" the app so that it 1) has a
separate shortcut and appears in a separate window from the browser, 2) can
send notifications through the native notifications stack, and use a fallback
on systems where one isn't available, 3) is available for use offline.

The Progressive Web Apps spec has answers to all of these problems, and it
would vastly improve the resource usage model compared to Electron because
each PWA would share the same browser runtime as the user's browser of choice,
which is more likely than not running 24/7 anyways.

I know PWA was designed with mobile apps in mind originally, but it'd be a
shame to limit it to that use case, as there is clearly a lot of demand for
building desktop apps with web technologies, and PWA sounds like an excellent
alternative to the current status quo that's dominated by Electron.

[1] [https://developer.mozilla.org/en-
US/Apps/Progressive](https://developer.mozilla.org/en-US/Apps/Progressive)

Disclaimer: Please excuse me for recycling this old comment, because I do
think the idea is still worth spreading.

~~~
helixten
I think pwa can replace many election app, MS thinks so too they are allowing
them in the app store.

~~~
lostmsu
You mean UWP JavaScript apps?

------
shampto3
Articles complaining about electron pop up at least once every month. One
thing I always see missing from them is a better idea.

The reason electron is prevalent in businesses nowadays is because it's easy
to develop and deliver to customers. Apparently this comes with the price of
performance loss.

Please, the next time you feel the need to use your time to write an article
about how electron is "cancer", try spending a little bit of time
brainstorming a better solution that still fits the bill.

~~~
isaiahg
I haven't tried them yet but I've heard good things about javafx and sciter.
Sciter especially looks like a nice replacement for electron.

~~~
AstralStorm
JavaFX is a actually pretty terrible and underdeveloped. On and off
development and relatively low availability still.

------
danschumann
Disclosure: I am heavily invested in NW.JS(which is similar to electron)
because my app is written in it.

I think this article complains about a problem, but that problem is not
necessarily caused by electron, or electron as a whole. Hear me out. The
memory leaks could be bad code in the application itself. If the memory leaks
are from electron, the problem still isn't electron as a whole, it's the leaks
themselves and should be fixed in the electron code.

> Bottom line; as an end user I really could not care less about how easy it
> was for you to make the application, if it is not working properly it is not
> working properly, being slow on today’s super fast hardware is a bug.

Sure you do, by proxy. If it was easier to write, there will be more and
better features, which you definitely care about. Therefore, the easier to
write, the faster to develop, the more polish and the more value there is.
Again, if the problem is performance, then fix the problem, don't curse the
whole system.

I find many pro's making NW.JS well worth it. I can fix the performance
problems as they arise, and just because developers of certain electron apps
don't address performance, does not mean electron as a whole is bad.

------
wilkystyle
As someone who doesn't particularly like Electron, I have an honest question:
Why all the hate?

Sure, it's slower and less resource-efficient, but is anyone making you use
it?

Yes, it makes it easier to "just use your web developers" instead of hiring
native app devs, but how many of those apps would even exist if the only path
was to develop a native app?

Electron is too slow for me, so I just stick to e.g. Emacs and Sublime text.
Other people get along just fine with Electron, and love VS Code.

Why can't it be fine for people like what works for them?

~~~
mamcx
>Sure, it's slower and less resource-efficient, but is anyone making you use
it?

Yes. Is impossed on the users by the developers using it.

~~~
TheCoreh
You can just use an alternative. If the company you work for is mandating that
you use specific tools, that's a different issue, orthogonal to electron.

~~~
mamcx
Which alternative can be used if the app is made only with electron?

No all apps have multitude of implementations.

------
TheCoreh
Software development is primarily an engineering discipline, so cost and time
to ship must be weighted along with performance. (a classic example of a
trade-off) There's no point in making things more performant than required.
(Except perhaps from an enthusiast/hobbist/academic/curiosity perspective)

If we can ship apps on Windows, Mac and Linux with a near native experience, a
fraction of the cost and benefiting from readily available professionals with
web skills, that's fantastic.

Don't get me wrong, there are several classes of tasks where performance is a
requirement. For these, Electron is indeed not a great choice. However, it's
usually possible to combine it with a more suitable technology to get the
desired results. For instance: VSCode uses ripgrep, a command line tool
written in Rust to provide the fastest possible search experience.

> even the simplest elements like the native menu bar is not available.

Not entirely sure what you mean by that, VSCode has a completely normal menu
bar on both Windows and Mac, and context menus are also native. (At least on
OS X; on Windows it's hard to know what "native" even means for context menus
since UWP apps and Win32 apps have completely different styles for them)

By the way, if there's a market for more efficient competitors to electron
apps, these will flourish and electron apps will "lose", but that doesn't seem
to be the trend.

------
jjcm
The accessibility that electron has makes it invaluable for me personally. I
use it to create tools internally; tools I simply wouldn't otherwise have the
time nor capability to create. In this respect, Electron is extremely helpful,
not harmful.

While I'd certainly agree that a larger company that's pushing out a
production product _shouldn 't_ use Electron, calling it harmful overall is
like calling 3d printing harmful when injection molds / CNC milled products
have a better finish. It's about using the right tool for the right job. Just
because it's slow doesn't mean there isn't value in how quickly you can create
things in it.

------
pacoverdi
> "Well, it works fine on my machine, and I only have 32 gigabytes of ram."

Tangentially, this problem is not limited to Electron. Developers should
regularly test (and why not also build) their software on an old laptop with
2GiB of RAM.

I don't get why I have to bump the maximum heap size of Gradle daemons to 2 or
3 GiB just so they don't barf under their own GC vomit. Building an in-memory
representation of your project's modules and dependencies (even hundreds
thereof) should not take more than a few MiB if done correctly.

------
xpaulbettsx
This again?

~~~
linkmotif
Wow are you some sort of mind reader??

------
curtisblaine
> You are not your end-users, and you if you are a developer most likely do
> not run average hardware.

Then your end users won't buy your product and you will be forced to write a
native application to not go out of business. But if your users can run it and
your product is successful (ie Slack) why do you need to spend more resources
to make it native?

This is like the "supporting IE matters" thing. It does matter if your target
uses IE. If only a negligible slice of your target uses IE, it doesn't matter.

------
_hao
Electron apps could be resource hogs, but VSCode is my favorite editor by far!
I don't care if it'll load 1 second later. Same goes for others like Slack,
Discord, Spotify. I want them to look the same everywhere I use them. I just
don't care if I'll wait a bit longer for the window to show up.

