Hacker News Reader

Comment by heavyset_go | Hacker News Reader

I'd bet that the reason they're using React is because it's cheaper and easier to find front-end developers for the task.

View on HN

I’ve been hearing this on HN and similar forums for what feels like years now: “Electron/web-based GUIs are only popular because it’s easy to find devs in those ecosystems”

Have we considered asking why it’s so much easier to find React devs? Why such a huge, huge majority of UI development today takes place on the web?

I’m a front end web developer. I’m very biased.

But I’m a little tired of the narrative that “the right way to make a UI is to build it natively, but everyone wants to take the easy way out.”

Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience. And if you spend some time exploring them, I think that becomes very obvious very quickly.

> Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience.

That depends on what one values, in my opinion. Whenever I start poking around with front end web stuff it makes me want to tear my hair out. Not because it isn't technically capable, but it all feels so slapdash, duct-taped, and chaotic compared to what I'm used to writing AppKit/UIKit, even if some aspects of the experience with front end web tech are nicer. Things are solidifying around React which helps, but for me at least, it's still a hard sell to trade away the positive aspects of native development just to get the positive aspects of front end web dev.

I’m guessing you haven’t tried building something serious with SwiftUI then. Because for me React is a million times more polished than SwiftUI.

I was a native dev before I got into web stuff. The Apple APIs for native GUIs are so good, but they are extremely verbose, and with swift now they are closed source. It’s just not as easy (or fun tbh) to build things with

SwiftUI is promising, but still green (for now). So no, I was talking about just plain old AppKit and UIKit. No fancy declarative syntax, but plenty capable.

Closed source isn’t great, but I’ll take that tradeoff for how much less frequently I need to reach for a third party library or write widgets from scratch.

Seriously, have you TRIED non-web, cross platform, UI dev? It's a nightmare. At least all the things I've tried so far are. I'm trying KDE's Qt IDE out and so far it seems much better at getting a working example built, though it looks like it's missing a visual interface editor. Qt-the-company had a good visual interface editor I used in ~2018 I think with PyQt but I can't find a way to launch it anymore. It's a mess.

I have, and I found QtQuick and QML to be a better experience for reactive UI programming.

I have, since the days of 16 bit home computers where when I wanted ultimate performance it had to code the core of the application in straight Assembly.

The only platform that offers native RAD like tooling for Web Development is OutSystems, most don't come even close, probably WebFlow.

Naturally since most devs don't like to pay for their tools, their target market is enterprise shops, so only Fortune 500 devs get nice tooling.

Some of us don't think much of Qt either.

The GUI designer is called Qt designer - it's called designer in Ubuntu/Debian. Unfortunately Debian has really made a mess of their packaging of Qt/PyQt. They've split up everything into tiny packages and their naming scheme seems crazy - I can never work out which package to install to get what I want. In this case it's qttools5-dev-tools.

Qt Designer[0] (for widget-based interfaces) is still a thing, and they have added Qt Quick[1] and Qt Quick Controls (for QML-based interfaces).

Recently they’ve been integrated into the IDE but with a right click on a file (within the IDE file browser or project browser panes) you can open a .ui file in the external Designer.

[0]: https://doc.qt.io/qt-5/qtdesigner-manual.html [1]: https://doc.qt.io/qt-5/qtquick-index.html

I am insanely productive writing desktop applications with wxPython+wxWize. No GUI designer, no XML, just straight up Python code that's easy to follow and easy to refactor. I can whip up a prototype as fast as I ever could in Delphi, and it transitions cleanly into the finished app.

I guess if cross-platform needs to include mobile, then that's not good enough. But for what it does, I'm very happy with it.

Full disclosure: wxWize is my own creation.

> Why such a huge, huge majority of UI development today takes place on the web?

Business models centered around the web, like the cloud and SaaS, and because it's the lowest common denominator when it comes to cross platform development.

> Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience. And if you spend some time exploring them, I think that becomes very obvious very quickly.

QML works very nicely, it has a pleasant developer experience, it's reactive and declarative, and it even gives you JavaScript. It's similar to React in those regards, and I prefer it.

I believe the reason why so much UI development takes place on the Web is because there are a lot more people making websites and web applications than there are making desktop applications. For example, think of all of the businesses and institutions, big and small, that need a web presence. Because the Web is such an essential part of modern commerce, it makes sense that there would be much more work available for web UI development than for desktop UI development. In addition, the Web is quite possibly one of the easiest platforms to deploy an application. Want to reach much of the world? Spin up a cloud VM, get yourself a static IP and a domain name, deploy your web server, and voila!

Another thing to consider is that native app development is fragmented. For one, there are a variety of platforms. There are four major commercial platforms for consumers: Windows, macOS, Android, and iOS. In addition, each platform has multiple ways of doing native development. I don't know much about the Android ecosystem, but in Windows you have a choice between (off the top of my head) Win32, MFC, WPF, and WinRT (and I may have forgotten a few), on the Mac you have a choice between AppKit and SwiftUI, and on iOS there's UIKit vs SwiftUI. Thus, it's not enough just to hire a developer based on platform; it's important to hire based on experience with the API your application uses.

In my opinion, my negative opinion of Electron on the desktop has nothing to do with laziness. There has always been a tradeoff between developer convenience and optimal performance in software engineering; for example, this is why I write machine learning code in Python instead of fine-tuned assembly. If that's lazy, I'm guilty as charged. Rather, my negative opinion is based on these issues:

1. A disregard for conforming to the platform's UI/UX guidelines, which are in place to ensure consistency in behavior across applications. By Webifying the desktop we get rid of one of the strongest advantages of desktop operating systems, which is consistency across applications, and we turn the desktop into the inconsistent hodgepodge of user interfaces that make up the Web.

2. Accessibility problems that are caused by ignoring the native platform's accessibility APIs.

3. Performance issues caused by running instances of entire web browsers to duplicate UI rendering features that already come with the UI toolkit of the system.

4. Applications written with the Web in mind for the desktop often inappropriately use design elements that may make sense in a web browser but do not make sense on a desktop (this is related to #1).

Some would say that #1 has long been the reality for Windows and Linux long before Electron existed due to competing toolkits (especially in the Linux desktop world) and app-centric viewpoints from application vendors where the look-and-feel of an app trumps platform consistency concerns for branding reasons. I agree. However, some say we should shrug, give up the dream of consistency, and accept having inconsistent applications. I believe there should be more consistency between applications (in fact, I disagree with the notion of app-centric desktop computing in general and strongly favor a component-style model, but that's another debate for another time), and I believe one of the strongest selling points of the Mac is the high degree of consistency that existed among the platform's applications for decades. The move toward Webified desktop apps undermine this consistency, however, and that I believe undermines one of the big things that make the Mac special.

>Thus, it's not enough just to hire a developer based on platform; it's important to hire based on experience with the API your application uses.

I don't think so. I'd hire an iOS developer for a macOS job. There is enough commonality for it to be an easy transition. It's the same on Windows, the Winforms app I work on has a ton of win32 calls and a smattering of XAML/WPF.

> I'd hire an iOS developer for a macOS job. There is enough commonality for it to be an easy transition.

No. No there isn't. As evidenced by the crappy Catalyst and other mobile ports that break all possible platform conventions on MacOS.

Yes, it might be easier, but not easy.

No. That's wrong. The fact that there are poor quality catalyst apps is neither here nor there. The tooling, languages and large parts of the frameworks are common or so similar that it doesn't matter. You can go straight from writing an iOS app to writing a Mac app without much friction at all. I know because I did it.

> Perhaps the explanation is that native GUI frameworks simply haven’t kept up in terms of developer experience.

Native UI toolkits are light years ahead of anything the web can offer in any forseeable future.

Well, WebGL is somewhat of an exception, but then you're literaly bringing native technologies with limitations into the web.

And one major exception: deployability. Nothing can beat the web in deployment.

Reply on news.ycombinator.com