Sure you could use something like SwiftUI and create some simple DSL to dynamically build a native UI. But at that point you’re basically building a slightly crappier, less flexible version of HTML. So might as well use HTML+CSS and take advantage of the decades of learnings it represents.
I’ve personally used a similar approach to power a banks fraud warning UI. Made it possible for us to quickly iterate and change our UI as various strategies used by fraudsters evolved. Meant we could go from see a new issue, to updating our ML models and deploying new UI in under a week, which is faster than the app review process.
[1] https://news.ycombinator.com/item?id=30384494
Edit: mention iOS Settings.
Why don’t those both use the same UI toolkit, like the convergent GNU/Linux DEs? (macOS seems to be getting more touch-optimized with each update — eg. making sliders giant and iOS-style; why hasn’t Apple merged Cocoa and Cocoa Touch into one yet?)
we spent decades wedging compatibility shims into gaping functionality holes, while heroic visionaries of the web as a platform toiled and bargained to bring us the tools we needed for modularity, performance, and a modicum of basic platform services.
all while making sure <TD STYLE=FLOAT:RIGHT> continued to work.
There’s a reason you get system colours and fonts in CSS: they’ve been round since the ’90s. You certainly wouldn’t get such useful and flexible stuff being added now.
There are very strong parallels in a lot of the progress that’s been happening in the past few years with what happened twenty years before. Probably the most obvious example is dark mode: computers had that twenty years before, then it got lost somewhere along the way, then it gets reinvented in an only slightly different form (both more and less useful: it’s far more restricted, to just one alternative theme rather than many, but for the web you can actually design for it in CSS alone this time).
Cycles.
Of course that's all kind of moot because the important point is that there's a large different between a native app that uses a webview (or the windows/linux equivalent) to display some content, and a cut down browser view trying to act like a native application. Admittedly a number of the bugs in electron apps are a byproduct of their use of chromium which is very much a Mac-second engine and the actual API requires host apps to do much more work for system integration, which is a valid choice: it gives the host app much more flexibility in handling things. The down side is there are some things that apps shouldn't be trying to reimplement themselves.
Those properties open up the possibility of abstracting things and making very powerful libraries over it. There is nothing else as powerful out there.
Yet, everybody stops at plain react. So whatever is the reason for the success, it's not that one I pointed.
Let me introduce you to https://github.com/ocornut/imgui
React brings to the table is the general concept of immediate mode UI programming. So does ImGUI. Reaching for React doesn't mean it's the only thing the programmers knew, it means it's a general pattern that arises in UI programming.
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.
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 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
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.
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 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.
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.
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.
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.
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.
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.
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.
The results aren't good though, the whole thing is painfully slow.
I’ve only recently started working with react, but so far it’s been the best experience I’ve had working with GUI in decades of working with different things.
I’ve always been what you’d call a full stack developer, but I’ve always very much not been the front end design developer, and react with bootstrap and font awesome is the first time I’ve been able to effortlessly create GUI stuff that doesn’t look like it should’ve been made by a front end design type.
So to me this is not at all surprising or crazy. It’s simply what happens when you have a really effective tool that a lot of people know how to use.