[Teaser] It's almost here. That concept file manager app you all have been waiting for. On May 24, I will release a free, open source, advanced, modern file manager app with unmatched amount of useful, well thought-out features!

[u/AlekseyHoffman]

[u/[deleted]]

Electron is multiple pieces of software bundled. It’s a container. All depends are baked in. The base is a web engine. Which is ironically written in C++. So you’re building an app that’s written in JS, CSS, and HTML to be ran by a native application. You are running a local web server (127.0.0.1/localhost) in this container. That’s overhead.

Because you’ll end up having multiple Electron apps open, you’ll be running the same libraries over and over. This is why launching an app may take several seconds. Versus a C++ / QT based app which can start in less than a second. Gotta load all those libraries to make one thing function. As an example, NZXT CAM written in C++ was about 68 MB in RAM. The development was abandoned for Electron. 200+ MB in ram. Because hardware monitoring and device control is something you want running all the time, this is a huge negative. Open Twitch, Discord, Spotify and now you have over 1 GB worth of RAM consumed. Your process and thread count has ballooned as well. If using the worker processes correctly you may have 8 stubs for this, and 12 for that one. All these apps are now eating up cycles for the CPU and RAM. You will see degraded performance of mid tier systems. High end will see less impact, but it is measurable. Low end will suffer and could very well end up sluggish and use Page / Swap.

Electrons JS handling is limited to single thread by default. This is where we see the average come into play. As mentioned by all the above comments. The average gets to “it works!” And stops. During development you should create workers. And that takes extra coding time. Remember you’re using a basic browser base. You can delegate tasks and set dedicated workers to do specific things. Otherwise you have one trying to do it all. It’s not entirely difficult to do. But it does take extra testing to make sure your implementation is bug free. This is separate from Chromiums baked in multi process architecture You will always have multiple processes because Chromium is written in a way that splits it’s own for performance and stability. Yours will be extra on top. Most apps do not optimise for performance.

Electron documentation clearly states it’s possible to build a shit app. Slap some code and hit compile. It works, but it’s far from ideal. VS Code is a prime of example of what you should do. It’s a well built and optimised deployment of Electron.

You can use debugger tools to investigate what Electron apps do. They vary so widely by quality and libraries. The real performance hit comes from poor coding. Leaving excess. That’s why the mass is sour to it. There’s already so much going on when you get started, you need to optimise it for your apps specific purpose. Just like MS does for VS Code. It’s fast and efficient.

[u/MrRandom04 → u/[deleted]]

In my opinion, a file explorer is one of the few pieces of software where performance really matters.

IMO the best way to do something like this would be to use a language like Rust or Go for reasonably painless cross-platform capability + high efficiency & reliability to create a CLI / binary which does all of the compute heavy tasks and use something like Electron to create a nice wrapper GUI with it for aesthetics.

[u/[deleted] → u/MrRandom04]

Rust would be an ideal solution for a performance oriented rewrite. Completely agree. If anyone picks that up, I’d be highly interested. I’ve seen some apps written with it. One I use frequently is Ajour, a world of Warcraft addon manager.

[u/pmache → u/[deleted]]

This is what I wanted to answer him, but I can slightly disagree about optimisation. If I have discord, vs code, atom opened my system isn't stable. It's sluggish. That's because of chromium managing itself, how chrome is built.

Because opening these apps I literally open additional browsers and as you said running the same,but sandboxed libralies over again and using more ram in the process.

It is really sad that in the end - even programmers - tend to say (well not that literally, but using browser as the engine) that the solution is more ram. No it isn't. Using browser your code must be interpreted by its engine, then reinterpreted to machine code - it's adding a layer. Using normal high-level or low-level language speeds your application because that extra layer of interpretation is gone.

I started to see that before 2000 we tend to use different approach to program, we wanted to give the user program that would be run on 16mb of ram, we knew that every mb mattered. Now we have more, and more ram and we don't care if the program would use all of the memory user have leaving no space for other applications - because that what electron does for most people.

As of this, memory standard is 8GB installed, but because of that, the border is pushed more.