Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Technically, you can have all those advantages with Qt/QML, since it uses JavaScript and runs on desktop, mobile and even web. That said, I never used it.

Another alternative would be React-Native, now that react-native-web exists...




> Technically, you can have all those advantages with Qt/QML

GTK+, too. There was a big uproar several years ago when GNOME tried to anoint JS as the "official" language for GNOME app development. They eventually backpedaled, and overall their story for JS today seems to be technically decent but thoroughly undocumented.

Keep in mind, this was all before GitHub announced Atom and (what was not-yet-then called) Electron. Imagine if the GNOME folks had used that head start to commit themselves to the original decision, instead of reversing. They might have managed to capture the mindshare that eventually poured in Electron, there'd be a straightforward migration path for DOM-based UIs to go "native", and GTK+ and GNOME apps might've been successful outside the increasingly niche space it occupies on the Linux desktop.


JavaScript is one of the official GNOME languages.

https://wiki.gnome.org/Projects/Gjs

https://2017.guadec.org/talks-and-events/index.html#abstract...

Electron apps across GNU/Linux users are the final nail of the desktop Linux aspirations.

When the world is a Web VM, the kernel and everything UNIX related is irrelevant.


How popular is it? If it's not popular, is there a reason?

I often see comments mentioning QT and Java as alternatives to Electron for cross platform apps but my impression is an order of magnitude more developers/companies side with and see the advantages of Electron instead.


Many companies outside IT see software development as a cost center, ideally outsourced somewhere, not as something where UI/UX matters.


> Many companies outside IT see software development as a cost center, ideally outsourced somewhere, not as something where UI/UX matters.

I work in IT and I see it as a small increase in UX for an order of magnitude increase in cost. I don't see how e.g. making Spotify or Slack into native apps would dramatically improve their UX.

In contrast, I think many coders are overly sensitive to CPU and memory usage to such an extent that they lose sight of business sense.


> I don't see how e.g. making Spotify or Slack into native apps would dramatically improve their UX.

Well then that is something you might want to do something about if you're an app developer. There's no reason arguing if you are unable to discern the big difference between the UX of a (both properly built) native app and an Electron app. I think this might be one of the reasons Electron is actually successful; a lot of developers do not have a good sense for UX so they think what they've built is a proper alternative to a native app. Same goes for those who think PWA's are going to be great and up to par with native apps (hint: nope, not even close).


> Well then that is something you might want to do something about if you're an app developer. There's no reason arguing if you are unable to discern the big difference between the UX of a (both properly built) native app and an Electron app.

I'm able to tell the difference thanks. I'm saying that with native apps the UX can be better but for a large cost and a lot of the time that cost is not worth it. I'd also argue that most coders fixate on bad examples of non-native apps because when non-native apps are done well they don't notice. For example, Visual Studio Code is based on Electron and there's always lots of comments from people being surprised how performant it is. People also use lots of web apps day-to-day that they're happy with.


> I'm able to tell the difference thanks.

I must've interpreted that the wrong way then. We'll have to agree to disagree then because I do think there is a big difference in UX.

I really think the limits of providing a nice UX with web tech is the elephant in the room here and everyone is ignoring it because it is simply cheaper and easier to work with and/or because of idealistic reasons. Which I think is a shame because it's responsible for a trend where we're moving towards good-enough software on all platforms, instead of nice software for specific platforms.

Turning Slack and Spotify into native apps can upgrade them from just being functional, to actually being a pleasure to use, something of which I'm convinced is not possible with web tech no matter how hard you try. There is a huge amount of platform specific UX details (much appreciated by Apple users especially) which you will not be able to emulate.


When Slack on iOS hangs when I am trying to switch channels — or I get irregularly delayed notifications.. or glitching when trying to copy paste.

Slack for iOS is pretty terrible in terms of stability and quality.

Writing an actual native app in Swift isn’t that hard and they’re Slack — one would think they could afford to hire the proper developers.

It’s hoghly irritating when I’m a paying customer of a fairly big tech company and they think saving money on pseudo-native for iOS is ok. They think it’s ok to provide a shitty “near native” experience in the name of crosss platform. iOS and Android are different systems. They have different devices; it’s ridiculous to ship the same app.


Why are you making this about native vs non-native? You can write bad native apps with bad UIs that hog memory and CPU. If a company is happy shipping a bad non-native app they're not likely to do a good job of a native app either.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: