Skip to content
DevMeme
2698 of 7435
When killall electron kills your editor too
Tooling Post #2981, on Apr 18, 2021 in TG

When killall electron kills your editor too

Why is this Tooling meme funny?

Level 1: Same Name Problem

This is like trying to remove one bad toy from a room by yelling, "Throw away every toy named Electron!" Then you realize your favorite pencil box had the same name, so it gets thrown away too. The funny part is that the developer tried to fix one frozen program and accidentally closed the very tool they were using to make it.

Level 2: Kill the Wrong Thing

Electron is a framework for building desktop applications using web technology like JavaScript, HTML, and CSS. Apps such as many code editors and chat tools have used this approach because it makes desktop development feel more like web development.

killall is a command-line tool that terminates processes by name. A process is a running program on your machine. If you tell the operating system to kill everything named electron, it may shut down more than the one app you were thinking about.

That is why the third panel, editor closes, is the punchline. The developer intended to close the frozen app they were building. Instead, their code editor closes too, because it is also an Electron application. For a junior developer, this is one of those lessons where the shell teaches precision: commands are powerful, but they do exactly what you asked, not what you meant.

The meme also points at a common early-career surprise: development tools are software with their own dependencies, bugs, and runtimes. Your editor feels like part of the workbench, but it is still just another app running on the same machine.

Level 3: Process Table Roulette

The joke lands because the plan is technically valid and operationally reckless in exactly the way developer tooling often is. The visible sequence is:

electron app I'm writing freezes run "killall electron" editor closes editor closes

killall electron does not know which Electron app offended you. It just looks for processes matching the name electron and terminates them. That is satisfying when the frozen desktop app is the only Electron process around, but modern developer workstations are crowded with Electron-based tools: editors, terminals, chat clients, API clients, database GUIs, and that one internal dashboard someone shipped as a desktop app because browsers were apparently too direct.

The humor is the blast radius. The developer is writing an Electron app, hits a freeze, reaches for a blunt CLI process management command, and discovers that the editor was also part of the same runtime ecosystem. Gru's sideways stare in the fourth panel is the moment the dependency graph stops being theoretical and becomes a blank editor window.

This is also a quiet jab at developer experience trade-offs. Electron is popular because it lets teams build cross-platform desktop software with web technologies, which is enormously productive. The cost is that many unrelated apps share similar process names, memory profiles, update mechanisms, and failure modes. In the clean architecture diagram, your app and your editor are separate tools. In the process table, they are cousins wearing the same badge.

The anti-pattern is not "Electron bad" so much as "global hammer meets local problem." A better response would be identifying the specific PID, using a more precise process name, killing the child process launched by the current project, or restarting through the dev server. But the meme is funny because every tired developer has chosen speed over precision and then watched the terminal prove that it follows instructions literally.

Description

A four-panel Gru planning meme shows Gru presenting cards beside a clipboard, then realizing the plan has a side effect. The visible text reads: "electron app I'm writing freezes", "run \"killall electron\"", "editor closes", and again "editor closes" as Gru looks sideways in regret. The joke is that many developer tools, including code editors, are Electron apps, so a blunt process-kill command meant for the frozen app also terminates the editor used to write it. It captures the tradeoff of Electron-based desktop tooling: convenient cross-platform UI, shared runtime blast radius.

Comments

69
Anonymous ★ Top Pick The real dependency graph is your process table: kill one runtime, prune half the dev environment.
  1. Anonymous ★ Top Pick

    The real dependency graph is your process table: kill one runtime, prune half the dev environment.

  2. @sashakity 5y

    it's simple, don't use electron

    1. @batuto 5y

      Don't use vs code

      1. @sashakity 5y

        that too

    2. dev_meme 5y

      I'm on board with that, but sadly it's not that simple. They can't always use qt5 or gtk3. Also, it's just really easy to build an electron app. It won't be a good app, but it will be built incredibly fast, and therefore also cheaply since they have to pay the devs less.

      1. dev_meme 5y

        But it actually COULD be a good app, the point that typically those managers who prefer to use electron just don’t really want to invest time in client performance (while app works at least somehow)

        1. dev_meme 5y

          absolutely. My stance is that no matter what framework they could've used, the app would've been garbage either way.

      2. @AmindaEU 5y

        GTK4* 😝

        1. dev_meme 5y

          GTK4 isn't really stable yet & there's a lot of changes I don't like already. I still need to get more info on that, so educate yourself I guess.

          1. @AmindaEU 5y

            👍🏻

      3. @sashakity 5y

        why not qt? i'm interested

        1. dev_meme 5y

          not as platform independent as electron afaik

  3. dev_meme 5y

    yes, but you need to compile your app for every system separately. With electron, you can just write everything in js.

    1. @sashakity 5y

      yes thats how... making a program works

    2. Deleted Account 5y

      isn't it actually better?

      1. dev_meme 5y

        certainly

      2. Deleted Account 5y

        i mean, imagine catching an os-specific bug early than having an unreproducible bug at runtime

  4. dev_meme 5y

    I'm not saying I like it & there are just certain system-specific quirks that can be avoided by just writing in js *eugh*

  5. @sashakity 5y

    plus im pretty sure a lot of electron apps do have actual executable components to them

    1. dev_meme 5y

      some of them. The ones that are actually properly written.

      1. @sashakity 5y

        but honestly at that point why not just make a proper program

        1. dev_meme 5y

          idk man, because they started with a sloppy codebase and don't want to rewrite everything? The only electron-based program that's any good I've seen is discord, and even that is questionable.

          1. @sashakity 5y

            probably lole

  6. dev_meme 5y

    You would do that. Microsoft not so much.

    1. Deleted Account 5y

      microsoft way is to use c# and teliing everyone to fuck off

      1. dev_meme 5y

        C# is mostly platform independent nowadays, but no, Microsoft uses electron for their newer stuff now.

        1. Deleted Account 5y

          it sucks tho, their gui still looks like shit (even natively on windows too imo)

          1. Deleted Account 5y

            not that i care much about gui, but still

  7. @sashakity 5y

    discord started as a browser based thing too

    1. dev_meme 5y

      telegram had the web client before the desktop one as well afaik, and they still managed to use a proper library.

      1. @sashakity 5y

        they started with the web client? huh

        1. dev_meme 5y

          They started with the android app, then had the web client and after that I lost track.

          1. @sashakity 5y

            ahhhh i see

          2. dev_meme 5y

            I know telegram-desktop started as an unofficial client though

  8. @sashakity 5y

    youd think theyd actually update it with features

  9. @sashakity 5y

    caching tiem

  10. dev_meme 5y

    aye, it doesn't clear the cache properly. I'd say someone should open an issue, but they're busy adding new features :/

    1. Deleted Account 5y

      it's been open for like 1 year already

  11. Deleted Account 5y

    that's c++ memory leaks being c++ memory leaks

    1. dev_meme 5y

      I don't think they're actual memory leaks. Just badly written caching.

  12. Deleted Account 5y

    btw rust can leak memory too

  13. @sashakity 5y

    rust be like

  14. @sashakity 5y

    hello world? thattl be 2 megabytes

  15. @sashakity 5y

    it tends to make wierdly big executables

  16. Deleted Account 5y

    nah, in rust you can go Box::leak and it won't even be unsafe

  17. Deleted Account 5y

    python segfault is easy

    1. dev_meme 5y

      ye

    2. Deleted Account 5y

      and java is famous for being a memory hogg

      1. dev_meme 5y

        aye. I believe someone in here explained why that is, but I forgot.

  18. @sashakity 5y

    oh right

  19. @sashakity 5y

    200kB

  20. @sashakity 5y

    i can never remember lol

  21. @sashakity 5y

    yea definetly

  22. Deleted Account 5y

    you can't leak memory if there is no dynamic memory allocation

    1. Deleted Account 5y

      you can do void loop_forever(){ while (true) { printf("loop\n"); } } int main() { int leaking_memory[8196]; loop_forever(); }

      1. Deleted Account 5y

        technically a leak

      2. Deleted Account 5y

        i would argue that isn't a leak

        1. Deleted Account 5y

          a value that will occupy memory while never being used again

          1. Deleted Account 5y

            just because it isn't used, doesn't mean it is unreachable

            1. Deleted Account 5y

              oh, and it isn't technically reachable from loop_forever or any function after it

              1. Deleted Account 5y

                and it's never going to be cleaned up

              2. Deleted Account 5y

                What if code in another thread decides to hack the stack

                1. Deleted Account 5y

                  you need to have the ref, so not a leak anymore

                  1. Deleted Account 5y

                    if you try to reach it through another var an some pointer arithmetic it will be ub instead

                  2. Deleted Account 5y

                    A ref is still stored in your example

                    1. Deleted Account 5y

                      no ref in my example, array is a value

  23. Deleted Account 5y

    in c++ i did delete this; in the destructor of a tree

  24. dev_meme 5y

    flex some more, why dont'cha?

  25. dev_meme 5y

    a fellow german-speaking dude, I see.

Use J and K for navigation