My return to desktop applications | Hacker News Reader

My return to desktop applications

ashlan.com

193 pointssamemail88195 comments

Most comments are about owning your data or running your own server. But what’s also important is decoupling the mechanism of distributing or syncing the data (for access from different locations/clients) from actually working with the data. Basically, this is the separation between file system and application.

The separation has two benefits: One can work with the data independently from internet access, and one can choose between different applications that understand the data format, including writing your own, without having to depend on a third party. Controlling what is shared is then also independent from the chosen application.

Lastly, native applications can have the benefit of improved usability by adhering to the platform conventions and having better integration into native features.

> one can choose between different applications that understand the data format, including writing your own

Which is arguably "just" a much deeper form of "owning your data." One that I wholeheartedly agree with by the way.

By the way, I think what the author should have phrased it as is "local first" applications.

Exactly. It's like KeePassXC. It's a local app but the syncing of your password file is on you. You can choose to sync it however you want. You can choose to use Dropbox/Google Drive/etc or choose not to sync at all. The benefit you have a choice and you have complete control of the data/file. Nobody can take that away from you.

Can you open your data without KeePassXC?

The database is an open format I think?

I don't know what qualifies as an open format, but there're enough open source implementations (including original KeePass) and format descriptions to work with this format in practice.

There is other software that can open it. You could even write you own with a library like this one: https://pypi.org/project/pykeepass/

I think the ideal case is having a web app in a self-hosting environment, but also having a robust API/client ecosystem.

For instance, I host TinyTinyRSS on my Sandstorm server, and if on a machine that isn't mine, I can just use the web interface to read for a bit. But I definitely have preferred client apps on both my phone and desktop OSes for devices which I use regularly.

Out of curiosity, which local client do you use on the desktop? I also have a TT-RSS server running on Sandstorm, but many of the client apps I’ve found require that you install a server-side plugin, which seems a bit more difficult there.

I use one somewhat unhelpfully just named "Tiny Tiny RSS Reader" by Stefan Prasse. He actually delisted it from the Windows Store, however, I have both the APPX files for sideloading it, and he did post the source online. I actually had an issue with it recently, and have been monkeying with the code, and sent a message asking if I can republish it with fixes, as it does not have a license at present.

If you want me to send you the Appx, hit me up at me (at) ocdtrekkie.com

Also, if there's a TTRSS client you really want to get working with the Sandstorm version, kick open an issue on the repo and let's see what we can do. (https://github.com/zenhack/ttrss-sandstorm/) Usually I've found the biggest challenge is many client apps don't support HTTP Basic Auth, which is what the Sandstorm API requires. If the server-side plugin will work in the Sandstorm environment and isn't detrimental to the package, maybe we can include it.

I have noticed a trend recently of high quality, free apps disappearing from app stores. I wonder if it is the changing app store/play store guidelines and changes are making it too difficult to keep up with the changing requirements to keep the apps in the store.

In this case I believe it's because the app was written principally for Windows Phone, which is dead, though I really like it on desktop Windows too. The author moved on to writing a PWA version instead.

There is a bit of a general runaround to maintaining app store presence, keeping versions up to date and stuff, if someone doesn't want to use an app anymore personally and also aren't making money on it, I definitely can't fault them for delisting it.

> There is a bit of a general runaround to maintaining app store presence, keeping > versions up to date and stuff, if someone doesn't want to use an app anymore > personally and also aren't making money on it, I definitely can't fault them for > delisting it.

I think you've hit the nail on the head, its like an extreme version of software rot.

This decoupling is important, true. But not for all applications. Especially applications you'll open at multiple machines at the same time (like password managers), syncing could become an issue, or at least tedious, since file-based syncing is (afaik) always all-or-nothing with single files. Sure, you could then switch to use multiple files, but then portability suffers.

> But what’s also important is decoupling the mechanism of distributing or syncing the data (for access from different locations/clients) from actually working with the data. Basically, this is the separation between file system and application.

Is there any good FOSS middleware to handle this? CoreData (based on sqlite) can sync data to an iCloud CloudKit container[1]. Firebase can do this[2]. And Couchbase-lite-C can do it with JSON documents[3].

Couchbase is the only system I know of that does this transparently and is open source across the board. But for some reason no one seems to be using it.

[1] https://developer.apple.com/documentation/coredata

[2] https://en.wikipedia.org/wiki/Firebase

[3] https://github.com/couchbase/couchbase-lite-C

I think there's going to be an increasing push for people to own their own data, from whatever application it is they are using. Tim Bernes-Lee's Solid [1] is aiming at that idea and a lot of the new personal knowledge management tools like LogSeq [2] and Obsidian [3] can work from a local file. My own browser bookmarking plug-in BrainTool [4] reads and writes plain text (in org-mode format) from a local file. BTW I'm advocating for org-mode as the universal exchange format for productivity apps [5].

[1] https://solidproject.org/

[2] https://logseq.com

[3] https://help.obsidian.md/Obsidian/Obsidian#How+we're+differe...

[4] https://BrainTool.org

[5] https://braintool.org/2022/04/29/Tools4Thought-should-use-Or...

I find SOLID frustrating because I feel like it's chief selling point is that Berners-Lee is pushing it. I think it's a fundamentally flawed design: It still relies on apps which are hosted by other parties and can hence disappear, or of course, do evil things.

Retaining your data is important, but so is retaining the application. Google Takeout is a great example: You can download all your data but literally nothing ingests most of it and makes it at all useful, so it's mostly pointless to download a bunch of JSON files.

Do you know of alternative efforts besides SOLID? Would love to research this some more.

I think a far better approach is to just self-host your own applications, instead of just your data like a SOLID pod. Several solutions assist with this with varying levels of security isolation and open sourceness.

I use and contribute to Sandstorm.io, but also on the open source side there is also YunoHost, and on the proprietary side is Cloudron and Umbrel.

Self-hosted applications can still be closed source, but hosting them locally means you can monitor their behavior, and they should continue to work even if the developer shuts down and abandons it.

Selfhosting everything yourself is not realistic for the majority of users. And even experts who have the time, money and expertise, can't selfhost everything, after all at some point they must exchange data and trust others work. I mean, just take this forum. How would you selfhost this place which needs a centralized power which upholds order? How would you realize a good moderation and trustable voting on a dezentralized forum, with sane solutions? Sure you could decentralize this all and play blockshit-bingo, for a high price. But until we have a true dang-ai, forget about the quality of moderation. And this is just for a simple text-forum, let's not talk about youtube or the like... That's the point were solutions like solid make sense. Places where centralization is unavoidable, but also places were people are to lazy or "poor" to use other solutions, thus a compromise for the real world.

Oh god! BrainTool is the extension I've been looking for so long. My note taking usually starts with some bookmarking or link from a forum or post and it was always difficult to be consistent to manually storing each link/bookmark on Obsidian or Joplin so I always end up with a messy bookmark list or notes with missing references.

This is perfect, thank you so much. I'm going to try it.

So far I'm pretty happy with TiddlyWiki - steep learning curve and a bit of a hassle to get setup right, but I can't go a day without it if I'm hacking at something. https://tiddlywiki.com/

Highlights:

* You can drag-and-drop plugins from other wikis you come across

* You can write own plugins and customise everything

* Hostable as a self-contained file (one index.html) and it builds itself (a quine)

* You can host it in Node if you want stand-alone note files

Still didn't figure out a good mobile workflow though.

> Electron and PHPDesktop might be considered the future of desktop development as they allow rapid development of desktop like software.

And unfortunately also Flutter.

I am developing my own cross-platform, desktop-only GUI system. It is rough going for me, but the ideas in it are really not that hard. What surprises me is that no company has stepped up to fill the gap left by GTK, Qt, wxWidgets, and the OS-specific frameworks other than Flutter and Electron. Flutter and Electron can't even manage multiple windows. It's a shame. Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework. And for some reason, academia doesn't seem to be interested at all in GUIs and other such things, despite there being a lot of interesting and difficult problems.

You got my curiosity. Any links to share?

Links to my GUI system? If so, it's early days, and there is nothing public. I am using F#, my own bindings to GLFW, and SkiaSharp, which is an existing .NET binding and library over Skia, to prototype things. At this point, I have a basic windowing system down, and now I'm trying to figure out the right interface to the events that can be sent out to whatever wants them and also basic "widget" elements. But I am considering multiple windows from the start, and I have that working do a decently satisfactory level right now. Things will definitely keep evolving as I learn things though.

To be honest, I never wanted to create this. I originally wanted to experiment with making my own desktop programs but found the existing solutions too unsatisfactory or complicated. I also do not want to use C++. The closest I got was using Racket's GUI toolkit, but I found I was going to have to be writing a lot of custom widgets anyway, and I was also dealing with bugs and slogging through terse documentation.

>Flutter and Electron can't even manage multiple windows

How so? I use multi window Electron apps, VS Code is one of them

Do your VS Code windows interact with each other?

I think parent is thinking about a behavior like the tool panels in Photoshop.

I work on an Electron app that has multiple windows interacting with each other in all kinds of ways. It's quite possible.

It's possible in the sense of how webapps do it, because that's basically how Electron does it. Electron creates several different processes that talk to each other through an inter-process communication model. Electron's process model is rather complex.

https://www.electronjs.org/docs/latest/tutorial/process-mode...

This is not how native desktop applications handle multiple windows, although they could obviously.

Yea, it can be done: https://www.electronjs.org/docs/latest/tutorial/ipc

That's a low barrier for what is meant by managing multiple windows.

What I mean by "managing multiple windows" is a single OS-process and application managing multiple windows: creating them, destroying them, hiding them, etc. Electron cannot do this. You are basically creating separate applications that talk to each other through inter-process communication. I mean, it says it right there in the link you posted. The process model of Electron is complex.

Here's how you create multiple windows in my in-work prototype:

    let windowing = Windowing()
    windowing.Initialize()
    windowing.CreateWindow("Window 1")
    windowing.CreateWindow("Window 2")
    windowing.CreateWindow("Window 3")

    while(windowing.WindowsAreOpen) do
        System.Threading.Thread.Sleep(100)

Would it be one full electron process for each window ?

That would be quite a load if the user decides each current pane is now an independent window on the screen.

I remember JVM apps hitting this same issue. There are many ways to make two entities talk together (if IPC wasn't an option, a local IP channel would work as well, albeit way more costly), but then the performance would be abysmal, for apps that were already handicapped. Same process windows are way lighter than that.

It's possible to do, but it's not what I meant. I have four windows open in Visual Studio Code right now, and Visual Studio Code has 81 separate OS processes running. There is not one application, one OS process, nor even one programming language running all of that.

So true. I love tools like https://tiddlywiki.com/ that *just works* - across platforms, can be shared without problems, and is flexible enough to make all sorts of simple tools without having to use a terminal, add n dependencies and compile things. Please share if you know similar software!

> I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework

Developer adoption is a big one. Why should I trust your NewGui to still be updated and improved 5 years from now?

Even Microsoft has a whole graveyard of dead GUI frameworks (WinForms anyone?)

I doubt I ever release mine, if I even complete it. For companies that can manage this, there's no reason why they couldn't obtain adoption. Just look at Electron, Flutter, VS Code, etc.

Microsoft is one of the examples of what not to do. They have made great strides with .NET Core and now .NET 6+, but I have no idea why they're doing what they're doing in the GUI scene.

Hah, WinForms is still my go-to for quick Windows GUIs. Perhaps is WPF used CSS instead of god awful XML boilerplate overrides for styling I might use that.

Same here! Hard to match WinForms productivity for small apps, especially if you cut your teeth in the 90's VB era. And you can push WinForms really far with the fancy controls in the Syncfusion Community License.

Winforms is absolubtely my go-to as well after using it briefly at work for a project around 2015. It was old then, but I really liked the way it worked, it was sensible and c# is always easy compared to c++

> Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework

Here's one: cross-platform GUI apps will, without exception, feel subtly wrong on every platform. Each platform has its own "way" of doing things.

Right, but the alternative is rarely a native app for each platform, it's Electron in most cases.

I imagine you could make something that at least gives you as much opportunity to fit in as electron, with accessibility support, and some new ideas, be it from a development paradigm, inbuilt widget sets, or something else.

I mean, the better (for users, maybe not for developers) alternative is to buck up and build a native client for each platform. Share as much code as you can portably, but you'll have a small platform-specific shim around the edges to call into the shared business logic and implement the platform-specific window management and bling.

Yes, this is very reasonable for some kinds of software. For other kinds of software, the users may consist of a small team - say the teachers at a school or a specific research group or a family - where some are using Mac and others are using Windows

Sometimes, developing a simple tools should be simple (without all the overhead of shared business logic, etc.), but in my experience, there is too many obstacles to make simple GUI tools that just works. It's a shame, I believe that many teams would have increased their efficiency if there were easier ways for individuals to make simple tools adapted to their specific needs. Now, they are typically stuck with Excel...

>but you'll have a small platform-specific shim around the edges to call into the shared business logic and implement the platform-specific window management and bling

No you won't. We've had cross-platform libraries like SDL to do that for ages.

Electron isn't that revolutionary - it's basically just shipping applications in containers. It just happens that the container is a web browser, but it could just as well be the JVM or any language runtime with a GUI layer.

The "interesting" part, if anything, is using a document-based paradigm to build a GUI-driven application, with separation of concerns between code, layout and semantics. But none of that has to be done with webcode.

> Electron isn't that revolutionary - it's basically just shipping applications in containers. It just happens that the container is a web browser

Except that the backend part of the app doesn't run in the browser, it runs in Node. So it's not shipping applications in containers, even if one views a web browser as a container.

>Here's one: cross-platform GUI apps will, without exception, feel subtly wrong on every platform. Each platform has its own "way" of doing things.

You're stating as an objective fact what is you own aesthetic opinion.

Yes, different platforms are different, and the same app behaves differently on different platforms. But most people don't switch platforms or use the same app on different platforms routinely, and it wasn't an issue prior to Electron, when the most likely manifestation of this would be the use of the same browser on different platforms.

You’re reading it the wrong way around I think. Think in terms of cross platform applications that try to fit in on their host application, except they aren’t using the native widgets, similar to what Qt did historically.

Then you have something that looks as if it should behave like a certain widgets you’re used to, except they behave in subtly different ways. That’s where that idea comes from.

Now if you go all 90s WinAmp and create all your own widgets, then that mostly goes out the window, until you enter a text box…

But is subtly feeling wrong a massive barrier? And feeling wrong for who - I would guess that it is mostly people who would have done fine without a GUI that would notice, for the others (or us all?), most GUI apps would feel slightly off anyway

There's an attempt to make this work for Rust desktop applications. There's the winit crate, which does cross-platform windowing and event loops. There's egui, for menus and subwindows. There's rfd, for file dialogs, which are special for security reasons. And there's wgpu, for cross-platform 3D.

I'm using all of these in my ui-mock,[1] which is a GUI for a game without the game. It has 3D graphics with 2D GUI elements on top. I'm using this to shake down all the cross-platform problems for my metaverse client. My own code, which is 100% safe Rust, has no platform dependent code.

Results are pretty good. There's minor dirty laundry in those libraries, which has been reported to the various maintainers. Stuff like this:

- You can get a file dialog hidden behind the main window, which, in a full screen program, is a real problem. Mostly a Linux problem; works fine on Windows.

- Full screen on Windows mode under Wine 7 crashes Wine. Known Wine bug.

- Warnings from WGPU, but it works around all of them with some minor performance loss.

- Cross-platform packaging, to make a Windows installer without Windows, isn't implemented yet.

So, not big stuff. A lot of stuff works that you might not expect to work, such as profiling with tracy. Wgpu is taking care of Vulkan vs Apple's Metal. (Apple just had to Think Different, to the annoyance of everybody doing 3D.) Opening a web page in the default browser is cross-platform. You can cross-compile - I build the Windows version on Linux, without using any Microsoft tools.

With some more work, I could make this work on WASM and Android as well, but that requires some special casing, mostly because WASM doesn't have proper threads.

So cross-platform desktop development is working pretty well. Most of the problems I'm running into would not appear in a more typical application.

[1] https://github.com/John-Nagle/ui-mock

Worth noting for c (and hence your niche language of choice via ffi) there is also glfw for windowing and webgpu-native which is from the same folk as wgpu.

EDIT: and also libuv which is the cross platform event loop for node.

Incidentally, if there's anyone into Windows installers and Rust, see [1][2] There's a Rust bundler for making installers cross-platform. Mac is done, Linux is partly done, and Windows needs someone familiar with the arcane world of Windows install files.

[1] https://github.com/neovide/neovide/issues/1374

[2] https://github.com/burtonageo/cargo-bundle/issues/116

> Here's one: cross-platform GUI apps will, without exception, feel subtly wrong on every platform. Each platform has its own "way" of doing things.

Is that really true though? No one cares about this for webapps, so why do they care about it on desktop apps? In my opinion, this is one thing that web apps have taught people, in that there isn't much sense anymore about having OS-specific "look and feel", if that is even a thing, and I think the OS-makers agree because even Windows and macOS are chock full of inconsistencies. And in general, I hate moving across apps, like Visual Studio and Outlook for example, that adopt the OS-isms of their host OS, because it means you gotta learn the same app twice.

About the only real difference are the way menu bars, toolbars, and docking are handled, and probably file pickers. Outside of that, I don't see why an app that looks the same across three different OSs is bad.

> Is that really true though? No one cares about this for webapps, so why do they care about it on desktop apps?

Web apps are easier to learn and functionality is more discoverable often at the price of having less functionality.

Desktop apps are consistent, and have more functionality, but unlocking that functionality takes a lot of effort on the user's part.

>wxWidgets

This is, in theory, what you're asking for. It's not perfect. But nobody uses it and there are few contributors. In most threads lamenting Electron, it barely gets mentioned. So:

>I really don't see any massive barrier

I think the barrier is a lack of interest. If anyone thinks about building a cross-platform native-widget GUI framework, they only have to consider briefly the near-total obscurity of wxWidgets and how much work it would take (a lot!) to even reach feature parity with the same.

I'm not sure there's no interest. See the uptake in Electron apps. And people are chomping at the bit for Flutter to fully support all desktop OSs.

I'm curious which operating systems people are still waiting for. We have delivered Windows, macOS and Linux on stable as of Flutter 3. We don't have plans to add more, but people in the community are working on things like embedded Linux: https://github.com/sony/flutter-embedded-linux

Disclosure: I'm a Developer Relations Engineer for Flutter

Thanks for the update, although it should be pointed out that that was apparently very recent, as in May 2022. It's not like it's been there and makes my comment that people have been waiting on it inaccurate. I wasn't aware of stable macOS and Linux support, so thanks for pointing it out. As far as I know, Windows was the first to get stable desktop support from Flutter, and that was just at the very beginning of this year. Even now, the official Flutter Desktop webpage links back to that release as "new": https://flutter.dev/multi-platform/desktop

Flutter still cannot manage multiple windows on desktop, which makes it a no-go for my use cases, and it doesn't look like it's coming anytime soon: https://github.com/flutter/flutter/issues/30701. The original issue has been sitting around for four years.

Also a comment from May saying that it’s under active development at the moment.

We are aware that multiple windows is an area of interest for potential users of the desktop platform. You can see the proposed API we have published for feedback: https://docs.google.com/document/u/0/d/11_4wntz_9IJTQOo_Qhp7...

> I think the barrier is a lack of interest.

Probably not in writing C++ apps.

There's also React Native Windows (which despite the name also has a macOS version). It's a little experimental, but Facebook's Messenger app for windows and macOS uses it (and I think Microsoft are shipping something minor using it), so it does have some production usage.

I'm still hopeful we'll get a high-quality cross-platform GUI framework out of the Rust ecosystem at some point. But unfortunately it's looking like it might be at least a decade away at the moment.

> I'm still hopeful we'll get a high-quality cross-platform GUI framework out of the Rust ecosystem at some point. But unfortunately it's looking like it might be at least a decade away at the moment.

Given the way Rust has evolved, I don't really hold much hope that it'll be any better than the existing options. Rust keeps intriguing me, but then I start looking into it, and everything is just extremely complex. I'm not sure I have the time to really learn it or will even like it. For my own work that I'm doing, I'm using F#.

> the gap left by GTK, Qt...

What happened to Qt? As far as I've seen, it's actively developed and as good as ever.

By "gap left" I mean gap in usability and complexity. All those frameworks are both complex and limited.

Hmm, perhaps I'm missing something, but for most apps, I don't really see how you could do it much simpler than Qt does.

> What surprises me is that no company has stepped up to fill the gap left by GTK, Qt, wxWidgets, and the OS-specific frameworks other than Flutter and Electron. Flutter and Electron can't even manage multiple windows. It's a shame.

It's not that these toolkits are gone -- it's that the desktop metaphors you are looking for are gone. Or at least, as gone as these toolkits: neither of which is dead by any measure, but your assumption that they are dead likely comes from the fact that the target users for these have almost completely vanished.

Even most builtin Windows apps these days are single window square boxes with a webpage inside. There is a reason Qt the company was trying like crazy to target the "single window, no widgets, 3D graphics" market.

I don't think they're gone. What I meant by "gap left" is that they are not very good, in that they are extremely complex.

And I don't buy the argument that the market is gone. Everything we interact with on the computer is through a desktop app. The fact that so many apps are written in Electron tells us two things: (1) many people still need to write desktop apps, (2) there is no good cross-platform framework to do so.

Electron is extremely complex too, seeing as it embeds a webview.

I absolutely agree with that, and that's why I don't want to use it either. Flutter is intriguing, but it uses Dart, something I'm not interested in.

> (2) there is no good cross-platform framework to do so.

Chrome and Firefox are pretty good cross-platform frameworks. They are so good than the OS vendors keep coming out with workalikes like Edge and Safari (and by the way, both are really good).

As a software publisher I love it because if it works in Chrome and Firefox, I mostly don't have to even care if you have a Mac, PC, smartphone, or something completely different. You go to my URL, and there it is. Stuff like PWAs and Electron are great, too, because I can make it easier for users to get into my app - just launch the application. No more two step, launch browser, type in URL or click on bookmark.

Good cross-platform frameworks for what?

For web app development, you need, at a minimum, three separate programming languages but typically more, a host server, and a desktop app to render your app. That is not a "good" framework, in my opinion. And the number one thing support people ask is "have you tried it in Chrome?". Isn't that weird thing to ask? "Can you use another desktop app to verify that my app is working or not?"

Web and mobile apps do not support the types of apps and functionality that I am interested in. That's fine that people are happy enough with web and mobile app development. That's also why I do not care to even address those scenarios, not to mention that they are completely different from desktop apps.

> Because for a team of competent folks, I really don't see any massive barrier to creating a cross-platform, desktop-only GUI framework.

The barrier is opportunity cost; there's plenty of actively maintained, cross-platform—often desktop-only or desktop-first—GUI frameworks, both ones with many language bindings and ones that are specific to particular languages. Sure, a competent team could make and maintain another one that maybe fits their preferences better than the existing ones—or they could make a useful app using one of the existing ones.

> And for some reason, academia doesn't seem to be interested at all in GUIs and other such things,

Academia is interested in them if it's about new UI paradigms or something, but not it is just bikeshedding.

My personal hunch is that the only gap is a developer training gap. Since ~2014 there were a bunch of copy-pasted bootcamps selling "MEAN stack" or "JAM stack" or whatever, but all of them centered around JavaScript. It seems like the assumption is that everyone does web, so we have to shoe-horn JS into making native apps with tech like Electron, React Native, etc. But, the JavaScript ecosystem is actually very complicated. I'd say it's just as complicated as Qt or GTK, but maybe they lack the kiddie pool introduction that making small JS programs for the browser offers.

If JavaScript isn't your comfort zone or you don't come from frontend web development, Qt in particular is awesome. It comes with a ton of primitives that you don't have to reinvent from scratch. It has UI controls that do the complex stuff you want without having to pile a bunch of event binding code on it. You don't even have to write C++.

It bothers me every time I read about Electron's redeeming quality being that it allows web developers to build native apps. Python is a "web" language, and you don't need to write anything but Python to make a great Qt app. A famous Electron app like Slack could have very well been written by web developers using Python, and I bet it would feel snappier than today's Slack.

Good luck with your GUI system, btw. I'd love to see what you make.

I've been dabbling with a desktop toy application. I have it finally "done" and am in the process of working out packaging it so folks can use it.

It's written in Java with JavaFX. Short term I'm reasonably comfortable with folks downloading a "fat jar" and then grabbing the JDK on their own, and, perhaps, firing off a .sh or .bat file to run it. Mostly because I don't have a Windows box to try the whole jlink or jpackage process.

But then I started packaging it up for delivery.

JavaFX has platform dependent shared libraries, all of which would need to be bundled in the fat jar.

After building it, the result came out to 48MB... .. .

This "app" is a pane with about 20 controls on it and a GO button. It's less then 2000 lines of code. And the deliverable is 48MB.

I know, I know, that fancy animated GIF icon on that forum for someone's Avatar is probably 48MB.

But that doesn't mean it doesn't chafe me to do so. That's not even including the JDK.

I shouldn't care, but it was soul crushing.

On total whimsy, I tried Flutter. I downloaded it, and built "Hello World" for macOS. Not only did it take an eternity to compile (on my modern, SSD enabled, eleventy gigablip iMac), the result was 108MB. And that was just for the Mac version, I'd need 2 others for Linux and Windows. The compile time was glacial (I know, its got hot reloading to speed things up).

I'm sure the Electron vesion artifact is similar.

I should just shut up and take it, but it rubs me the wrong way. I'm currently exploring the possibility of doing it as a PWA targeting Chrome, dunno how well that will work, but apparently with Chrome you can save and load local files (which is something I want to do). But I can't see my large vision being done as a PWA.

I should put my head down, blinders on, and push on through.

But for the moment, I'm irked.

Hey if you are so desperate to the point of considering a PWA (I like them, but the support isn't good and the UX isn't good either, it's also not even supported by a few major browsers such as Firefox) check out Tauri at https://tauri.app/ which uses the system web view and generally yields binaries of around 2MB (except if you use AppImage which is a bit larger of course).

Hi! I'm a PM on the Chrome web platform team working on advanced apps including PWAs.

Can you tell me more about what's missing in PWAs in terms of support and UX?

PWAs are well supported in Chromium browsers. Can't speak to Firefox support, but I hope as adoption and usage grows we'll see them add more support.

Hi I'm happy to provide some context: When it comes to support on Chromium it works well but there a few things that still make them less than ideal such as the toolbar that includes the extensions icon and doesn't use the system styling (at least in the case of Linux with Gnome).

Something else I feel would make PWAs much more interesting to most people is if the browser _prompts_ the person to use the PWA, if I'm not forgotten Chrome does this on mobile but not on desktop. You also don't really have much option when it comes to customizing the PWA if the provided manifest gives a bad icon or something like that.

But overall the Chrome browser is the best for PWAs right now on both desktop and mobile. Firefox however has dropped support _completely_ for PWAs which is why I personally don't even consider it an option anymore. Some discussion here: https://connect.mozilla.org/t5/ideas/bring-back-pwa-progress...

AFAIK Apple doesn't really support them too (although theoretically Steve Jobs really liked them when the iPhone first launched) because it undermines their business model of the App Store. I wish companies would use them more because they truly are the best way to develop cross-platform right now (and the PWA size is just the size of the page load for the SPA!)

while Mozilla has dropped official support I've had no issues using FirefoxPWA addon for similar functionality

Tauri just hit 1.0 yesterday too. Looking forward to this saner future for packaged up web applications!

Yeah, I was there was a more mainstream solution that was free/open source, could create small binaries, and have a good builtin GUI. Usually one of the 3 is missing.

48MB? Nowadays laptop are sold with 500GB SSD and minimum of 16GB or RAM. What matters are the performances. The JVM outperforms all the electron and JS app out there. I would much prefer to download a 300MB app than use those slow JS web apps running on top of the browser.

> Nowadays laptop are sold with 500GB SSD and minimum of 16GB or RAM.

I know we are living in a bubble as HNers, but this can be disproven quite easily. I opened the website of MediaMarkt (a major European electronics retailer) and clicked (literally) the first laptop I saw:

https://www.mediamarkt.nl/nl/product/_acer-aspire-3-a315-35-...

4GB RAM, 128GB SSD.

OK, maybe you consider that one too cheap (although there must be people buying it). Let's click the first 'reasonable' one:

https://www.mediamarkt.nl/nl/product/_acer-nitro-5-an515-57-...

512GB SSD but 'only' 8GB RAM. (And this is supposed to be a gaming laptop!)

I've never used a java app that didn't feel like a total clunker, especially with time to start up. This includes simple little utility apps, like testing SMTP servers.

I won't dispute electron apps are also often slow, but there are counter examples, such as VSCode, that are actually reasonably snappy on fairly modest systems.

What's the counter example that runs on JVM where I might not notice it's running on the JVM? (I'll also freely admit I've spent the last decade avoiding java apps when I can, because I've never had a pleasant experience due to the combination of performance and early-2000s aesthetic. Maybe the situation is vastly different today and it's just me that's outdated)

As far as Java apps that feel snappy, I would imagine Minecraft qualifies?

Otherwise on the JVM in general, something like jwhois is very snappy to start up.

Not snappy - but intellij is in my opinion a good Java app.

"Not snappy" is an understatement. It's a memory hog, and can visibly lag (keystrokes and mouse clicks) on my 3-year-old laptop depending on the project I have open. I probably wouldn't use anything else for Java or Scala development, but ugh, I would not call it pleasant to use from a performance perspective.

"Is an understatement". You are probably right. When I think a bit more of when I have opened huge monstrosities of Spring boot apps then it is quite slow. But for small projects I think it is "okay" and very feature rich.

I’ve been down a remarkably similar path to yours, and I came to the conclusion that if you want native, cross-platform, low-footprint desktop apps, then Qt is honestly the only game in town.

I know there are other frameworks - imgui, for example, which uses GPU rendering for its widgets - but none that I’ve found check all the right boxes.

To me, those boxes are: “I want to write an app using one framework, and when it’s done, I want the person on Mac to think it was made with AppKit; the person on Windows to think it was made with UWP; the person on Ubuntu to think it was made with GTK.”

Qt is the closest I’ve found, and it’s still not totally what I want (not including it’s licensing scheme, which also is a huge turn-off).

I like Qt too, but when it comes to packaging size, I seem to remember it was a pretty big chunk. 20 or 50 MB or something? I therefore chose wxWidgets over it, for a recent project.

Agreed Qt is the play for desktop apps. I use it at work quite a bit, and if you’re careful enough you can just rely on upstream packaging for Linux. Windows isn’t horrible if you’re only relying on base/core and the platform plugins. It’s not tiny, but at least an order of magnitude smaller than an electron app. Mac I do not have any experience with so I can’t speak to that.

It really is a fun framework to develop with and it’s signal/slot feature is a delight. I’ve recently developed a Wt web app and the learning curve was basically zero after having the Qt “expertise” I do, quoted because even after 10 years with it I’m always learning something new. The more I learn the less I know kind of thing.

This is my conclusion too. For cross platform, Qt is the only serious choice.

I've been dabbling in GTK and if it's just a personal or linux app then I'll do it in GTK using javascript/typescript (and I'm very curious to try out GTK for windows/mac at some point), but for now a serious app, Qt is the real choice.

How do you make a single Qt app look like both UWP and GTK? I'm not aware of any Qt Quick Controls 2 style to make QML apps look like GTK apps (like the Adwaita theme), and Qt Widgets on Windows looks like Win32 rather than UWP (either Windows 8 or 10 settings, or the newer rounded colorful Windows 11 style).

If you want to make a nice looking desktop app there are only 2 games in town:

- the native platform framework. - electron/web

As much flack as slack gets for example it looks 50x better than any QT, GTK, Java, or WxWidgets app I’ve ever seen.

Another thread here was talking about how they WxWidgets to make an app that looked native on each platform with a small binary.

Unfortunately not a single one of these screenshots looks like it belongs in a modern desktop. https://www.wxwidgets.org/about/screenshots/

Went through similar feelings a few years ago. Ended up going old school with C++ and wxWidgets as UI library. Felt to me like the best balance between

- wanting a single code base that I could compile for Mac/Win/Linux

- startup times measured in milliseconds

- snappy and native looking UI

- a executable size of 10MB (Mac) / 17MB (Win) / 12MB (Linux).

The bulk of that exe size is the wxWidgets UI library I statically compiled in. If you wanted to get that crispy couple of hundred kilobyte sized binary you'd probably have to directly use the native UI API of each platform, and therefore be in for not being able to reuse very much between each platform. (github.com/allanrbo/filesremote if anyone wants to see the result)

Real desktop app development feels like a dying art. (And arguably my use of wxWidgets made it not even "real real"). And I feel like it's not even harder than trying to shoehorn the web dev tools into desktop apps with things like Electron. It's just different and sort of forgotten it seems :-)

>And arguably my use of wxWidgets made it not even "real real"

Doesn't wxWidgets wrap and abstract over the native APIs for each respective platform?

Seems real enough to me.

I once decided I'd write a GUI in pure win32 (when Windows 7 was new) and the experience really, really sucked. In my book there's no shame in using a GUI library any more than a socket library.

> If you wanted to get that crispy couple of hundred kilobyte sized binary you'd probably have to directly use the native UI API of each platform, and therefore be in for not being able to reuse very much between each platform. (github.com/allanrbo/filesremote if anyone wants to see the result)

No need for three different native code bases, you should simply use FLTK. It's actively maintained, works on win/lin/osx and is just 300kB when statically linked. However it doesn't look native, if this is a serious issue for you.

Nice! Will try FLTK for my next GUI project.

For such a simple application (pane with 20 controls and a GO button, 2k lines of code), I think Lazarus (or Delphi) are fantastic solutions.

Either of these two would give you Windows, Mac, and Linux coverage for your app (and in the case of Delphi, also mobile apps).

* Lazarus - https://www.lazarus-ide.org

* Delphi - https://www.embarcadero.com/products/delphi

> On total whimsy, I tried Flutter. I downloaded it, and built "Hello World" for macOS. Not only did it take an eternity to compile (on my modern, SSD enabled, eleventy gigablip iMac), the result was 108MB. And that was just for the Mac version, I'd need 2 others for Linux and Windows. The compile time was glacial (I know, its got hot reloading to speed things up).

I'm curious how you got 108mb. Here's what I'm seeing:

  $ flutter --version
  Flutter 3.0.4 • channel stable • 
  https://github.com/flutter/flutter
  Framework • revision 85684f9300 (7 days ago) • 2022-06-30 13:22:47 -0700
  Engine • revision 6ba2af10bb
  Tools • Dart 2.17.5 • DevTools 2.12.2
  $ flutter create hello_world && cd hello_world
  Creating project hello_world...
  Running "flutter pub get" in hello_world...                      1,764ms
  Wrote 127 files.

  All done!
  In order to run your application, type:

    $ cd hello_world
    $ flutter run

  Your application code is in hello_world/lib/main.dart.

  $ flutter build macos

  Building with sound null safety

  Building macOS application...

  $ du -ah build/macos/Build/Products/Release/hello_world.app | tail -1
   44M build/macos/Build/Products/Release/hello_world.app

Note, the release build is significantly smaller than the debug build, which includes a full Dart VM for hot swapping application code:

  $ flutter build macos --debug

  Building with sound null safety

  Building macOS application...

  $ du -ah build/macos/Build/Products/Debug/hello_world.app | tail -1
   98M build/macos/Build/Products/Debug/hello_world.app

Note, on the glacial compiles, here is what I'm seeing on my M1 mac laptop:

  $ time flutter build macos

  Building with sound null safety

  Building macOS application...
  flutter build macos  1.20s user 0.59s system 47% cpu 3.801 total

It's slower than building web pages in vim, but this is comparable with compiling desktop applications in Xcode.

Disclosure: I'm a Developer Relations Engineer for Flutter

44 megabytes is still quite large, is what the parent is trying to say. I don't know enough about binary sizes but it seems that it could be smaller.

No, the parent is trying to say that hello world is 108MB which is not true at all.

Hard to make a good point about binary size when they outright lie.

Looks like they probably didn't lie but built the debug version by mistake.

I mean sure, but I presume they weren't talking directly about the exact size but that other desktop apps can be built for (at least) an order of magnitude fewer megabytes. In other words, it's not exactly 108MB that they really care about, it's that Qt or other frameworks could make a hello world app at 10MB. That's how I interpreted their comments anyway.

If you want a sneak preview of the functionality that can be delivered in Flutter at about the 100mb mark, sign up for the beta of https://www.superlist.com/

Well if it's as laggy as your homepage then that's not saying much. On my phone I can't even scroll down without lagging.

As a potential user, I'm typically really pleased with a fat jar download option! In an age where desktop apps are less common, we beggars can't be choosers anymore so 50 MB is perfectly acceptable.

I mostly use Qt these days though for desktop apps I build. It takes a minute to learn but once you get the basics down you're off to the races. And the cross platform story is awesome. I literally don't even test on windows or mac anymore until right before a release, because if it works on my linux dev machine, it's gonna work on windows/mac.

I recall building my first FLTK app in 1998 and being somewhat dismayed that it was more than 1.2 MB in size. With some craftiness I had it down to just under a Meg.

It was a 3D model viewer that allowed me to load some common 3d files including vrml and do some basic manipulation like picking a face, moving it, changing its color etc.

This was all in a single static executable. Maybe OpenGL was linked dynamically don't remember.

What the fuck happened in the last quarter century? The desktop apps of today that do little more than my viewer take three orders of magnitude more space and run slower than my thing did on a 350MHz Pentium (GPU performance excepted as there have been impressive progress on that side).

And yeah, no they are not "fast enough".

15 years ago I was able to do Skype group calls just fine on the hardware available then. Since then, camera resolutions have hardly improved and yet MS Teams grinds everything else to a halt when a call starts. Just another example of things regressing. I think it has to do with a move away from tools that do one thing well to these Kraken platforms that want to eat your life.

Counterpoint: Coolplayer (http://coolplayer.sourceforge.net/) is a fairly capable MP3 player, weighing in at ~500 KB. I've used it to play MP3's on 486's back in the day.

The closest modern equivalent would be Foobar2000. Foobar2000 is much larger than Coolplayer ever was, but it's also far more capable, has plugin support etc.

On the other hand, both players are small compared to some modern alternatives.

> I know, I know, that fancy animated GIF icon on that forum for someone's Avatar is probably 48MB.

I know you are trolling but I cannot keep myself from reacting. Well done!

Would it be possible to use Swing and make a runtime image with only the minimal modules needed?

Not sure what you've tried, but here are a few more options with the Java version:

Try ProGuard, which can remove classes that aren't being used from your fat JAR. Sometimes you'll have to tweak the configuration to keep classes that it doesn't realize are being used, though (due to reflection use or whatever).

Try GraalVM, which can compile the entire thing to a native binary without a dependency on a JVM, even. I believe this will mean a separate build for each platform you want to support, though.

Not sure if these will lower the size of the download, but they're worth a try.

My production docker image with flutter web (frontend) and Actix-web (backend) is 13 MB.

I enjoined the ending paragraph tone. Alien like remark on the desktop app emergence and rising popularity after 2000.

On my end: being born two years before 2000, makes me a desktop apps powered man and frankly I've been moving away from them. I'm seeking order and density so I've moved to the dark side of the spectrum, towards clis.

There's hope in TUI like apps: like cashiers softwares terminals which displays some of both extremes. Until GUI are able to visually convoy meaningful symbols without ever using explicitly written characters, there's little gain in using them more the a solely characters driven interface.

Thise are personal considerations,

Hopefully I'm just a maniac that enjoy that intimate vibe interacting with a machine rather than clicking it.

> ... so I've moved to the dark side of the spectrum, towards clis

Do you mean the best side? CLIs are were the power is at, because it's the only place you can convert human thought into instructions the computer can understand. It's the only place raw desire can be converted into a string of demands that the computer can meet. GUIs offer a static sub-set of this functionality in exchange for accessibility of the masses (which is fine... Instagram doesn't need to be a CLI tool.)

> There's hope in TUI like apps: like cashiers softwares terminals

When I worked in a Vodafone call centre many, many moons ago, we had a system actually like this. The F1-F12 function keys were critical and the entire thing was insanely fast. They eventually switched to a web based solution and it was terrible.

Modern technologies favour the technologist, not the end user... they just happen to like it because they have no choice. GUIs, the shite they're built on, hold a monopoly.

Wrong.

The real issue isn't Desktop vs. Web, it is "people don't want to run their own servers".

Take email: with Dovecot, Postfix and SpamAssasin anyone can build their own email server. Almost no one does.

With Syncthing or Owncloud anyone can build their own Google Drive, iCloud or OneDrive. Very few do.

There are alternatives to WhatsApp/Telegram where you'd create your own server (e.g. Matrix). Almost no one uses them.

I don't need to run a server to run a local email client.

I also don't have the requirement for anyone to be able to join a project-specific IRC channel I'm hosting. In fact, quite the opposite, I DON'T want just anyone to join it.

For secure communication, I still use S/MIME (I may be in one of the last clusters of people to do so.)

It's entirely possible this article was not intended for you. It sounds like you have different requirements than the OP.

I tried and tried to get co-workers to use S/MIME. I was reliably able to get one other person on board, but no one else wanted the go through the hassle (and its not that much hassle!). So the two of us eventually abandoned it.

You don't actually need to run a server for bookmark management (his example).

You're taking applications that are pretty inherently network-connected, like chat and sync. Yes, those make very little sense without a server. Although syncthing in particular will work just fine actually.

But a lot of things don't require internet connectivity at all, not inherently. They largely stay on one device and that's fine. If they're to be shared between people or devices, very often attaching them to an email is better than "share this link with your friends (all they'll have to do to see it is sign up for our service so Growth can report those sweet sweet activations)"

Unfortunately as far as email is concerned this is not so true anymore. Many years ago I used to do as you described but eventually switched to hosted services due to the likelihood of any messages being sent from said self-hosted server being flagged as spam in the best case, or never received in the worst case as you'll receive an undeliverable message due to the sender requirements of many organizations.

As with most nice things the bad actors (spam, phishing, etc.) in society will abuse things to the point that we can no longer have them.

I've self-hosted my personal email for 25+ years, at a variety of ISP's and multiple IP's over the years. It's not fully automatic, not cattle, my pet. It takes focus and effort. I do it because I like the independence and do not have any more spam than my big three accounts. Delivery was only an issue once. Microsoft. I filed a request to fix it. They fixed it in a couple of days for free.

Correct, the real issue is - the most beneficial thing for users is to only share data as needed, but what scaled and was profitable was "leak everybody's data everywhere all the time."

Now, the cracks are showing in this approach, mostly because of the ones who do it poorly. Perhaps the ones to watch out for though, are the ones who do it well, e.g. Google Apps?

I ran my own email server for a while and to be frank, it was a pain in the butt. Even though I spent a lot of time reading up on the proper way to set things up and tried to apply that as well as I was able, there was this lingering feeling that something somewhere was misconfigured, if not from a mail authentication/anti-spam standpoint, then from a network vulnerability one, and of course it needed to be continually maintained with patches, config updates, etc.

Eventually I gave up and moved to Fastmail. The few dollars per month are worth it.

Syncthing on the other hand I found pretty reasonable when I still had need for it, with my only gripe being that the only UI surfaced by several clients is a webpage which feels a bit janky.

These are server apps. This guy is talking about end user apps more.

Example: I prefer to run Google Earth desktop instead of Earth in a browser. It's faster, has more features and doesn't suck up as much memory.

I use Notepad++ instead of google docs for most note taking.

I use Kusto Explorer desktop instead of Azure Data Explorer.

Outlook desktop instead of OWA.

There are exceptions. The facebook messenger app I prefer in a browser, because, do I trust Facebook software to not scrape my screen and send it back to FB servers? I would much prefer it to live in my taskbar as a discrete app otherwise.

Many people run their own NAS which is the non-cloud alternative to something like Google Drive.

Running your own email server is a pain, having a client that pulls down your emails and stores them on a NAS so that your email is only briefly stored in the cloud is not a pain.

Never used WhatsApp or Telegram so no idea what the alternative for those is.

All these solutions are too complicated for an average person. Anything requiring typing command lines of any sort is too complicated for 99% of people.

And setting up your own email requires intricate knowledge of modern anti-spam protocols and reputation management.

Because to run it 24/7 you need maintenance. And proper HW to run it in home environment. And ISP... And...

This paper, "Local-First Software: You Own Your Data, in spite of the Cloud"[0] is a great read on how to evaluate software for local-first properties and provides interesting case studies and ideas on how to achieve it, for instance using CRDTs instead of centralized storages.

[0] https://martin.kleppmann.com/papers/local-first.pdf

Not sure if running an instance of web browser for each little desktop application is THE solution. I personally prefer Python ant TKinter. Yes, it looks ugly, but applications are small and use same runtime. For web developers I might even suggest trying GJS (GTK bindings with JS).

I prefer Blazor, which doesn't require embedding a browser. Running the server portion to serve my pages and json is just like running any other app, so I don't get the "People don't want to run their own server" meme. No one wants to run their own mail server, I get that.

I understand not everybody likes PHP, some prefer python, java, go. PHP is my go to language for tinkering on my personal projects. Also, I don't need to run an instance per each little desktop application. I can run one instance and "host" all them on the same instance.

PHP is still a great environment for toy projects. I write nearly everything web-based in PHP if I have no outside constraints because I can get started with it quickly every single time.

Before learning Python I used PHP for simple command line utilities, no complaints here.

Running local offline applications made a lot more sense before we had multiple devices (phones, tables) home computer, work computer.

If I want to use a bookmarking tool I want to use the same tool to store entries in during my work day. I'd also want to check something if I'm outside with a friend and want to show them something I bookmarked a week ago.

Different use cases for different people. When I do real web surfing, its usually on the computer. When I'm on my phone, its light surfing (finding a restaurant address, etc). Also, if you really want it sync between two computers, you can use Syncthing or Dropbox.

For those of us who don't like to be on our smart phones all the time, who keep work and personal strictly separate, who don't travel often (and when we do we leave our tech at home because a vacation is to get away), who prefer to keep their data local and outside the hands of 3rd parties, it has really sucked over the last 10 - 15 years to see the entire industry go all in on SaaS everything.

I use Linux and FOSS mostly. I always have anyway, but it's nice to be able to still be in control of things while the Apple and Microsoft worlds keep pushing Cloud and SaaS on their customers (last time I installed Windows on a dual boot I needed a Microsoft account just to log in to MY computer ... WTF?!?!?!). And for work I need an Apple ID to use my MacBook... at all. WHY?!

> And for work I need an Apple ID to use my MacBook... at all

Why? You can use the computer perfectly fine without an Apple ID.

Unfortunately (and this was my experience a couple of days ago, I could be wrong), when I wanted to download XCode to develop a native app, the site made me log in with an apple ID and accept terms and conditions. So, if writing software for Mac counts as using the Mac, you do need an Apple ID

To download Xcode you'll need an Apple ID. Developing for macOS / iOS without a free Apple ID doesn't make much sense though as you need it to sign the software and deploy it to test devices anyway.

That doesn't seem like an unreasonable requirement that you need an account with the platform vendor for that.

> Developing for macOS / iOS without a free Apple ID doesn't make much sense though as you need it to sign the software and deploy it to test devices anyway.

I'm a node / javascript developer. I make web applications. I remember having to install XCode for some dependencies. I don't make native Mac / iOS software, so it's a faulty assumption to assume that devs using Macs will be doing native dev. Even if I did, when working for a large-ish organization individual devs are not going to be the ones signing or publishing releases.

> I remember having to install XCode for some dependencies.

If you really don't want to create a free developer account to download the Xcode command line tools (That's probably what your dependency refers to, as the full Xcode is usually not necessary) you could just install or build the dependencies from another source?

You could also just download them via curl (There's direct links to the latest version out there) or `xcode-select --install` which both don't need an Apple ID.

Yeah while it is genuinely the substance of nightmares with Windows 10+ with its insistence upon using a remote account. But Mac OS will ask once and it's perfectly skippable.

Of course, if you wish to access iCloud or the App Store, it's required. But in fairness to Apple they don't push it in the same sneaky way as MS.

Have you ever inspected Mac traffic? As of Catalina (last I checked), even if you do not connect to iCloud, you have ~10 opaque connections/hour back to Apple - and about ~40 (slightly less opaque) connection if you are logged in to iCloud.

Most of the connections are from the nsurlsessiond demon, for which I have been unable to figure out the actual request url contents. Some of them have to do with update checks, some with notarization checks, who knows what else.

I wonder how it ranks against Windows.

But yeah, I accept that's still an issue. While I'll concede that I'd rather have the ability to choose zero, I think iCloud connections are expected if you're actually making use of its services.

Perhaps the best compromise is Apple hardware with Linux software. I've considered that if I ever lose patience with Mac OS.

You can do sync via e2e and protect it from service providers, or let users provide their own sync (which they can self host or use a paid service).

Seems to me that 1 user can store their data in 1 or N local or remote silos. classically each local app had its own data store, so 1:N. Web apps were the same except that each of the N providers could monetize your data and lock you out. Google and FB are using SSO to abstract the N behind one front door but really thats just so they can monetize the data instead of the N vendors.

Having 1:N but the user controlling where those N are stored, and that storage being portable between backends, seems like the right choice. Bonus points if apps can share data between themselves M:N style, although that is fearsomely hard to secure (exhibit A: windows registry).

A localized database stored in a non proprietary single file format that can be moved around and rsynced, dropboxed etc at will, plus a common, network independent access protocol so that open/read/write semantics work whether the thing is local, at a URL, etc just work would seem to be very desirable and possible with todays tech.

What's old is new again.

I liked the article and agree with the sentiment. I myself have trouble trusting my data with companies nowadays. The constant cyber attacks, misuse of private data, and the monetisation of user data deeply disturbs me and makes me think a ton before using a new service.

I'm currently building my own budgeting tool for myself and my partner. The pros: all the data is mine, never leaves my own network unless via my home VPN, and I build the features I want. The negatives: I have to build it myself, won't have as much fancy features and nice UI.

This certainly won't be for everyone, and is not viable for most, but there's a not a lot of viable alternatives at the moment.

You will find thousands of open source budgeting tools if you want a head start. It is a popular hobby category for devs.

Good point! The tricky thing is that even desktop apps today tend to have online backends to store data and analytics. So it would be a matter of building/searching for apps that are 100% local.

Thats why I decided to build my own. My bookmark manager is 100% local. It even caches pages I bookmark using chrome headless. The data is stored in a sqlite file which I can sync using Dropbox, Syncthing, etc if I use multiple computers.

Why not hosting it on some cheap hosting if you are already using PHP?

(I also build an app which is basically bookmark manager and it's based on PHP and SQLite.)

that would need the internet, kinda defeating the point no?

AFAIK, dropbox also needs the internet to work, doesn't it?

But you don’t need the internet to work at the same time as you use the local application with the data previously synced via Dropbox. Of course, in the case of a bookmark manager, the usefulness is limited when the internet isn’t working. :)

I only mentioned dropbox if I wanted to sync my database on multiple computers. I don't need to, so I don't need dropbox.

This is on the assumption I want to host it online. I don't want the task to maintain a web server and pay for its cost. I just want to be able to it use it locally. I want to be able to send it to a family/friend and they can run it themselves.

I've felt this way a few times. But whenever I think about building some of my personal apps as desktop only to reduce the hosting burden I remember that I want to access a lot of that data on mobile too and getting sqlite to sync around to my mobile device is a real pain (not to mention now having to build a mobile app to read it).

Web apps are just real convenient on the usage side even if I loathe building them most of the time.

Personally I don't see it as a general trend because its uneconomical and I think the notion of 'ownership of data' is confused.

One issue is that local and online isn't an either/or situation. People bring up keepass and self-hosting for example, but pretty much any online pw manager stores your data both locally and online, and you can export it. Going local only or self-managing my data has no benefit to me.

Second point is about control. We have encryption nowadays. I'm always confused when people hide their password vault or throw it on a next cloud home instance or something. The entire point of encryption is to enable the transport of secure data across insecure or adversarial channels. You can either own things and keep them secret, or encrypt them. Doing both kind of defeats the purpose of the latter.

Third thing is that empirically speaking, Google has a better track record of not losing my stuff than I do, so I think there's also a lot of illusions going on when people think that data is more safe if they have close on hand.

> The entire point of encryption is to enable the transport of secure data across insecure or adversarial channels. You can either own things and keep them secret, or encrypt them. Doing both kind of defeats the purpose of the latter.

An scenario where encrypting locally makes sense is protecting confidential data when an attacker has physical access. For example, encrypting your disk so that losing your laptop in the train does not expose all your local files.

Google has a worse track record of not losing my stuff than I do, but admittedly I don't use too many Google services.

Two examples:

I had a YouTube channel that was created before Google bought YouTube and switched to using/requiring Google Accounts. That channel/account became orphaned and I could no longer gain access to it. I contacted YouTube support and the only remedy they could offer me was to serve a DMCA notice to have the content removed.

I used Google Play and had bought music through the service. When they shut down the service I lost music that I had paid for. Meanwhile I still have a local mp3 library that has some content in it that has persisted on various hard drives since the 90s.

Desktop apps declined in popularity largely because of security concerns - you could download a virus that would steal data from all your other critical apps, like password managers or Bitcoin wallets. Browser apps are somewhat better isolated. Is there a way to prevent downloaded exe's from installing key loggers and root kits?

Is this still a problem in 2022? This is a solved problem in the linux world, with each distro having their package managers and vetted repositories. Of course, security issues still can arise, and sometimes you have to skip the official repositories to find what you need, but still much better than always downloading random binaries from the web.

Doesn't windows offer something akin to that?

Chocolatey.

But still you need download some exe's here and there.

Yes, windows has an app store now. Still, I wouldn't trust any app store, look how many Android or ios apps are compromised. And npm libraries have been compromised. App store "vetters" just can't find all exploits, it's mathematically impossible.

Has there been a trojan found in the Debian, Ubuntu or RedHat repositories? If so, I haven't heard about it, and neither did Google -- and I've been using these one way or another for 27 years now.

I suppose Arch/AUR might have had one. But there's a huge difference between a Windows store, which publishes author-provided executable files as-is, and Debian / Ubuntu / RedHat repositories which are all built from source.

I'm happy other people are doing this. I gradually started doing this a couple years ago when there was one specific feature of Lotus Manuscript I couldn't find in google docs. In addition to using local apps, I'm also using more apps in the terminal. I've even come to terms with Lynx.

That anyone would consider Google docs et al a suitable total replacement for a desktop word processing app does my head in. They have their uses, but even as someone that doesn't need to write up especially complex documents I can't imagine opting for a web-app to craft them in. Nothing to do with data ownership, as I keep the documents in a hosted managed service (usually Onedrive these days).

I can't imagine using a destkop app for this. Google docs is great! I can open the same doc on my desktop, my two laptops, my tablet, and my phone, and if I need to share it it's just a couple of clicks to share a live version. I can't imagine using a desktop app for this

From like 1993 To 2008 i used microsoft office. Bought new versions often, etc... When I started using google docs I haven't touched office since. Zero desire to go back.

There are plenty of other apps I'd consider for web only if good ones existed. For example I'm not a super fan of Google Slides, just because I find the feature set lacking. But seeing it and similar sites work it's clear to me someone could make a vector drawing app for the web that I'd be perfectly happy to give up Affinity Designer for.

Must've improved dramatically since I tried it a few weeks ago then!

You can make web apps that work offline today[1]. You can use IndexedDB to store data locally, in your browser[2].

[1]: https://web.dev/progressive-web-apps/

[2]: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...

my cross platform desktop plan has been a http-server-in-golang(or other languages) with a browser as the front end, for many browser is the only desktop application they need these days so no learning curve on the UI.

even Adobe is moving towards browser-based solution, unless you have a very special niche market that must be addressed by Qt/etc, I feel browser-UI is fine as a decent desktop UI app at least for my taste.

browser, like it or not, is the new cross-platform UI now.

I think one of the major times to use Desktop applications is when performance is critical.

Video games are the key example: all video games are competing against other games for what comes down to more complicated physics calculations (often light-based physics: "more realistic" shadows from Raytracing, or "cooler" shaders like Dragonball FighterZ / Guilty Gear (very "unrealistic", but clearly requires modern GPU-shaders to calculate).

Though Google tried to get video games "into the cloud", it still required data-centers full of high-end GPUs... and even then had latency issues.

Other performance critical applications include Stockfish Chess, LeelaZero Go (and KataGo), Blender 3d modeling, etc. etc. Having the user "spend the money on more compute" is economically a more feasible move, than centralizing compute costs to a server somewhere (especially costly GPU-hosting).

--------

Good news! There's plenty of performance-critical applications waiting to be explored.

But if you just need to deploy a simple application with low compute costs, centralizing the compute into a single server (or even mild decentralization through the Javascript interpreter) is good enough.

Have you... read the article? Like, at all?

They are specifically talking about the issue of data ownership, not performance. They are talking from a user perspective, not from a developer perspective. And they are specifically not talking about how centralizing is "good enough" - because it fails exactly at the data ownership point.

I have read it, and stand by what I say.

Desktop applications shine in this performance situation. Video games, 3d renderers, chess analysis, go analysis, deep learning, compiling, video editing.

-----------

If we're talking about "Data moving with you wherever you go", that was a Floppy Disk back in the day. If you want bookmarks to be portable in some kind of modern day setting, you'd store it on your phone and connect that up with your Desktop-app, or maybe keep it on a USB drive in your pocket.

3d renders might win in the cloud because the default could be a render farm.

they could also be running on the top GPUs where you might locally have some low-end notebook.

I haven't used it but as one example there is Clara.io and even if Clara.io isn't perfect it at least shows a path

Once more: There is a privacy concern. "Make thing go fast" wasn't on the list. Performance is not the concern. It's not "data moving with you", it's "data should not be available to third parties"

I have pretty much always hated web apps. I never used a webmail client as my primary mail interface, even. It was Eudora, or Outlook, or Mail.app.

Local, native apps are just better. They're faster, they can better respect platform interface and behavior conventions, and you can use them on an airplane.

After hunting for a desktop and mobile Gmail replacement for a while, I have settled on Bluemail for both. Along the way I tried Mail.app, Thunderbird, and various open source thingies. None were close enough to the quality level of Gmail.

This new situation is probably good enough to keep me off gmail for good.

Taking a gander through their privacy policy it doesn't seem like it's anymore private or secure.

What is the lightest cross platform toolkit to make apps in? Is is WxWidgets?

It depends on what you define by lightest, are you looking for smaller binaries, smaller memory footprint, smaller CPU usage. It also depends on the system you are shipping to and how. For instance a Qt application on Linux is going to be just a few kbs since you can just use the system libraries, but you will probably want to ship the lib with your application on Windows which means around 40MB or more. In this case if you are developing for Linux then Qt is lighter, but if you are developing for Windows the you should use Tauri (which will have a binary of around 2MB, but much more memory usage due to the webview).

FTLK.

sorry but the convenience is way too much for the vast majority of people to have to download desktop and access it. everybody is content being able to do it through the phone.

People would download the desktop app and content if it existed rather than using a webapp. Look at mobile, people want actual apps not webapps

This is a great incentive to build desktop apps for fun :)

Welcome back, I never left

What about paid web apps? E.g., Office 365?

What about it?

The future of apps. The article was saying running Electron Apps locally for privacy, I predict those that care about their privacy will go for paid for web apps that protect their privacy.

> Websites get hacked and people's data get stolen all the time. Also, do I really control and own the data I generate on these sites.

Unless legislation forces application providers to be accountable for privacy breaches, with tough penalties, I don’t see why privacy-sensitive users should forego applications that work with local files, moreso if those applications are free.

Unrelatedly, the author explicitly states that Electron apps aren’t real desktop apps. So he’s talking about native apps.

This pendulum will keep swinging. All of this has happened before and will happen again. The question that I got from the original article is not if there is pressure to move back to local applications (there is), but if we've hit the maxima for remote (webapp) applications. Eventually the remote-first momentum will wane and we will cycle back towards local applications, data locality, and local processing. We've been pushing so far with remote, web based applications for many years now. Email was first, but then came video and office applications.

Mainframes -> microcomputers -> appliances (phones, tablets) -> whatever's next... (home servers?)

At some point it will swing back. It won't look exactly the same, but the industry will swing back. It might not be for speed, but as you say, for privacy. It's easier to protect data that is physically close to you.

We will probably also swing back from microservices with HTTP APIs towards monolithic applications. But that's another thread!

Why use Office 365 when you can use Office locally (assuming you need/want to use Office)?

In payed Office you have desktop apps and 1TB of cloud. Web office is free btw.

Reply on news.ycombinator.com