Creating a good cross-platform
GUI framework is probably harder
than creating a good cross-platform
language.
Way way way way way harder, I'd think. It's basically never been done in the modern era. All the successful ones from the past look (and work) like garbage on a modern desktop computer (I use gnucash for my dad's business, ha ha).
SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tell you that the current "native" experience sucks green potatoes. There are like 9 or 12 different UI technologies I must interact with each month. All with different text sizes and massively inconsistent UI paradigms.
So I think there is an opportunity here.
But, I bet SwiftUI → Web will come first. And if that happens, SwiftUI on Windows, and desktop Linux, will be a no-brainer and will happen.
And if it doesn't happen, then probably SwiftUI won't matter outside of the Apple ecosystem, and that will mean Swift won't matter much in the end, either. (EDIT: I don't mean Apple need do this and I don't expect they will. But SwiftUI is just an API; anybody could port it to whatever environment they want, and there are already some nascent third-party efforts to implement it for HTML/web.)
Full disclosure disclaimer: former NewtonScript programmer
I think the opportunity is particularly on how SwiftUI has been implemented in iOS, iPadOS and macOS, by relying on the native UI of each platform and providing a common abstraction for developers.
Instead of providing the same UI that works badly on every device, SwiftUI interprets each concept differently according to the platform.
For example, a Toggle in an iOS and iPadOS app looks like a on/off switch, while on macOS it's rendered as a checkbox. A Picker has is scrolling wheel on iOS but it's shown as radio boxes or a drop-down menu on macOS.
Navigation is also the same. On iOS, a NavigationView offers the drill-down navigation common to iPhone apps, while on macOS it creates a split master-detail interface.
Each implementation does so by using the native UI framework of each platform under the hood, UIKit on iOS, and AppKit on macOS. I don't know how UI development works on Windows, but my speculation is that a SwiftUI implementation would work the same way.
I can’t comment on SwiftUI in particular, but I’ve found that a lot of things like this tend to break down in most other cross platform GUI frameworks, falling into a kind of uncanny valley, where the experience ends up being either:
1. Native feeling, but sufficiently inflexible that only very simple, common UI patterns can be implemented
2. An “uncanny valley” native ui, where things are almost native but often feel wrong in subtle ways
I think that’s why Electron has succeeded where so many cross platform UI frameworks failed: it’s so obviously not native that it doesn’t fall into that “uncanny valley” anymore
The way they have implemented it for even their own "cross-platform" needs (where the "platforms" are really basically different versions of the same OS) works very well — the sickening, jaw-droppingly awful apps from Twitter, JIRA, etc that use the "Catalyst" system of porting iPad apps to Mac shows why the approach is really necessary.
(Those apps bring iPad metaphors to the Mac, so what should be a single interaction, picking something from a menu, is a jarring series of taps, swipes, and animated fuckery.)
If that "render the concept using the OS's native widgets" approach was necessary even for cross iOS-macOS apps, it will be even more necessary across Mac and Windows, where a lot of the UI conventions are wildly different, and sometimes literally the opposite (e.g. the standard placement of buttons).
And it's obviously the only way it could work for web apps.
Sun tried with Swing.. and they were not a second tier company at the time. Also previous versions of OSX (before the rename to macOS) included a special theme of Swing to make apps to look more native in OSX (Jobs was happy to announce that OSX supported Java... when Java was sexy).
Then when RIA was a buzzword Sun/Oracle tried to modernise Swing without success. Today the only big Swing apps that I know are Netbeans and maybe IntelliJ (but I think that IntelliJ has tons of customisations on top of it).
So is even hard for a big company too. I guess the problem is that the framework will be always behind the OS, and you need to recreate all the styles or to create a thin layer with the common denominator between platforms.
Is interesting that different approaches to cross-platform UI (draw all vs thin layer) goes back to Smalltalk. AFAIK the idea of Swing drawing all the UI came from VisualWorks, while the thin layer of SWT came from IBM VisualAge
>Sun tried with Swing.. and they were not a second tier company at the time.
Swing was ill thought from the beginning. Over-engineered, too complex, slow (as if there were 2-3 layers between the code and the drawing engine), and looking bad in every platform...
>So is even hard for a big company too. I guess the problem is that the framework will be always behind the OS, and you need to recreate all the styles or to create a thin layer with the common denominator between platforms.
I'm not so sure that's a problem. You can always look different than the OS, and do a good job at it. Millions use the Adobe Creative Suite, Cubase, Pro Tools, StudioPro, etc, and their non-native UI is the last thing they complain about...
Heck, even Electron apps do that. Why wouldn't users like apps that look different from the OS, the way Electron apps do, but with far less memory usage, much speedier drawing, and better integration options with native widgets when needed?
There are tons of existing cross-platform UI frameworks (Qt, wx, libui, JavaFX, TornadoFX, ...). The comment above says "Everybody would jump to Swift [for new projects] if it meant a cross-platform GUI framework."
And yet people are still wondering why Electron ends up being the technology of choice for so many desktop apps.
JavaScript is a language that's neither abstracted from the basic programming concepts nor its syntax is alien. Most of the people who picked it up can learn many other mainstream programming languages in a week, if not a weekend. Add 1-2 more weeks and they're writing GUI code.
Yet, they don't.
JavaScript is popular for pragmatic reasons (a.k.a. "it delivers results"), so is PHP. They aren't the best languages, but developers who choose them aren't simpletons who can't code in other languages.
They are both deeply, deeply flawed (though I have learned to love JS's good parts, while I still hate PHP).
I have programmed in many languages - Java, Python, Scheme, and Bash are all ones I've worked in professionally, and I've spent plenty of time in Emacs Lisp. This doesn't touch on the ones I've tinkered with for fun.
JS and PHP are not the best languages, but they work, they're everywhere, and they're usually what your client already has in place.
Changing languages rarely delivers any actual business or end user value.
So, I work in what the client has.
JS will long outlast PHP, because it's such a massively deployed language and browsers can effectively never remove support for it.
PHP may slowly die out, since it's strictly on the backend, where you can choose your language.
I’d say electron became popular thanks to HTML, not JavaScript. IMO HTML is by far the “easiest” to use GUI framework because it is so unconstrained. It will end up a mess, but eventually you can get the result you want. This is not the case with native frameworks which come with a larger sets of rules on how they can be used.
I did UI development for quite a while too, and in my experience having very specific layouts (and look) in HTML is easier than in frameworks I used (Gtk, Qt, UIKit...).
Main difference is that HTML has affordances to size elements "upwards" whereas in other toolkits you need to do this manually (e.g.: estimating text size is a thing, in html you don't need to care about this)
Now, this also encourages original layouts which are untrue to platforms which is not a good thing imo.
I very much doubt that is a major reason. Language itself is rarely the issue, unless you're reusing code from other parts of the project (which many projects are, e.g. VS Code with Monaco).
I have spent far too much time on HN recently in related discussions.
Building custom UIs is also very easy with the flexibility that HTML provides (https://news.ycombinator.com/item?id=23164595), even though it can be done with other technologies (and there are some examples of that).
> Qt is pretty good but QtQuick can be fairly barren in some areas i.e. if you want a embedded spreadsheet you're out of luck unless you make your own.
Possibly, but that's if you include the part about making it look/feel native. If you just provide the tools the are just focused on the language and framework and let the people who care about making it look native on whichever platform it's running focus on that then I think it's doable.
Unlike things like react native you wouldn't be actually using the native components necessarily unless you can implement the UI frameworks components in terms of them. Otherwise they would need to be written from scratch.
I’ve thought enough about this problem that I don’t think it’s possible to recreate a “native” experience with a cross-platform app. You end up compromising on the nativeness every time. It makes more sense to me to use native GUI frameworks and program your functional logic in something like Rust.
A native look and feel is definitely an implicit assumption I held. You’re right that eliminating this requirement changes the level of difficulty significantly.
Personally I wouldn't mind creating a new UI for every platform I need to support as long as I could use the same language with the same build tools and reusing components between them.
SwiftUI is an interesting re-think, though, and as a Windows 10 user, I can tell you that the current "native" experience sucks green potatoes. There are like 9 or 12 different UI technologies I must interact with each month. All with different text sizes and massively inconsistent UI paradigms.
So I think there is an opportunity here.
But, I bet SwiftUI → Web will come first. And if that happens, SwiftUI on Windows, and desktop Linux, will be a no-brainer and will happen.
And if it doesn't happen, then probably SwiftUI won't matter outside of the Apple ecosystem, and that will mean Swift won't matter much in the end, either. (EDIT: I don't mean Apple need do this and I don't expect they will. But SwiftUI is just an API; anybody could port it to whatever environment they want, and there are already some nascent third-party efforts to implement it for HTML/web.)
Full disclosure disclaimer: former NewtonScript programmer