Electron vs. Qt for a new open-source project? Looking for advice
zynath.com
zynath.com
Don’t be GUI-first or CLI-first; be API-first. You can get started by writing a test target. As soon as you need more than “edit tests, recompile, run, examine debug prints”, you can start on both the GUI and the CLI together.
Focusing on keeping a solid API makes things much simpler. And if you ever regret choosing Electron over Qt or vice-versa, having all the juicy parts behind an API makes it much easier to switch.
For examples, look at Git, the TypeScript compiler, and Everything [0] (closed source unfortunately).
There was a quick-search app for macOS that used V8-to-Rust asynchronous procedure calls as the API. It would make a great example, but I can’t remember it’s name.
(Love the app idea btw! I look forward to trying it on my mess of files for my small business.)
If you build it as a CLI, you can get the GUI for free via Gooey[0] (shameless plug)!
But then you've just added a dependency and, unless you vendor that thing, or don't update it in the future, you've no way to ensure it doesn't screw up your application at some point down the road.
Design the API, write the code, then have your front end(s) (cli, GUI, etc) call into it. Best of all worlds, no additional dependency.
This is very good advice for all systems. First try to describe the domain before implementing the user interface.
The business logic could run as a daemon in the background or a shared library and can be implemented in whatever language you're most proficient in for writing system services and that matches the performance requirements of the task, and the GUI can be written in whatever language you're most proficient with for GUIs (so you can start with Electron and switch down the line if needed).
I would've said Electron is a bad idea for this (for the reasons you mention in the post), but if the "business logic" is decoupled from it then Electron's task is to merely display information at which point it becomes more viable.
Some customers had problems because they had malware browser toolbars installed that rewrote/altered the HTML.
But it’s pretty annoying that even things like a file path picker would need to be custom made and done via the daemon.
It’s the same as us programmers driving cars or using kitchen gadgets. If something is out of the ordinary or the UX is difficult, we’ll think it’s fishy and lose a bit of confidence.
https://lawsofux.com/jakobs-law/
Jakob Nielson is a founding member of Nielson Norman Group that has studied UX for decades.
"Users spend most of their time _opening_ other _door handles_. This means that users prefer your _door handle_ to work the same way as all the other _door handles_ they already know."
A site that is effectively a sovereign app has more freedom to defect from general interaction patterns, whereas one that is more of a transient app has less.
The only major technical hurdle I can think of would be a way to locate and classify remote assets and resources, so one knows what belongs to what. We'd need to come up with an address system, something like a "universal resource locator" that could assign an app to a "domain" (think Java namespaces) that maps to one or more IP addresses. Instead of installing the app, you could just type the "domain" into the browser and access the application.
It could be a revolution in the way Electron apps are distributed. Someone write this down!
If only there existed a GUI library which did that for us ...
Some of the most performant products use it, like antivirus products. Yet, you see antivirus products have a nice GUI and that's the reason. You can see it in the showcase.
I know Sciter is not mainstream, but you don't have to deal with Qt's API nor with making your business logic in Javascript with Electron and shipping the greatest overhead that an embedded browser implies.
To me, it's the best of both worlds. Flexible do-as-you-see-fit GUI and native performance because of compiled languages.
[0]: https://sciter.com
You also neglected to mention that Sciter is closed source which is a pretty big turn off.
> antivirus products have a nice GUI
They do??
> deal with Qt's API.
Qt's API is one of the best designed that I've ever used.
Yeah, but most developers won't in the case of Electron. It's a source of CPU Perfomance abuse. Developers will take the shortest/easiest route, businesses will save costs on development at the expense end-user software performance. See [1].
It's almost always best if your framework protects you from shooting yourself in the foot. That's why some languages support Static Typing, Type Inference, Clear Inheritance rules, among other failsafes. In this case, Sciter protects you from bloat-by-default GUI code.
> You also neglected to mention that Sciter is closed source which is a pretty big turn off.
That's not true. The source code is available for review if you pay for the license. It's not a turn off for businesses that do need continued support and a contract to back it up.
There was an effort to open source it, but it didn't took off in the past year. See [2].
> Qt's API is one of the best designed that I've ever used.
Yes, it's nice and all. I've used it myself in about 5 projects. I didn't try to imply it's hard to use or somewhat cumbersome.
However, sometimes I prefer not to have to deal with Qt's Theming or I really need custom controls I'd rather develop with web technologies rather than with Qt, at the same time not bundling an entire Chromium + Node 300mb+ package.
Sciter does the job for less than 2 Mb, and to me that's unparalleled advantage over Electron.
[1]: https://www.ivanmontilla.com/blog/economics-of-software-perf...
[2]: https://www.kickstarter.com/projects/c-smile/open-source-sci...
EDIT: Typos and clarity.
1. Like Electron but uses the platform web view API - Edge on Windows, Safari WebKit on Mac and GtkWebkit on Linux.
2. Same but I think it uses GtkWebkit on all platforms and possibly bundles it (if their claim of zero dependencies is not a lie). Not so sure about this one.
Admittedly, I don't currently know of any books that have been revised to cover version 2, but there is momentum on the desktop. For example, it will be the default framework on Ubuntu moving forward [1].
However they had some issues with Qt, and have been transitioning to Flutter.
Their technical blog discusses their issues and experiences. https://openprivacy.ca/discreet-log
Is the point to build and support this project for the medium to long term? Choose the one with which you’re more familiar, or for which there is more available help and resources.
As a sub-consideration, do you expect others to work on this project with you? Choose the one with which contributors are more likely to be familiar.
Is the point to learn a new UI framework? Choose the one in which you’re most interested.
Is the point to burnish your résumé? Choose the one that is more in demand by the opportunities you’re seeking.
That’s assuming that both technologies can meet your requirements (e.g. if you might want to use this on resource-constrained devices, choose Qt; if you want a web version, choose Electron). But all else being equal, you need to figure out your goals before you can make this decision.
QT has much less overhead to it, but it's not exceptionally difficult to create an optimized Electron app that people will enjoy using. Discord and (in my opinion) Visual Studio Code are good examples of well-optimized Electron apps.
All else held equal, I would personally choose Electron (or rather Tauri) if just by virtue of "you are forced to separate the display tier from the business logic."
You just have a powerful computer.
I switched from Slack / Discord to Ripcord and, even though the UI is not great, it's much cheaper to run. It's using 80mb of RAM with multiple slack organisations open and multiple discord servers.
Pritunl written in Electron is using more than 100mb or RAM, just to let me provide 2 factor auth and connect to my VPN.
I've been toying with the idea of writing a native app for Pritunl, but I don't work for Pritunl and I have 32GB of RAM. I'd love to rewrite Visual Studio in Qt, but I don't work for Microsoft.
The funniest thing is that the developer experience on Qt is years ahead frontend development in the browser and it's been like this for more than 10 years. You have a mature widget system and you even have native looking widgets.
I can see the appeal of Electron; if all you know is web development, you don't want to take the additional complexity of learning a new framework. Personally, I would definitely use Qt.
I definitely don't intend to imply that Electron apps aren't inherently heavier - they are, hence the second paragraph of my initial comment.
> I switched from Slack / Discord to Ripcord and, even though the UI is not great, it's much cheaper to run. It's using 80mb of RAM with multiple slack organisations open and multiple discord servers.
I actually switched to Ripcord for Slack myself! I find it doesn't provide a comparable experience to the first party Discord app, but it beats Slack all day every day. Slack is an excellent example of a poorly made and unoptimized Electron application, in my opinion.
I don't hear about this often, but I've heard that native apps are still common in China. I bet they don't have this problem.
I bring this up because I notice a lot of the time on HN this gets attributed to web UI people being easier to hire and unwilling to learn native UI.
Apparently electron enabled all of those companies to make those apps you use.
(formatting intended to convey sarcasm.)
Not really related: your German word of the day is "Raubmordkopieren".
The content industry, in Germany, decided to phrase copyright violations as "Raubkopie", literally "armed robbery copy". (There are two verbs for robbery in German, "stehlen" for simple theft without force, and "rauben" for forceful theft.)
Since this is pretty obviously a far stretch (how is filesharing "by force"?), the P2P scene decided to go for the hyperbole: "mord", as you might have guessed, is murder. "Raubmord" is an established word in German ("holdup murder".) "Raubmordkopie" — you get the idea.
Even banning aside, I wish there were better unofficial Discord clients. Ripcord is closed-source, lacks multi-message select, and doesn't let you search, and gtkcord3's repo is archived (and I didn't try it).
I'm pretty sure you can access slack through a browser tab if you want, so anybody who really hates electron has an easy out.
However, in none of these decisions was the user experience a factor at all. That bothers me.
"Just buy a laptop with 16GB RAM and stop complaining, get with the times", I hear the downvoters thinking. This development directly drives people towards purchasing a more powerful replacement computer. Chip shortage, electronic waste, does anyone care?
Then again mine is only a source included product, not a community effort.
You can write the cli in rust and the gui in html js css
Binary will probably end up around 6MB
[1]: https://www.bleepingcomputer.com/news/microsoft/microsoft-is...
Qt is amazing due to much smaller memory footprint, but cross platform builds, packaging and CI still gonna take a lot more effort to maintain.
For Electron apps it's all much easier because all native code is heavily tested by other commercial software and there is even on-the-fly updates possible.
PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink.
>If your Qt app has single C++ line of code cross platform builds become much harder.
As I mentioned, Qt has an extensive cross-platform API; indeed that API is Qt's value prop. If you've the need to write arch/platform-specific UI code, then it's very likely you'll find the solution to that problem somewhere within Qt's docs. If not, then you cannot expect to be able to write such code using Electron/JavaScript.
>Also regardless you still have to solve packaging and updates for Windows, macOS and Linux.
What's to solve? Qt has had these capabilities. If you describe a specific issue, you may have an argument, otherwise this statement makes no claim.
>Also it's much harder to do QA and it's take much more effort to maintain cross platform Qt app in general.
How so? This is such a broad and unspecific claim to the extent it isn't possible to form a counter argument. State specifically the issues making it much harder to complete these tasks using Qt.
>For Electron apps it's all much easier because all native code is heavily tested by other commercial software
Qt's testing suite is extensive. Qt is and has been deployed and "heavily tested" around the world for years. Qt is also deployed as an embedded technology.
>PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink.
I'm not sure you spent much time doing this because Qt makes shipping cross-platform software so simple it sometimes feels like I'm cheating (there are exceptions when dealing with very specific platform/arch-specific items as I mentioned above; there is no solution in JavaScript.). There must be some specific issue(s) you came across, but without specifying what specifically made you perceive using Qt a huge time sink, the statement makes no claim.
So here is the problem: open source project usually mean that it's gonna be project with just single maintainer for quite some time unless it's get like really popular. So you gonna work on C++ codebase doing everything alone with limited resources.
Qt have a lot of features, but it's still not comparable to what web stack has to offer. And if you take single external non-Qt library it's will make builds, deploy and testing so much more harder. And testing or debugging desktop software alone is huge pain in ass when it's cross platform. Running 3 different OS in VMs at least, etc.
Is Qt bad or lack something compared to Electron? No, not at all. But for 95% of open source projects C++ simply wont work. Messing with CMake, packaging and platform-specific mess most likely just gonna sink the project long before single developer manage to get it to stable, usable and user-friendly state.
What is a Qt app without a single C++ line of code? Is it written in PyQt? Or did you mean a single C++ dependency? I assume you meant that, based on your later comment saying "if you take single external non-Qt library it's will make builds, deploy and testing so much more harder".
> For Electron apps it's all much easier because all native code is heavily tested by other commercial software and there is even on-the-fly updates possible.
I've had the opposite experience; if you can build your own application code using CMake, and link it with prebuilt Qt on a set of platforms, bundling extra libraries vendored with your program and built from source each time is not significantly more difficult than making your own "build from source" work.
On the other hand, in my experience with Python's native modules and observing others working on Electron Node native modules, if you're depending on prebuilt native binaries (the alternative is building native extensions from source, requiring everyone building your app to have a JS/Python toolchain plus a C++ toolchain that the JS/Python can find), you are at the mercy of the maintainer of the native extensions to fix bugs for you and release prebuilt binaries. That's unless you build and host your own native binaries with your own bugfixes and tweaks.
Yeah I meant PyQt since when you use Qt bindings you mostly bypass burden of C++. With single non-Qt dependency it's just end up worse.
> I've had the opposite experience; if you can build your own application code using CMake, and...
Be honest about it starting with CMake: even CMake alone is a mess especially if you have to target not just latest version. It's has mixed code quality, non-existent dependency management (both Vcpkg and MXE are far from perfect) and require you to know tens different specifics if you want to build C++ project across Windows, Linux and macOS.
And if you want your open source project to be successful you need good CMake configuration so contributors across 3 different OS can easily setup development environment and builds.
I'm not gonna lie - I do far more experience working with C++ / Qt rather than Electron as well as other web-tech based desktop apps. But it's just crazy how many hours, nights, days and weeks I sinked into messing with CMake and debugging C++ project and some 3rd-party library build issues instead of actually writing the code for my projects.
PS: Might be I have somewhat rose-tinted glasses when I look at using non-Qt frameworks for desktop apps, but so far it's feels far more plausable to bring some project to completion if it's has nothing to do with C++.
Can you see any issues with this on either Electron or QT? At first glance it feels like both should ok.
I don't see any issues with implementing your idea using Qt and it's will absolutely certainly be using less CPU and RAM without any optimizations.
Yet IMHO there is good chance that if you stumble into some Qt / CMake / C++ issue then you gonna be wasting ten times more time on initial implementation. This is C++ for you. And this might kill your project before you even get to first stable version.
Qt widgets would likely be the fastest and lowest footprint. Though I'm not familiar enough to say exactly how you'd go about that.
I recently added a wgpu backend https://github.com/adamnemecek/femtovg.
Combine that with the Flutter layout (check out the Druid implementation), and you have a GUI framework.
Join the discord https://discord.gg/V69VdVu
Electron has entire libraries that are portable cross-OS. It is literally write once, deploy on Ubuntu, Mac, Win10. I've never had an issue, even using serial ports and USB interfaces. Qt is just a GUI, you will still need to write native hardware interface code. As a bonus, with Electron you also get ALL of the modern frameworks and templates. If you choose Qt you will always feel "behind".
EDIT: Based on this thread I need to re-examine Qt. They now have cross-platform USB endpoint classes that are of interest. But I'm not giving up my frameworks.
Stuff like QSerialPort worked fine across platforms for my usage. YMMV
* Only very popular libraries actually available.
* Sometimes they break on package manager and no one notice for months since test coverage is often limited.
* Each extra library might cause tons of little issues and make your build system more and more complex.
* Libraries often don't support all OS equally well.
* Most of mature C++ projects avoid those libraries and package managers.
So much often than with npm you will have to test each library on your own and what worse you might only learn that something fundamentally broken (on specific OS or architecture) inside it much much later. And with C++ it's just harder to do refactoring to replace said library with something else.
Why would you dig your heels in if you've found a superior alternative fulfilling all your requirements?
I was being funny but you took it seriously.
Perhaps I misunderstood; text isn't the best medium to convey tone.
However, recently Qt's own marketing people seem to be undermining it by incorrectly suggesting that all commercial development requires a commercial license. Which is not the case. Commercial developers can use the GPL or LGPL versions as long as they comply with the license terms. Complying with LGPL is generally quite easy.
git-annex manages (possible very large) files and helps you to copy/move them between different storage location, e.g. usb sticks or hard drives (actually it supports far more than those). In your proposed scheme when you copy a file to a new location you must also copy the UID. This means that when you copy a file by traditional OS commands, your system will will not be able to recognize that the copies are actually identical. git-annex uses a smarter system because the unique identifier for a file is a hash of its contents. This means that it can detect if two files are identical or not[1].
In your description of a bin you have a name, description and tags as information about the bin. You only really need tags because they could be used to implement name and description. With git-annex you can add tags as metadata to each file [2].
git-annex is a great solution if you have many files stored in different locations.
[0] https://git-annex.branchable.com/ [1] If you think that you can produce SHA-256 collisions, you should be writing a scientific article about it and not spend so much time on HN. [2] https://git-annex.branchable.com/git-annex-metadata/
Qt is amazing, though only downside is near absence of ready-made 3rdparty widgets. Which limits the development speed quite a bit, while in other technologies you have an option to throw $$$ at the problem at get a widget of ok quality to solve your problem, there is very little of that available for Qt. So before venturing there I would recommend checking if built-in are covering everything you need, otherwise be prepared for a long road of making native-feeling widget that works with all platforms UI guidelines.
I would give .NET ecosystem a try, they cover both developer velocity (coding in Rider is amazing) and 3rdparty widgets (plenty available), albeit it's not _that_ crossplatform just yet, .NET MAUI is only getting ready for .NET 6, so there be dragons :)
Personally I'd go with almost anything that seems OK on Linux (e.g. GTK seems to be pretty mature and seems less susceptible to issues with the Qt company), and native on every other platform.
- GUI vs. CLI
Why CLI first? Command line tools can be used independently in scripts to automate various tasks (often repetitive tasks). This also further decouples programming logic so that you can work separately on the CLI code and the GUI code. (Here's some good tips on how to create a GUI for a command line tool - https://softwareengineering.stackexchange.com/a/204316 ).
(Also keep in mind another Unix philosophy - "Reuse. Don't reinvent / rebuild". The GNU Coreutils command line programs that is available for multiple platforms can be a real asset for your project - https://opensource.com/article/18/4/gnu-core-utilities . SQLite is another software that can really make your project simpler).
- Language / UI Library Selection
For creating the GUI, consider the free and lesser known gem Lazarus https://www.lazarus-ide.org/ - it can help you create native GUI for many platforms from one code-base (with some tweaks for each platform). A native GUI makes your application small, fast, and familiar to your users. The catch - you will have to learn Pascal to use it - if you are familiar with it, here's a good tutorial http://www.delphibasics.co.uk/Article.asp?Name=FirstPgm to help you get started. (Note: Lazarus is an open source fork of Delphi - https://www.embarcadero.com/products/delphi ).
Lazarus is better than QT because it uses the operating systems native GUI toolkit. You also don't have to worry about licensing issues with Lazarus and can even create commercial closed source applications with it for free.
Lazarus is better than Electron because Electron bundles another layer over the OS (the chromium browser framework) to render the UI. That's a lot of additional software just for a GUI, and will make your software big (50+ MB) and slower (chromium is a resource hog).
(But ... if time is a constraint or you don't have the inclination to learn yet another programming language, then go with what you are most familiar. If it is C++ choose QT. If it is HTML + CSS + JS, choose Electron.)
- Use Cases
Funny, I have the same problem, and use a similar solution for a long time now.
> What we need is a cross platform, cross UI (GUI and CLI interface), and cross file system solution. It has to work on thumb drives with ExFAT filesystem.
Why cross platform and cross filesystem? Why specifically ExFAT? Is this a personal Project or something Community-driven?
> Bin Pointers - Pointers live in one part of the tree and point to a Bin in another part of the tree. Just like Aliases on MacOS, Shortcuts on Windows, or Soft Links on Linux, but cross platform and automatically self updating! If you move the target Bin, the Pointer will find where you moved it and update itself!
Many Buzzzwords. Also, are Windows-Shortcuts and Symbolic Links really the same? AFAIK Shortcuts are on desktop-level, while Symbolic Links are on Filesystem-Level. And Windows&MacOS have links on Filesystem-Level too.
> The base file organization unit in Bin Finder is a File Bin. A Bin is just a folder with a Bin Description File > Because a File Bin is just a special type of folder, it can contain any number of files and sub-folders inside of it, including other Bins and Pointers to other Bins! > If you need to tag or point to an individual file, it can be wrapped individually in a Bin. Since most human endeavors of any substance produce multiple files, this use case is relatively uncommon
Looks kind complicated... What's the point of nested bins?
My own solution is similar, but simpler. I use a central folder $HOME/HUB were I collect my sources (Local Drive, USB-Stick, NAS...). Each source has a subhierachy according to some personal reasons, with Content-Folders being on a fixed level. Each content-folder has #Tags in their name, and I use a simple script with rules to generate Hierachies of filesystem-links in my home-folder. I run the script occasionally when I change something, and thats it.
I also have a handful scripts and build a little GUI for managing code-projects, but overall it a very stable and straighforward solution. I mostly use a filemanager for 10+ years now, and overall it works very well. Though, I use it on Linux, were such things are common and easy. Having certain fixed paths for certain is also preferable, so my solution must be working on it's own, without a gui.
> When you click on a Pointer to the Project Bin you just moved, the system will first check where it has seen the bin last. If the system can't find the Bin in that location, it will quickly rescan all of your Trees. If the Bin is found in another location, the system will update the pointer and open the Bin
This is pretty much the same as what Windows Shortcuts are doing.
This overall reads like you reimplement Windows Shortcuts, but for Multi-sourcesand with a focus on Project-Workspaces-Handling? How would this work on CLI? You can't click them there?
> I have most of the UI and workflows worked out in my head pretty well, but I find myself in a "paralysis by analysis" situation.
So you have not used it yet? Then why not start using it? Start as simple as possible an experience the basic concept in your daily life. I know from my own system that things evolved over many years and adapted to certain demands from my own life and work. Organizing is very personal an i won't be always work as plannend.
> GUI vs. CLI - I want to support both. But should it be a CLI first application that's then wrapped with GUI?
What is the purpose of the GUI? How would you use it daily? What's the purpose of CLI, How do you aim to use that? Waht ability do you even have? Are you a coder and could implement something fast? Or would you start by zero and would invest a juge a mount of time for this?
> Language / UI Library Selection - Here the choices appear to be Electron with JS vs. QT plus either Python, C++, or Go.
I use Python and Qt. It's working well for this, as Python has a good focus on filesystem and cli-tooling, while PyQt allows fast growth into frontends. I would at least start with this for your first generation, till you have figured out what you really need. Start with cli, evolve into a lib, and build the GUI. Then you can still optimize with Go or Electron, depending on how it goes.