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
69Comment deleted
The real dependency graph is your process table: kill one runtime, prune half the dev environment.
it's simple, don't use electron Comment deleted
Don't use vs code Comment deleted
that too Comment deleted
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. Comment deleted
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) Comment deleted
absolutely. My stance is that no matter what framework they could've used, the app would've been garbage either way. Comment deleted
GTK4* 😝 Comment deleted
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. Comment deleted
👍🏻 Comment deleted
why not qt? i'm interested Comment deleted
not as platform independent as electron afaik Comment deleted
yes, but you need to compile your app for every system separately. With electron, you can just write everything in js. Comment deleted
yes thats how... making a program works Comment deleted
isn't it actually better? Comment deleted
certainly Comment deleted
i mean, imagine catching an os-specific bug early than having an unreproducible bug at runtime Comment deleted
I'm not saying I like it & there are just certain system-specific quirks that can be avoided by just writing in js *eugh* Comment deleted
plus im pretty sure a lot of electron apps do have actual executable components to them Comment deleted
some of them. The ones that are actually properly written. Comment deleted
but honestly at that point why not just make a proper program Comment deleted
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. Comment deleted
probably lole Comment deleted
You would do that. Microsoft not so much. Comment deleted
microsoft way is to use c# and teliing everyone to fuck off Comment deleted
C# is mostly platform independent nowadays, but no, Microsoft uses electron for their newer stuff now. Comment deleted
it sucks tho, their gui still looks like shit (even natively on windows too imo) Comment deleted
not that i care much about gui, but still Comment deleted
discord started as a browser based thing too Comment deleted
telegram had the web client before the desktop one as well afaik, and they still managed to use a proper library. Comment deleted
they started with the web client? huh Comment deleted
They started with the android app, then had the web client and after that I lost track. Comment deleted
ahhhh i see Comment deleted
I know telegram-desktop started as an unofficial client though Comment deleted
youd think theyd actually update it with features Comment deleted
caching tiem Comment deleted
aye, it doesn't clear the cache properly. I'd say someone should open an issue, but they're busy adding new features :/ Comment deleted
it's been open for like 1 year already Comment deleted
that's c++ memory leaks being c++ memory leaks Comment deleted
I don't think they're actual memory leaks. Just badly written caching. Comment deleted
btw rust can leak memory too Comment deleted
rust be like Comment deleted
hello world? thattl be 2 megabytes Comment deleted
it tends to make wierdly big executables Comment deleted
nah, in rust you can go Box::leak and it won't even be unsafe Comment deleted
python segfault is easy Comment deleted
ye Comment deleted
and java is famous for being a memory hogg Comment deleted
aye. I believe someone in here explained why that is, but I forgot. Comment deleted
oh right Comment deleted
200kB Comment deleted
i can never remember lol Comment deleted
yea definetly Comment deleted
you can't leak memory if there is no dynamic memory allocation Comment deleted
you can do void loop_forever(){ while (true) { printf("loop\n"); } } int main() { int leaking_memory[8196]; loop_forever(); } Comment deleted
technically a leak Comment deleted
i would argue that isn't a leak Comment deleted
a value that will occupy memory while never being used again Comment deleted
just because it isn't used, doesn't mean it is unreachable Comment deleted
oh, and it isn't technically reachable from loop_forever or any function after it Comment deleted
and it's never going to be cleaned up Comment deleted
What if code in another thread decides to hack the stack Comment deleted
you need to have the ref, so not a leak anymore Comment deleted
if you try to reach it through another var an some pointer arithmetic it will be ub instead Comment deleted
A ref is still stored in your example Comment deleted
no ref in my example, array is a value Comment deleted
in c++ i did delete this; in the destructor of a tree Comment deleted
flex some more, why dont'cha? Comment deleted
a fellow german-speaking dude, I see. Comment deleted