I would like to debunk some myths around electron (chromium performance) vs "native" performance.
If we talk about desktop, native means everything and nothing.
Originally native means the GUI(s) that are shipped by default on an OS.
There are also cross platforms GUI(s) like QT or GTK, they're not native and native is not an intrinsic quality per se it's a limitation (not being cross platform) and one could say it is better "integrated on the OS" but in practice that doesn't mean a lot (actually people are far more used to web UX than the native default UX (which is inconsistent between their own devices (Android vs windows mainly)))
The default GUI themes from e.g GTK are not flexible enough and modern enough for a startup.
So let's compare GUI(s) that allow customizing UX
Let's debunk the performance myth:
Native or cross platforms GUI(s) are less performant than chromium/electron on a number of metrics
The most user facing performance metric is rendering performance.
GTK use Cairo, QT has it's own renderer, many smaller native GUI(s) use worse or equal renderer.
Chromium develop and use Skia (tuned for the needs of chromium)
Skia is by far the fastest, mature 2D renderer (but I have hope in a fastuidraw backend from Intel), GTK and QT renderers are often ridiculously slower.
Rendering performance is not only tied by that.
Vsynctester.com show that chromium has great support for low, consistent latencies.
QT and GTK have not the human resources nor the expertise to have such a quality assurance and performance.
Hardware makers contribute to chromium, e.g the state of the art NV_path support if you have an Nvidia card.
GUI(s) cannot afford this.
Every potential bottleneck in chromium is decoupled, they parallelize (+ AVX) and make asynchronous almost everything.
They have state of the art scrolling performance.
State of the art networking performance (and will be the firsts to support HTTP3 (for September)
Chromium will in a few releases render every websites using Vulkan API, no GUI toolkit can catch up.
They are also totally rewriting their layout engine to learn from past mistakes.
Microsoft is moving chromium input handling off the main thread to reduce input latency.
Web apis allow performance control (e.g css containment) and profiling far beyond native apis (but most don't know about them)
So if chromium has the fastest rendering, scrolling, input handling and networking performance, why do people think that electron apps are "slow" or "bloated"
It depends what we talk about:
If we talk about Langage performance, yes c++ destroy JS.
WebAssembly help but does not catch-up.
But electron or CEF allow to use c++ just fine so this point is moot.
Indeed people won't observe lag on native guis when such guis have e.g gnome theme where everything is monochrome, there's no complex rendering, no animation, no responsive layout, etc.
If you watched the slack GUI on Gtk I believe it would lag, but actually GTK has not enough features to recreate slack.
Let's talk about RAM usage:
Not using available RAM is a failure not a reason to be proud...
RAM allow preemption / caching instead of recomputing the same thing over and over.
So if you want to compare chromium vs a GUI toolkit efficiency: compare the same UX, and look at cpu usage too.
Let's talk about disk usage:
Yes it's dumb to download a browser for each app...
It's not a big problem seeing current disk space, and is solved by Google Carlo.
Electron has a prototype for solving this issue too.
Using Carlo, web apps will use less disk space that most other GUI toolkits!
Another potential reason for the misunderstanding come from the usual gap of skill between say a QT dev and an electron dev. Generally the QT dev (c++) has a mindset more oriented for performance, optimizations.
This is cultural, the same person could optimize for electron.
The last reason could have been a valid one:
Chromium transcend any other GUI toolkit feature wise which allow startups to express most design, in a precise, productive way.
This has the theoretical downside of having more complex designs, and more constraints on possible optimizations.
E.g a layout engine cannot make the same Invariant assumptions if it has to handle Right to left text (RTL).
If there was as much dev improving QT there is on chromium, I have no doubt QT would have better performance because of more possible optimizations because of less features.
But the reality is, this is far outweighted.
I would like to introduce the important notion of software poverty.
What I mean by software poverty is a software that has a slow development.
It's relative, and comparing QT or GTK to chromium is like comparing USA to Zimbabwe.
Gui(s)often have a few 10K commits while chromium has 850000 commits.
This is order of magnitudes differences!
Numbers have not a strong effect on the brain but they should.
The gap will increase even more now that Microsoft joined chromium.
To partially survive, GUI(s) toolkits like GTK or QT, webify!
GTK styling is now made with css via an old webkit...
QT QML and styling (modern QT) is made through the QT web engine (an old chromium).
Finally it is true that electron is not latest chromium, but it's "quickly" catching up, and many issues attributed to an electron app are due to it being an old electron, so using an old browser (and yes browsers are awesome since not that many years)
BTW skia is becoming the default renderer in android 10.
I guess I debunked many myths, any feedback?