Regardless of the GUI framework I would suggest separating the business logic from the GUI.
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.
I invite you to try Sciter[0], it allows you to write your frontend in HTML, CSS and JS, but the backend of the app can be anything native you want (C++, C#, Python perhaps). The events in the HTML DOM interface with methods in the native code, so your button actually runs the fastest, because the business logic of the app is native.
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
If Electron is too heavy, there are lightweight alternatives such as Tauri [1] and Neutralinojs [2]
Did you consider wxWidgets? I chose it over Qt and Electron for a recent project, because it gave me the most native looking UI across Mac/Win/Linux, and resulted in a small binary size and memory footprint. The project was an SSH file browser. Sounds like your project is also file browser related, so you may be able to get some inspiration or even reuse parts: https://github.com/allanrbo/filesremote
Is there a reason that flutter2 is not considered? With version 2 comes a push for first class desktop support.
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].
Broadly speaking, I would not make this decision based on the technical merits of either option. Instead, choose based on your high level goals for this project.
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.
Hacker News is probably not the best place to ask this question, as it's very much "JS bad" as a service. Take any advice received here with a grain of salt. With that out of the way - the only correct choice is the one you're more productive in. If you find that QT fits your workflow better, go with that. If you're more familiar with web technology and want to work within your comfort zone, use Electron (or Tauri or Neutralino or NWJS or...you get the point).
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."
My 8GB dell xps laptop can't even play music, chat, edit text and browse at the same time anymore. Because it's all Electron/Chrome (Spotify, Slack/Teams, Chrome, Vscode). This was no problem in the windows XP days. What makes Electron so great that it is worth this amount of resources?
My choice was Qt. In hindsight Electron probably would have been good enough. It also could have helped me launch sooner, iterate more easily, all at the cost of user memory.
Then again mine is only a source included product, not a community effort.
I suggest Electron for accessibility (e.g. with screen readers) if nothing else. In my experience, Chromium's accessibility support is much more mature than Qt's, at least on Windows. See also this thread: https://news.ycombinator.com/item?id=27303503
If you want to prototype quickly and reuse a component libraries/be able to attract contributors go with Electron. if you need to run your app on low-power devices consider QT but it will require a lot more investment from your end.
Maybe look at tauri?
You can write the cli in rust and the gui in html js css
Binary will probably end up around 6MB
Qt QML is really great for making GUIs.
Advantage of using Electron is that you have easy to deploy web version as well as easy build / install / update process for Linux users (though less native).
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.
I have been recently rolling my own Rust GUI framework using this rendering crate I’m invovled with https://github.com/femtovg/femtovg and I’m pretty happy with it.
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
I've built with Qt and Electron combined for over a dedcade.
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.
Also, go look at licensing. Qt is quite complex, and LGPL might scare away your company since it intermingles with everything: if you're not going full GPL, don't mess with GPL. Electron is download and go.
I strongly suggest that you take a good look at git-annex[0].
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/
Just write it in the framework you're most familiar and most likely to get something working in. You can always rewrite it later.
Web and Electron could be good if you're willing to deal with Chromium Embedded Framework (CEF) directly, like Spotify desktop client does, it's fairly snappy and feels good. That would mean that UI is web based, but everything else is native, and there is FFI of sorts in between. Though it probably only makes sense for a company of >1000 people as at that scale issues like being able to hire specialists become more prominent (pool of web devs is simply larger than pool of Qt devs).
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, if I see an app uses Electron, I look somewhere else... The only one I use is VSCode.
If you want to learn some new tech.you could have a look at reasonML and the revery framework for your UI https://github.com/revery-ui/revery
If your thinking about using Qt, check out U++(https://www.ultimatepp.org/), its pretty powerful and I've never seen a better designed IDE for C++.
If your considering writing your application in something like C, C++, Rust or Go, then I would these days consider wrapping it in a Flutter / Dart CLI that consumed it via FFI. Reach out if you want to discuss.
Electron and Qt are both terrible in different ways, but Electron is clunky and resource-heavy on all systems while Qt is primarily clunky on non-Linux systems.
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.
Qt is far better and extremely much faster and generic, once you have spent the long time required actually learn Qt and c++ properly. If you are new, then electron + some shitty html + js you'll get something that mostly mostly works very quickly, at the cost of being slow as hell. Take from that what you will.
The major app makers seem to think electron is the better choice, and I tend to agree.
Qt, absolutely. Great API and docs, and much more performant.
Answer: The one you are most proficient in.
- 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
> I generate a lot of files for various projects. Some of my projects are professional software and hardware development projects, or marketing and design projects, for ongoing or one-off customers. Others are personal video, welding, making, building, etc projects. Lot's of stuff to keep organized!
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.
How come TCL/TK or GT+ isn't an option? They're both far better.
> 1. GUI vs. CLI - I want to support both. But should it be a CLI first application that's then wrapped with GUI? Or perhaps it's better to build it as a GUI first application, and add a CLI interface to it? Or just have a core library, and use it in independent CLI and GUI tools? I never wrote a cross-platform tool, so I am not sure what's the best approach.
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.)
[0] https://www.voidtools.com/support/everything/sdk/