Electron vs. Qt for a new open-source project? Looking for advice(zynath.com)
zynath.com
Electron vs. Qt for a new open-source project? Looking for advice
https://www.zynath.com/articles/bin-finder-2/
127 comments
>But should it be a CLI first application that's then wrapped with GUI?
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
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
>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.
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.
> Don’t be GUI-first or CLI-first; be API-first.
This is very good advice for all systems. First try to describe the domain before implementing the user interface.
This is very good advice for all systems. First try to describe the domain before implementing the user interface.
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.
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?
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)
Also various local firewalls and anti virus software are going to block it by default.
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.
Some customers had problems because they had malware browser toolbars installed that rewrote/altered the HTML.
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.
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.
But it’s pretty annoying that even things like a file path picker would need to be custom made and done via the daemon.
That is going to look strange and suspicious to anyone who is not a tech worker.
why? The installer could clearly show a picture that this is how it works? People are not that stupid.
[deleted]
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.
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 on other sites. This means that users prefer your site to work the same way as all the other sites they already know."
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/
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/
Except this is a file system, so to users it shouldn’t be a site at all.
This applies to all interactions. E.g.
"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."
"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.
[0] https://en.m.wikipedia.org/wiki/Application_posture
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
The best compromise would be to open a web view. Though it's a concept often neglected, most languages have a package that does 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!
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!
> I would suggest separating the business logic from the GUI.
If only there existed a GUI library which did that for us ...
If only there existed a GUI library which did that for us ...
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
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 can write your backend logic in whatever language you wish with Qt or Electron too.
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.
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.
> 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.
[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.
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.
If Electron is too heavy, there are lightweight alternatives such as Tauri [1] and Neutralinojs [2]
1. https://tauri.studio/en/
2. https://neutralino.js.org/
1. https://tauri.studio/en/
2. https://neutralino.js.org/
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.
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.
Thanks! Will research them now.
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.
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].
[1]: https://ubuntu.com/blog/flutter-and-ubuntu-so-far
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
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.
Their technical blog discusses their issues and experiences. https://openprivacy.ca/discreet-log
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
actually it is pretty stable for dart and c interrop code you just can't have external view support like a browser yet
Flutter is still single threaded isn't it?
only the UI thread is, you can have concurrency and there is a nice library to execute rust code for high efficiency compute
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 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."
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.
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.
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.
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?
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.
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.
> What makes Electron so great that it is worth this amount of resources
Apparently electron enabled all of those companies to make those apps you use.
Apparently electron enabled all of those companies to make those apps you use.
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.
Or you can shoot yourself in the foot and code fast n' loose for those sweet quarterly profits.
People used to create music players, chat apps, and code editors without bundling a browser engine per app.
So what’s stopping them from doing that now?
[deleted]
Probably familiarity with and the relative ease of Electron?
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?
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.
(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).
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.
There are plenty of alternatives such as Qt
I'm not defending the choice. Just explaining the upside.
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'm pretty sure you can access slack through a browser tab if you want, so anybody who really hates electron has an easy out.
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.
Enabled them to do create them cheaply, sure. Enabled in the first place? I don't think our profession is that shitty.
[deleted]
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.
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
You can write the cli in rust and the gui in html js css
Binary will probably end up around 6MB
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?
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"
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.
[1]: https://www.bleepingcomputer.com/news/microsoft/microsoft-is...
[1]: https://www.bleepingcomputer.com/news/microsoft/microsoft-is...
I guess, that you have to write (some?) Rust.
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.
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.
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.
The original post describes a desktop application to manage local files. Having a web version is not a design consideration here.
This does not dismiss the rest of his argument. Cross-platform is still an issue even if you don't target the web.
Qt makes it also easy to build the app cross-platform, so no, it's not really an argument.
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.
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.
>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.
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.
[deleted]
> 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? 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++.
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++.
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.
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.
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.
It depends on how dynamic the UI will be.
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.
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.
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.
Should be possible with Qt widgets or Electron. Qt also has its own Electron-like web-based solution.
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.
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.
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.
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 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.
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.
Last time I used Qt, it had classes to abstract hardware.
Stuff like QSerialPort worked fine across platforms for my usage. YMMV
Stuff like QSerialPort worked fine across platforms for my usage. YMMV
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.
* 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.
[deleted]
>But I'm not giving up my frameworks.
Why would you dig your heels in if you've found a superior alternative fulfilling all your requirements?
Why would you dig your heels in if you've found a superior alternative fulfilling all your requirements?
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 was being funny but you took it seriously.
I was being funny but you took it seriously.
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.
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...
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.
Qt offers 3 licenses: Commercial, LGPL, and GPL. The LGPL option is quite business-friendly.
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.
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.
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/
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 :)
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 :)
I was considering experimenting with .NET, but wasn't sure how good GUI support is on MacOS and Linux. It's worth a look as well. Thanks!
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.
I wonder, how does this compare to Microsoft's React Native for desktop?
https://microsoft.github.io/react-native-windows/
https://microsoft.github.io/react-native-windows/
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.
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.
Isn't that because it's easier to find web developers than Qt developers?
- Sent from my 32gb MacBook
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 agree with this suggestion: Lazarus is
a great choice if you need to develop a GUI program.
> 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.
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.
Tk is very limited and full of bugs (especially the Cocoa implementation), you can't even compare it to Qt. For a simple app it might be ok, though.
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/