4 ms·
> No, there are plenty of options when doing native development. I was mostly meaning if you have an existing Chrome App or wanted to rely on existing JavaScri
by seanwilson 9y ago
> No, there are plenty of options when doing native development.
I was mostly meaning if you have an existing Chrome App or wanted to rely on existing JavaScript libraries.
Electron gets a huge amount of hate on HN but I personally see the native route as very unappealing. With less developer resources (and perhaps a slightly worse UI; I think people really over exaggerate here), you get fairly simple cross platform support, an update system, access to a huge JavaScript ecosystem and your code can be shared between desktop, mobile, web and server-side.
As a developer, I don't see the appeal of e.g. QT, Java or OS specific implementations at all compared to the above. In my opinion, you're trading a small increase in UX and improved system resource usage (which most users won't notice) for a massive increase in developer resources. This is an order of magnitude worse if you're going to do a separate implementation for each platform as well as now you're going to need platform specific libraries, testing frameworks, development workflows etc. for each OS.
Unless you have lots of money, it's not practical to support multiple platforms with a 100% native experience using the minimal amount of CPU and memory possible. If you have an existing web app, moving to Electron isn't a big leap but that isn't the case if you want to have multiple native apps.
- icebraining 9y agoTechnically, 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...
- seanwilson 9y agoHow 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.
- pjmlp 9y agoMany companies outside IT see software development as a cost center, ideally outsourced somewhere, not as something where UI/UX matters.
- seanwilson 9y ago> 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.
- briandear 9y agoWhen 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.
- seanwilson 9y agoWhy 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.
- rvanmil 9y ago> 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).
- carussell 9y ago> 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.
- pjmlp 9y agoJavaScript is one of the official GNOME languages. https://wiki.gnome.org/Projects/Gjs https://wiki.gnome.org/Projects/Gjs https://2017.guadec.org/talks-and-events/index.html#abstract-26-modern_javascript_in_gnome 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.