* one the best thing that happened to desktop software as it enable web developers to build desktop portable app
* one of the worst thing that happened, because it makes the desktop world rely on Google and decrease even more the expectations on how much resources an app should consume
What are your opinions ?
I have to kill the application before it consumes everything.
Electron applications like VS Code are an exception and slightly gives me hope.
Going to be working on an Electron app, so I'm curious about what optimizations have been made there.
I've found keeping as precious little of the work in the render process as possible has helped a great deal. Send everything to the main process and use the event/messaging system to update the state. Then things that you're used to doing to maintain application performance in a web browser apply. Keep the compute in the back as much as possible.
And depending on the task, offload compute to a native module [if you're capable and] if the expense between NodeJS <> native module is worth it (more intense compute tasks).
There's probably more and more experienced advice out there, but this is my experience so far.
They just run more efficient software on top of electron than others do.
However, if you want to hire Qt developers, that's a much smaller pool and then you also need to pay Qt license fees for each one.
If you want to develop truly native applications, now you need to maintain builds for Windows, Mac OS and perhaps even Linux. You need developers familiar with all of these native frameworks.
Optimizing for developers isn't necessarily worse for users, if they can get more done in less time, users benefit. It's just not so obvious. No user will ever complain about a product they aren't using because it won't ship until next year with half the features.
Basically, you need to link dynamically or provide object files. You can't use commercial modules too. But that's only a small portion of Qt anyway.
I strongly suspect I'd never be able to bring the level of polish I could with HTML & CSS to the UI through the standard SDKs -- so the resulting app would be a much worse user experience as well.
The amount of time I'd have to spend learning a new SDK would basically put me off, and I'd likely never have created this app.
Instead I have over 700 people who have purchased my app (~2 purchases per day over the past half year) - https://videohubapp.com/
But UI is not essential for a functioning app, and if the time costs of building a good UI are too high (a lot of new learning and problem solving) I'll spend less time on it.
What "sample" are you talking about? Is this the kind of thing you're comparing my app to? https://doc.qt.io/qt-5/examples-graphicsview.html
https://doc.qt.io/qt-5/qtdoc-demos-photoviewer-example.html
(Edit: by no means I'm saying that your work is trivial to replicate, apologies if this comment came across like that - just wanted to point out that there's more to Qt than Qt Widget.)
The original reply I made was to point out that startup costs decrease number of people starting. Unless you know Qt already, your first project will take much longer than using technologies you already know. It's not at all clear how long learning would take.
I know I can climb the mountain, but I'd rather not. This isn't to discourage others from doing it, it's to explain to those who don't understand why many people prefer to stick to Electron.
Simple QML viedo player.
That should tell you something.
It might change a bit with Flutter & SwiftUI but I still find web & CSS to be a better authoring model.
Note that I've been doing (native) desktop programming before so I can compare.
For personal use, you also don't need multiple runtimes for multiple electron apps. You can just use the single shared one (or even system one; for example archlinux has electron installable via pacman), reducing memory use.
It's also pretty good tool to write your own UI for other people's websites.
Can you point to some good examples of these use cases?
You can get data with XMLHttpRequest inside electron from any origin and then just process the returned document with regular web apis.
Sorry, I don't have anything public.
With my Web developer hat, I see the future as PWAs and if you really need more than Web APIs allow, by all means create a local daemon that uses whatever browser the user has installed.
All my uses of Electron are forced upon me, if native versions are available and I am allowed to choose, native wins.