Why in the desktop application Slack, most likely, there is a driver for the Xbox game controller and what is really bad about using Electron to build desktop applications.

In the screenshot below, according to the profiler, the Slack consumes almost all the processor resources. I wonder what he does there?

')
The process was launched in the background when it happened. I didn't even interact with Slack - I was at the meeting. And I noticed this only because of the noise of the cooling system of my laptop. Restarting Slack this time solved the problem.
But this is normal for Slack. In the background, Slack often consumes 5% of the processor. What is he doing? I have no idea.
I bet that the Slack development team doesn't know either. How many lines of code did they have to write for their client to work? I think in the region of 50 thousand. Perhaps 100 thousand. But Slack is not a native application. Or not the usual native application. It works on top of
Electron , which means that when you download it, you actually download a full copy of Google Chrome (
rather, Chromium - approx. Lane ). Chrome at the time of writing contains
15 million lines of code that are not comments. The Slack code itself is less than 1% of the load.
Chrome itself is a hog. He is big and complicated. It uses RAM and the processor as if no one else claims them and greatly reduces the battery life.
You can think of Slack as a small JavaScript program that runs inside another Chrome operating system (virtual machine) that you run to, in effect, use an IRC equivalent. Even if Chrome itself is already running, each application on Electron expands its own, additional copy.
And calling Chrome the operating system is not an exaggeration. By the number of lines of code, Chrome is almost the same size as
the Linux kernel . Like the Linux kernel, it has an API for various hardware, including OpenGL, VR, MIDI. It contains a built-in copy of SQLite, a memory management system and its own task manager. On macOS, it even has a USB driver for the Xbox 360 game controller. (I know that it is there because I wrote it. Sorry.)
Does Slack contain my code for an Xbox controller? Does the Slack team know about this? Does anyone know about this? Slack takes 160 MB disk space. These are about 70 uncompressed copies of the Lord of the Rings. Other Electron applications on my computer are Spotify (200 MB) and Atom (260 MB). I first installed Linux using floppy disks. It will take 450 floppies to write these three simple applications. Together, they weigh like a desktop Ubuntu distribution. Which, I think, contains an IRC client, text editor and music player. Full-fledged operating system,
user environment and web browser.
You will say that disk space is now worth nothing. Yes, but not RAM. The new shiny MacBook Pro comes with 8 GB of RAM by default. Due to battery life, you
cannot purchase a model with more than 16 GB. And right now Slack is somewhere between 300 MB and 1 GB in the memory of my laptop:

Come on. This application is for text sharing.
Another thing that is always lacking is the battery charge. Modern processors retain charge by stopping whenever possible (when there are no tasks). Curse power management is a program that constantly uses the processor for only a couple of percent. They force the processor to constantly wake up, accelerate and stop again. This is the perfect way to destroy precious battery power. If someone has time (just leave them running) - I would see how much Spotify is, Slack and Atom reduce the battery life on modern laptops. This is incredible.

And no, Spotify does not play music. He's just ... running. Makes his mysterious Chrome affairs. And he also uses a few percent of the processor. Just to exist.
(At the time of writing this note, Chrome decided to take 100% of the CPU resources in retaliation. In the embedded task manager, this was the mysterious Browser process. Thank you, Chrome.)
To be honest, JavaScript outside the browser is not a problem. In fact, I think that the API that the modern web provides is much better than the existing operating system APIs. We must use them.
But we need to find an opportunity to use these new paradigms (React and his friends) on desktop platforms without having to run more damn copies of Chrome. I’m just not so interested in your application to justify the launch of the next Chrome instance. It’s easy for a developer to fall into the trap of feeling that your application or website is a gift to humanity and the most important thing they can do. Why not take advantage of redundant resources? We need to deal with this way of thinking. Such a path leads to a world where we cannot have good things. This path leads to a world where the batteries of our laptops must grow to provide power for the processors to do even more useless work. This way leads to the return of Shockwave Flash and heating up in the pockets of the phones, which mysteriously turn out to be discharged when we want to use them. To paranoia in relation to the charge of the battery and closing applications as soon as we finished working with them. (I'm looking at you, iTunes and Mischief.)
Just tell Electron NO.
Developers, do not let your friends write applications on Electron. If you want to use JS and React - use
React Native . It's like Electron, but you just don't have to distribute a copy of Chrome to all users and run another copy of Chrome to use your application. It turns out that modern operating systems already have good and fast UI libraries. Use them, boobies!
Another sad fact is that even many developers have no idea what is happening in their computers. They use Slack, but do not know how greedy it is. It is your responsibility as a developer to know all this. Practice. Learn the tools for profiling. Use
iStatMeters or one of the free analogues. You cannot improve what you do not measure.
Maybe we should buy slower computers to feel the pain.
Facebook deliberately limited the speed of the Internet in its offices once a week in order to arouse sympathy for its users in other third world countries (Khe-Australia-Khe). Maybe, as developers, we should also do this with our computers, for example, make the code work much slower than usual in order to arm ourselves with intuition regarding performance. A couple of years ago, I left my laptop at work for a long weekend. Instead of going after it, I decided to connect my Raspberry Pi (damn slow 1st generation) and use it for development. Suddenly, a lot of operations that were carried out instantly on my usual i7 laptop became terribly slow. And I spent the weekend to make my workflow smoother. All these performance tweaks are also transferred to conventional devices. Reducing the startup time from 5 seconds to 2x on the Raspberry Pi felt like an incredible jump. This fix just became a jump from 0.5 seconds to 0.2 or something like that. It is still very noticeable to the user. A launch time of 0.5 seconds is short enough to miss this fact during development, but a drop to 0.2 obviously feels much faster.
Users : Please complain about slow programs. In the yard in 2016 (
... - approx. Lane. ). We carry supercomputers in our pockets. For programs it is unacceptable to be slow.
Developers : Performance matters. Memory matters. I don't care that you're the most attractive girl on the dance floor, Slack. I close you as soon as I leave the office. I remove you from the computer as soon as I have the opportunity. Slowness is a bug. The fastest program is the one that you do not run. So stop embedding the whole Chrome in your application.
And all of you web developers: Learn C or Rust or something like that. Your programs
run on the computer . Until you know how the computer works you are doomed. And get out of my lawn until you find out!
* shakes his fist *And yes, read about
the obesity crisis sites (
translated into Habr ). This is very funny. And very sad. And very vital.
Edit: Spotify actually uses the Chromium Embedded Framework instead of running via Electron. But he still embeds Chrome. I did not know about it when I wrote the article, but I don’t take my words about the ultimate performance.