1. 19
    Electron is Cancer rant medium.com
  1.  

  2. 48

    I really, REALLY dislike this kind of splash marketing in blog posts.

    So you’ve surfaced some interesting performance benchmarks that don’t cast Electron in a favorable light. Great.

    CANCER?

    The disease that KILLS millions every year, forcing them to endure months and years of the most extreme agony a human being can experience?

    Electron isn’t cancer, but titles like this are.

    1. 5

      At least he had the self-awareness to subtitle the image leading the post - “Beating a dead horse”

      1. 3

        It’s a broken metaphor at best, and linkbait at worst. Cancer is a random mutation that grows fast, choking out normal tissue. Electron isn’t a mutation, it doesn’t grow, and it doesn’t spread any more than any other framework.

      2. 19

        “Your computer has plenty of RAM, so my app can be inefficient” gets a little irritating when I have to run ten other apps that did the exact same thing.

        1. 15

          As Niklaus Wirth said: “…we do not consider it as good engineering practice to consume a resource lavishly just because it happens to be cheap.”

          1. 2

            That’s not really true though. If your design balances the value you put on performance with, say, safety or debuggability, then performance is bumped by a factor of 10,000 (roughly 20 years of Moore’s Law progress), it makes sense to spend performance budget on the other concerns. To do otherwise is no more “good engineering practice” than saving weight on a bridge by not putting guard rails on it.

            Which is not to say I think Electron is a good or acceptable trade-off. If Javascript were less error-prone than its native competition it might’ve been, but it seems to be the opposite. Which means, I think, that Electron quite literally is a waste of resources.

            1. 5

              As a particular point, JavaScript may be a safe language (and perhaps node + qt would be a good framework), but the browser exposes a shit ton of attack surface and unexpected legacy behavior. I know we all love our lisp code is data and data is code, but it’s a poor model for reliable computing when the barrier between the code in the document and the code about the document is very thin.

              1. 5

                Sure, and I don’t think Wirth would object. It’s the “lavish” part: Vala and GTK is just as if not more portable than Electron, produces faster and smaller code, is type-safe, works well with debuggers, works with the platform’s accessibility tools (disabled users often find Electron apps literally impossible to use), has a consistent UI (consistency between apps is another big Electron problem), etc.

                Why bring along an entire web runtime that consumes tens of megs of memory if you could get the same or more bang for the buck with less?

                (Note that I’m using Vala as an example; this would apply equally to any other desktop framework like Qt, etc.)

          2. 10

            I agree in principle, but sadly users rarely have a choice. Electron developers are the ones developing the only software that does X, and people will just use that because it does X. Electron is eating the lunch of native apps because it covers more market and poisons the well faster than native application writers can write alternatives for.

            1. 8

              A few things that I think are worth considering here:

              • If you’re going to benchmark Atom instead of Electron, then maybe you should refer to Atom in your title. Atom is Electron. Electron is not Atom.
              • Why are you comparing it to cancer? That’s really messed up.
              • If someone is using Electron in ways that don’t make sense to use electron for, maybe call out those projects instead of the core that they run on. Electron has good use cases, and there’s nothing horribly wrong with it.
              • I hear the “Electron Is Not Native” argument a lot, and it really comes down to the fact that the majority of users don’t seem to care. It’s a silly argument.
              1. 13

                I’m tired of these cheap shots at software. I have no particular love for Electron (I have developed with it, it does what it says on the box) but… come, on… it’s not cancer. Cancer doesn’t help you do something, it just kills you. Electron apps at least ostensibly have some purpose. Slack might eat your RAM unnecessarily, but it’s pretty hard to argue that no-one gets any value out of it, or that it being slow makes it utterly worthless.

                if the only cache the developer knows about is function memoization or http caching then well you can’t really expect that application to stay within any sort of cache lines

                I don’t think many programmers working in other GUI toolkits are really worrying about cache lines, either

                as an end user I really could not care less about how easy it was for you to make the application

                The corollary of this, of course, is that if it is a lot harder for some people to make desktop applications there will be less desktop applications. I know a lot of people wouldn’t miss Slack, but I’d sure miss Spotify (which, to be fair, is CEF and not Electron, but it still has the helper gobbling up your RAM). I’d probably miss Insomnia, too, which I think is Electron and is quite a nice Postman alternative.

                I tend to call Electron applications web pages whenever I talk about them, which in turn tends to piss off a lot of web developers but really that’s all they are

                I’d be surprised if this really pisses off web developers, because that’s pretty much why you build a desktop app in Electron and not in Java or QT.

                1. 4

                  What is cancer but a little extra mitosis? Mitosis is certainly a good thing (ask anyone who’s died of radiation poisoning), but sometimes you get a little too much of a good thing and it kinda grows out of control, starving the host.

                  1. 6

                    So you’re arguing that the vast, vast majority of the time Electron is a good thing, and only when there’s some relatively rare mutation/bug does it actually kill your PC. In that case, I agree ;)

                2. 10

                  Any post that calls electron ultimately negative but doesn’t offer a sane replacement (where sane precludes having to use C/C++) can be easily ignored.

                  1. 10

                    There’s nothing wrong with calling out a problem even if you lack a solution. The problem still exists, and brining it to people’s attention may cause other people to find a solution.

                    1. 8

                      There is something wrong with the same type of article being submitted every few weeks with zero new information.

                      1. 1

                        Complaining about Electron is just whinging and nothing more. It would be much more interesting to talk about how Electron could be improved since it’s clearly here to stay.

                        1. 4

                          it’s clearly here to stay

                          I don’t think that’s been anywhere near established. There is a long history of failed technologies purporting to solve the cross-platform GUI problem, from Tcl/tk to Java applets to Flash, many of which in their heydays had achieved much more traction than Electron has, and none of which turned out in the end to be here to stay.

                          1. 2

                            I seriously doubt much of anything, good or bad, is here to stay in a permanent sense

                            1. 2

                              Thing is that Electron isn’t reinventing the wheel here, and it’s based on top of web tech that’s already the most used GUI technology today. That’s what makes it so attractive in the first place. Unless you think that the HTML/Js stack is going away, then there’s no reason to think that Electron should either.

                              It’s also worth noting that the resource consumption in Electron apps isn’t always representative of any inherent problems in Electron itself. Some apps are just not written with efficiency in mind.

                        2. 5

                          Did writing C++ become insane in the past few years? All those GUI programs written before HTMLNative5.js still seem to work pretty well, and fast, too.

                          In answer to your question, Python and most of the other big scripting languages have bindings for gtk/qt/etc, Java has its own Swing and others, and it’s not uncommon for less mainstream languages (ex. Smalltalk, Racket, Factor) to have their own UI tools.

                          1. 4

                            Did writing C++ become insane in the past few years? All those GUI programs written before HTMLNative5.js still seem to work pretty well, and fast, too.

                            It’s always been insane, you can tell by the fact that those programs “crashing” is regarded as normal.

                            In answer to your question, Python and most of the other big scripting languages have bindings for gtk/qt/etc, Java has its own Swing and others, and it’s not uncommon for less mainstream languages (ex. Smalltalk, Racket, Factor) to have their own UI tools.

                            Shipping a cross-platform native app written in Python with PyQt or similar is a royal pain. Possibly no real technical work would be required to make it as easy as electron, just someone putting in the legwork to connect up all the pieces and make it a one-liner that you put in your build definition. Nevertheless, that legwork hasn’t been done. I would lay money that the situation with Smalltalk/Racket/Factor is the same.

                            Java Swing has just always looked awful and performed terribly. In principle it ought to be possible to write good native-like apps in Java, but I’ve never seen it happen. Every GUI app I’ve seen in Java came with a splash screen to cover its loading time, even when it was doing something very simple (e.g. Azureus/Vuze).

                            1. 1

                              Writing C++ has been insane for decades, but not for the reasons you mention. Template metaprogramming is a weird lispy thing that warps your mind in a bad way, and you can never be sane again once you’ve done it. I write C++ professionally in fintech and wouldn’t use anything else for achieving low latency; and I can’t remember the last time I had a crash in production. A portable GUI in C++ is so much work though that it’s not worth the time spent.

                            2. 1

                              C++ the language becomes better and better every few years– but the developer tooling around it is still painful.

                              Maybe that’s just my personal bias against cmake / automake.

                          2. 6

                            Electron is popular because is has little (no?) competition in its space. What are the other tools that provide the same level of code reuse between platforms, a UI toolkit that many developers already know how to use, and is free? Electron’s popularity is more the result of limited adoption of other cross platform tools than it is an endorsement of its particular approach.

                            This is where you end up when the big platform developers are not interested in supporting other platforms. See also the rise of React Native for similar reasons in the mobile space.

                            I find it a little funny that the argument used against many cross platform toolkits over the years was that they weren’t “native enough”, and now we are seeing more and more desktop apps built on top of a web browser.

                            1. 4

                              I guess we all miss the days when your only choice was a windows-only app.

                              1. 4

                                And yet the same people from Medium and HN tell everyone that desktop is dead and you shouldn’t consider learning how to make desktop apps. Yes, desktop app development sucks, with C/C++/ObjC and no sane cross-platformness. It stuck in 80s. Everyone is gone to gold rush of web apps, PaaSes, mobile apps, blockchains and superintelligent killer robots.

                                1. 2

                                  C/C++/ObjC

                                  here’s the thing: there are loads of other programming languages that have FFI to call C functions (Python, Ruby, anything on the JVM, anything on the CLR, JavaScript via node, others), and if you can do that you can work with ObjC (and, with some bridging, C++). So the choice is not “JS to use Electron, C to use native”.

                                2. 3

                                  I think people need to accept that this ship has sailed. Electron is here to stay, and people will build more and more apps on top of it. This is the reality, and it’s unlikely to change in the foreseeable future because it’s by far the easiest option of writing and maintaining cross-platform applications.

                                  My view is that it would be far more productive to focus on how Electron runtime can be improved. Reducing the footprint for Electron would improve all the apps built on top of it for free. If you’re not happy with the bloat then try and help to figure out how to reduce it. Moaning that Electron is cancer isn’t helping anybody.

                                  1. 3

                                    Yes, and it’s as good as we’re going to get if we insist on everything being free.