I haven't done desktop UIs in a while, but my experience is that html and css work really well for UI, and there are a ton of competing desktop UIs that all have their own issues. Last time I tried making a desktop UI, I definitely preferred html over it.

I wouldn't be surprised if there were a lot more web devs than native devs, too.

And finally, if you have something you want centralized, it's generally a lot easier to just have a web server than setting up some kind of system to sync the data between different computers. For finances, I could see wanting to use it on both mobile and desktop on a daily basis. That makes web a lot more desirable.

HTML and CSS are most definitely NOT better for the UI comparing to the native desktop apps. HTML was designed for cross-reference documents and people spent decades enriching it with CSS/JS/whatever to get some resemblance of acceptable UI. Not even mentioning all the resources required to run all the frameworks that the modern Web UI is running on.

If you want to be able to check your finances on the phone you have to put it on a 3rd party server along with your data. Might as well go with SaaS like Mint. I don't.

You do lose some cross-platform capabilities when you do desktop apps, that is true, but there are some toolsets available (eg Qt).

So I guess it comes down to what people are used to work with, which is Web-first.

The developer experience for Electron is much better than PySide + QT free, and nobody is spending 5,000 a year to write their own apps.

I think the original point is that if you're goal is to build cross-platform quickly, nothing right now beats html+css in electron.

Indeed. I can’t imagine doing native desktop development unless it was absolutely required for my project, and then I’d ask myself if maybe I shouldn’t just work on something else. All that work and it runs on one OS.

The short of it is that nobody has cracked the free cross-OS problem in the same way as electron has. Lazarus requires pascal and is unattractive. JavaFX, afaik, still requires a jvm download to use, and the documentation is minimal. QT is expensive for anything that isn't OSS, and the tools are minimal if you are on the free plan. Most of the rest require C++ and most don't have a great default visual design.

Electron has great documentation and we have a great variety of ready-to-use js widgets.

I really don't like this pattern either, but every time I've gone to trying to build a desktop app I get stuck in the mud. (I used JavaFX last time and got far enough to be usable, but I'd go to Electron if I wanted to have something to distribute.)

I just find the idea of building a local application using Web tools very... counterintuitive. Just such a waste of resources. Isn't Electron one of the heavier frameworks? Think of all the resources used on your local machine just for one application and one user.

If you plan on sharing this data with other users, then sure, it makes perfect sense, you can't share stuff from desktop app (without standing up API or smth). But if it's some personal stuff, like finances, personal notes, etc etc why move it out to the open?

I tried Mint awhile ago and it offered seamless integration with most of the financial institutions I deal with. Like I can get all my CC transactions data, checking accounts, savings accounts, 401K and (almost) everything else. Wonderful. I just need to provide all credentials to Mint so that it can authenticate with these institutions.

My cell phone provider has been hacked 3 times in the last 5 years, with at least one time stuff like SSN numbers and physical addresses got taken. If anything remotely similar to that happens at the SaaS that has my credentials, that's not just my credit card and bad loans, that's my life savings that can disappear. That's just... a non-starter for me.

But I'm old and I guess younger folks don't care that much about life savings. To each their own :)

I use Goodbudget. The appeal is that I can enter expenses from my phone, and my partner can do the same, and we can both see how much is left in each budget category. If we were to switch to a self-hosted version, it would run on a home server, but it would be accessible from anywhere. I don't think this is an option you considered.

Additionally, even if you use a third party host, it seems less likely they'd be snooping through your application data, as it would provide no benefit to their business of selling you hosting infrastructure. The providers of a budgeting app, on the other hand, have many reasons, benign and possibly not so benign, to be looking at your data.

If it's a self-hosted web app it is trivial to give yourself access on all of your devices using something like tailscale or wireguard. The same cannot be said for sharing access to a desktop app.

There's a lot of web developers, becuase the entire development process of web is much easier compared to other platforms, including setup, debugging, and distributing. Also, with a web app you can access it from several devices, instead of just one.

Agreed completely. I've used Gnucash for a small business, but found it a bit to cumbersome for personal finance. I've had a look at Homebank, Eqonomize. Anyone use these?

In the same boat. I did use GnuCash for business as well, in my opinion that's its primary use case. I just found Eqnomize and will give it a spin, however it's not open source (?). Other than that... Seriously considering dusting off my old tools and starting something myself :)

It's on Github, GPL licensed: https://eqonomize.github.io/

So Qt on C++ _is_ an option for desktop apps then :)

Because many people (or their partners) use phones more often than desktops. Many may not even own a desktops aside from a dusty laptop and their work computer.

> If it's installed on the local, it's a waste of resources and development time

Says you.

If it's installed on a local Web server it's designed to be able to serve multiple users. If there's only one user how is it not a waste of resources?

> If it's installed on a local Web server it's designed to be able to serve multiple users.

I'm sorry, but that just isn't how that works. It would be no more "wasteful" than running a native app. 1 user or 10, it doesn't matter.

Besides, most self-hosters have servers that are running many apps, so this is just one more. Not a big deal.

How is this not more wasteful than running a native app? You have to run a Web server IN ADDITION to the app. And your client-side is rendered in the browser which, again, is IN ADDITION to the app. Where the native app is just... the app.

Sure, many people seem to be running their Web apps on the local Web servers because Web development is all they know, I'm just pointing out how it's less efficient that native apps.

here: https://ledger-cli.org/doc/ledger3.html

I imagine it's because whomever created it is a web developer, primarily.

There's a wide variety of reasons.

1) People learned to build web apps for other reasons - their job, other projects that were multi-user, etc. Now they're comfortable working in that language and deployment model

2) They can access it from multiple places. I can view it whether I'm on my desktop, laptop, phone, tablet, etc.

3) If their laptop gets stolen or destroyed, they don't have to worry about having lost the data. (3rd party syncing solutions put you back in the 'my financial data is now on someone else's server)

4) If you have other self-hosted apps, you can double (triple, etc.) up on things running on your web server, database, etc.

5) I can back up all my self-hosted apps by backing up my database and config files, instead of worrying about how each individual app stores the information, etc. I know I can dump or replicate a database. It's something I've been doing for decades.

6) If I need something to be highly available, this is something well understood for web apps. I know how to set up multiple databases and handle failovers. I've been doing it for decades.

7) I understand how to model performance in web applications. I know well how to tune nginx, php-fpm, postgres, etc. I know how to trace requests through them. I know how to debug issues with them. This is all heavily standardized. The same can't be said for desktop applications.

I'm sure there's a dozen more I'm not thinking of off the top of my head, too.