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.
Why bother shipping an entire separate browser? What would you actually gain vs bundling the daemon with a tiny launcher that just opened a new browser tab with “http://localhost:4855” or whatnot?
It’s not about stupidity. Infact it’ll be the people who are proficient with computers but don’t work in tech that will find this fishy and lose trust over the software. Installation and management UX is a core part of any software.
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.
I would much rather use a tool that works similarly to most other tools on my computer, rather one that works totally differently but it’s cool because the installer explains it.
"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."
This is somewhat sensitive to application posture [0] (sites are, for this purpose, effectively apps, even if they aren’t the kind of site that would be described that way usually.)
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.
Some things will be pretty annoying to implement because pages in browsers are sandboxed and limited in how they’re allowed to interact with the OS. You are also running that daemon so theoretically nothing is stopping you from doing those things by having the daemon do it.
But it’s pretty annoying that even things like a file path picker would need to be custom made and done via the daemon.
For one, you have a better control on the GUI (native file pickers, app actions, your own icon etc.). Don't get me wrong, I actually ship the tools I build also as little servers (example: https://github.com/egeozcan/json-tail) but there are also disadvantages to this.
Right -- that was the other thing I was going to suggest. There's nothing stopping you from using WKWebView on macOS or Edge WebView2 on Windows. Some might argue that there are browser differences -- to them, I ask: what's difference between targeting a single browser and targeting a single GUI toolkit/framework? They both limit the platform your code runs on. So you might as well choose the latter and give your users a native experience without ~300MB of useless bloat to save yourself what is probably not more than two lines of Javascript (you useless inconsiderate louts).
What if it were possible to host Electron apps on a remote server? That way, instead of shipping a browser, the user could use their preferred browser to somehow load the app from the remote server, and run it on their local machine?
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!
This adds another layer of potential security flaws. Other applications might try to connect to that daemon via network and exploit it. In turn you have to do all the security things in it, treating your frontend as potentially malicious. In an electron app you have secure communication channels. (Still have to be careful on data by the user, but all you get in the backend from the frontend is from your code)
I ran a bootstrapped non-IoT home automation startup from 2009 to ~2014. The hardware UI was presented as a web interface over the local network (backend was a mix of Ruby and C, some of which I have open sourced).
Some customers had problems because they had malware browser toolbars installed that rewrote/altered the HTML.
Cool project, what are some of the "cons" (if you or anyone else happen to know of any)? I've read through the website and github readme so I have a sense of the "pros"
It appears that you don't really have to write any Rust unless you need to do some heavy lifting. In this case Rust would be grate for file tree scanning, the rest can be done in JS. I am having trouble finding any really grate examples of what has been built in Tauri. I kind of want to play with a fully featured app to see how it performs.
On Windows, Tauri won't run on a computer unless it has WebView2, which doesn't ship by default on Windows before 10, but may be automatically installed on Windows 10[1]. I'm not sure if all Windows 10 computers have it automatically installed though, in the Insider ring, stable ring, and/or LTSB.
Rust has been on my ToDo list. I played with it, but haven't written anything proper in it. This would be a really cool option, and I'll get to learn something new! So, basically I can use any HTML/JS framework I want for the UI?
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.
Also, I suspect the main cross-platform portability issues you're likely to run into with an app like that are differences in filesystem behaviour, and developing it as web app doesn't really help there.
That's a good point - still you'd be sacrificing product development speed for the low level fs access, so the author should really make sure they know how much of it they'll need.
Given that BinFinder only needs the ability to read/write files and scan directories, it should be relatively cross platform out of the box. No real platform specific features, such as soft links, tags, etc necessary. On MacOS the app will likely need to ask for permission to access the disk, that's the only cross platform file system issue I see at the moment.
I was hoping to design something where on the left side there would be a tree of all the Bins (folders) and user would be able to click check boxes next to the folders they care about and the UI would instantly update with a list of matching Bins on the right side of the UI. Data would be pulled from cache stored in SQLite DB.
Can you see any issues with this on either Electron or QT? At first glance it feels like both should ok.
Okay I hope you still readind replies so here is that: wanted to reply directly to topic starter since it's most relevant. Some might be taken my posts here like I hate Qt or something, but I really like Qt.
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.
If your Qt app has single C++ line of code cross platform builds become much harder. Also regardless you still have to solve packaging and updates for Windows, macOS and Linux. Also it's much harder to do QA and it's take much more effort to maintain cross platform Qt app in general.
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.
How often and to what extent did you build using Qt? Your arguments against using Qt don't align with its actual capabilities. Qt has an extensive API so perhaps you weren't aware Qt possesses such capabilities which would be understandable if your exposure to Qt was transient.
>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.
I don't have enough time to make extensive reply at this moment, but still wish to clarify a point that I trying to make here. Also I do like Qt and Qt Creator is my favorite IDE. And I wish there were less of electon apps that eating GBs of my RAM for no reason, but I also understand that our world is not perfect.
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.
> If your Qt app has single C++ line of code cross platform builds become much harder.
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.
> What is a Qt app without a single C++ line of code? Is it written in PyQt?
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++.
Desktop applications that manages local files can still use web UI. There is plenty of reasons why it's can be nice to be able to access it through web.
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.
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.
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].
Wow, I haven't heard about the Ubuntu taking up Flutter. I wrote several commercial Flutter Mobile apps before, so this should be an easy transition for me. However, how mature is the desktop support in Flutter. I read that it's still in very early beta on Windows. Linux support and MacOS appears to be solid. I think this is worth a look for sure. One of my goals was to learn something new, but learning something new about something I already know is great too! :) Thanks for the pointer!
The cwtch.im project (metadata resistant E2E chat app) started with Golang backend, and Qt as the front-end (targeting x-platform desktop and mobile apps).
However they had some issues with Qt, and have been transitioning to Flutter.
Unfortunately both projects really try hard to hide what they actually do, so to save you time:
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.
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
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'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.
In Qt, isn't it just a matter of finding a cross-platform C++ lib for whatever hardware support you need? Just like you'd look for an npm package for Electron?
C++ still don't have ecosystem anywhere as easy-to-use compared to npm. There are two package managers with a lot of libraries (Vcpkg and MinGW / MXE), but:
* 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.
Because I'm a rational human being. If something comes along that is better, I'll jump ship. If Qt native meets my USB needs I'll move to the next barrier: frameworks. If Qt solves that hurdle, why stay with Electron?
I understood your statement as saying you are not giving up Electron if you found Qt fulfills your requirements (USB). That's was I was questioning: Why continue to use Electron if Qt does all the things you need to do.
Perhaps I misunderstood; text isn't the best medium to convey tone.
Yes, sorry. Communication mishap indeed!! I was sort-of implying that now that I learned Qt offers USB support, one of my two reasons for not using Qt was dismantled, as if I was now worried that I made a mistake picking Electron and boy this sure sounds less and less funny as I type it out...
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 :)
> 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.)
>If you build it as a CLI, you can get the GUI for free via Gooey
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.
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
I am researching wxWidgets at the moment. I really like the small file size on the FilesRemote and how quickly it starts up. Those are a big plus for me. I am not too concerned about the native look and feel because of the type of app I am making, but the speed is a huge plus.
I was about to suggest wx too. :) Currently they natively support GTK and WinAPI as backends, which is why it's so fast. In case they revive wxQt, it'll be my choice for new projects.
But right now, from UX and portability perspectives, Qt wins.
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.
> You can write your backend logic in whatever language you wish with Qt or Electron too.
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.
Build command line tools first. Stick to the Unix philosophy of "Small is beautiful - do one thing and do it well" with each command program. Then build a GUI app for whatever platform you want to support.
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 command line tools, I'd recommend whatever language you are comfortable with, but I'd opt for something that can create a standalone executable.
For creating the GUI, consider the free and lesser known gem Lazarushttps://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'd like it to be platform and filesystem agnostic - easily portable to another OS. Have fast indexing and search. Extensive tagging. (Using a database, like SQLite, can really help with all this).
> 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 ...
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?
This feels like the most probable explanation to me; companies hire tons of people skilled in web development, front and backend, and then suddenly desire a desktop app. Then they either don't want to recruit people who specialize in desktop apps or they don't want to retrain their web dev staff. And even if they were willing, they probably would still impose a ridiculous timeline and expect the app to be delivered. I can understand that an engineering team not familiar with desktop applications would choose Electron in such a scenario.
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?
"aaS"-ification of everything. If your music is streamed from some service, you're generally forced to use that service's apps. Otherwise you'd StEaL tHeIr CoNtEnT.
(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.
If you use an unofficial Discord client, you risk getting your account banned.
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).
They would have to build an app for every platform they support. If you want to target all three, it's much easier to use something like electron that targets all three. You maintain feature parity and even bug parity across platforms.
If you think ChromeOS and iPadOS as desktop, music player and chat app is still written in native apps. These apps available too in macOS if developer opted in. So this problem seems to be limited to Windows and Linux only.
With the amount of capital these companies have if they couldn't manage without then something is deadly wrong (especially with the kind of people they hire - although that being said the most productive person I know has no formal qualifications). You could literally bring up an entire programming language and GUI framework from scratch with the resources some of these companies have.
I don't have professional experience in either desktop UIs or web UIs. When I tried making an app using the native macOS UI toolkit, I kept running into issues related to a lack of online discussion and books that were less complete than I expected. I think this is mostly just a symptom of there not being much native UI development happening in the west. It's a self-fulfilling prophecy.
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.
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."
Just because you don't feel the weight of electron apps, it doesn't mean it's not there.
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.
> Just because you don't feel the weight of electron apps, it doesn't mean it's not there. You just have a powerful computer.
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.
127 comments
[ 4.0 ms ] story [ 238 ms ] threadThe 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.
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.
https://www.nngroup.com/
"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.
[0] https://en.m.wikipedia.org/wiki/Application_posture
But it’s pretty annoying that even things like a file path picker would need to be custom made and done via the daemon.
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!
Some customers had problems because they had malware browser toolbars installed that rewrote/altered the HTML.
If only there existed a GUI library which did that for us ...
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.
Can you see any issues with this on either Electron or QT? At first glance it feels like both should ok.
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 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.
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++.
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.
https://microsoft.github.io/react-native-windows/
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].
[1]: https://ubuntu.com/blog/flutter-and-ubuntu-so-far
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
1. https://tauri.studio/en/
2. https://neutralino.js.org/
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.
Then again mine is only a source included product, not a community effort.
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.
* 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.
Stuff like QSerialPort worked fine across platforms for my usage. YMMV
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.
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 :)
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/
If you build it as a CLI, you can get the GUI for free via Gooey[0] (shameless plug)!
[0] https://github.com/chriskiehl/Gooey
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.
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.
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).
For creating the command line tools, I'd recommend whatever language you are comfortable with, but I'd opt for something that can create a standalone executable.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.)
I'd like it to be platform and filesystem agnostic - easily portable to another OS. Have fast indexing and search. Extensive tagging. (Using a database, like SQLite, can really help with all this).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 ...
Apparently electron enabled all of those companies to make those apps you use.
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?
(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.
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.
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.