Hacker News new | ask | show | jobs
by llbbdd 108 days ago
What alternative did you have in mind when you said there are even easier ways of getting high-performance cross-platform software built?
3 comments

The power move would have been Cosmopolitan, or a package similar to it.

https://github.com/jart/cosmopolitan

Cosmopolitan can be used to bundle up any gui package, and your code, and a team of professional software devs should be able to cope with it just fine. You end up with a native executable with a slightly bigger package to ship, since it's carrying executables for various platforms, but you'd effectively have the same code and behavior everywhere. A few extra megabytes, instead of whatever the hell electron is doing. They could also use Java, or even one of the electron type clones that attempt to be better, like Tauri.

The point isn't that electron is so awful. It's that the company with the purportedly best coding AI and one of the best overall AI models in the world chose to do the absolute tawdriest, cheapest, even laziest thing without any consideration of what the right thing to do might be, or what thing they could do that demonstrated their excellence and mastery of craft, or at a bare minimum, the advanced capabilities of the AI.

Cursor used claude to build a browser from scratch; it's not like their AI couldn't do it.

I don’t code, so I’m well out of my league but this point of “premier coding AI company should showcase its capabilities by using their own model to build superior software” rings true to me, right? Especially as we start to discuss AI as more dangerous than nuclear weapons yet it can’t even do that?

Who’s got the rebuttal to this?

It might be a strange thing to say, but Java is still viable alternative route. You can build a nice and fast cross-platform desktop application on it today. The language was designed for this kind of things. The entry barrier is quite high though.
I might hate Qt apps more than I hate Electron so I'm curious about the answer too.
Whats is wrong with Qt apps? Take too little RAM?
As far as I can tell after a quick Google, you can't share your Qt UI with the browser version of your app. Considering that "lite" browser-based versions of apps are a very common funnel to a more featureful desktop version, it makes sense to just use the UI tools that already work and provide a common experience everywhere.

The same search incidentally turned up that Qt requires a paid license for commercial projects, which is surprising to me and obviously makes it an even less attractive choice than Electron. Being less useful and costing more isn't a great combo.

> you can't share your Qt UI with the browser version of your app

You can with WASM (but you shouldn't).

> Qt requires a paid license for commercial projects

It doesn't, it requires paid license if you don't want to abide with (L)GPL license, which should be fair deal, right? You want to get paid for your closed-source product, so you should not have any reservations about paying for their product that enables you to create your product, right? Or is it "money for me, but not for thee"?

> Being less useful and costing more isn't a great combo.

Very nice, but now explain why you are talking about using Qt to create apps, whereas grandparent talks about experience with apps created with Qt.

I looked up the WASM Qt target and it renders to a canvas, which hampers accessibility. The docs even call out that this approach barely works for screen readers [0], and that it provides partial support by creating hidden DOM elements. This creates a branch of differing behavior between your desktop and browser app that doesn't have to exist at all with Electron.

It should go without saying that the requirements of the LGPL license are less attractive than the MIT one Electron has, fairness doesn't really come into it. Beyond the licensing hurdles that Qt devotes multiple pages of its website to explaining, they also gate commercial features such as "3D and graphs capabilities" [1] behind the paid license price, which are more use cases that are thoroughly covered by more permissively licensed web projects that already work everywhere.

On your last point I'm completely lost; it's late here so it might be me but I'm not sure what distinction you're making. I guess I interpreted dmix' comment generally to be about the process of producing software with either approach given that my comment above was asking for details on alternatives from the perspective of a developer and not a user. I don't have any personal beef with using apps that are written with Qt.

[0] https://doc.qt.io/qt-6/wasm.html#accessibility-and-screen-re...

[1] https://www.qt.io/development/qt-framework/commercial-qt

> I don't have any personal beef with using apps that are written with Qt.

But the author of a comment I originally replied to has:

> I might hate Qt apps more than I hate Electron

therefore it is your insertion about dev experience and license costs of Qt vs MIT-licensed web frameworks that makes me lost.

I do frontend work so struggle to get over how bad most Qt GUIs are. They are far out of date compared to Gnome or MacOS in a lot of the small widget details and menus.

Plus I use Mac these days and Qt apps just never looked right on that platform.

At least web apps looks like web apps.

As a recent toe-dipper into linux (now running Arch on a powerful minipc and KDE plasma) I'm shocked at how little progress has been made on the native UI side.
Well, it's not that surprising, considering that as soon as something radically new appears, there is always some mistreatment from all sides: platform owners, app developers and users.

Windows' Metro/Modern UI was pretty good from different perspectives, but didn't have enough effort put into it to make it a universal thing fit for multiple purposes (half of the Windows settings was still in Control Panel for quite some time), wasn't familiar for users (so they hated it) and wasn't familiar for developers (so they created hideous apps).

In the opposing Linux camp, GNOME made Gtk 4 with Libadwaita UI library with "everything is a phone app" mindset that not every app can adopt. For example, there's no application menu (a line with File, View, Edit, etc.) component shipped by default, you should make it yourself or get it somewhere. So now GIMP is developed using Gtk 3 (not modern 4) because it has all the components GIMP needs. Trying to get GNOME developers to implement some stuff outside of their vision is a futile effort.