Creating a good cross-platform GUI framework is probably harder than creating a good cross-platform language.
Creating a good cross-platform
GUI framework is probably harder
than creating a good cross-platform
language.
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
Also never been really tried, except by second tier companies with small recourses like Trolltech/QT, or even smaller open source attempts like Wx.
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
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?
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.
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.
It looks like the bear is in keeping up with all the platform updates all the time though.
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.
probably because of the large number of JS only developers.
Guess what, what in most of them I never had any issues to center elements, or create fake UI elements out of list items.
Also layout managers were already a thing back in 2000.
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.
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.
I work primarily in JS and PHP.
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.
JS is eternal.
How are you using it?
I have spent far too much time on HN recently in related discussions.
Having access to libraries like React and its huge ecosystem is a big plus for productivity (example vs. Qt at https://news.ycombinator.com/item?id=23154315).
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.
Hey, have you checked out https://github.com/ec1oud/spreadsheet.qml?
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.