The amazing thing is that 30 years ago there were cross platform toolkits like Neuron Data and the toolkit under OpenOffice(called StarOffice originally), and yet today the options are still fragmented and imperfect.
We have far better compilers and even languages for cross-platform work, so it should be easier by now.
Building a cross-platform GUI toolkit takes an incredible amount of work & time, especially at the systems level.[0]
A robust cross-platform ecosystem for the underlying programming language is a necessary but insufficient piece of the puzzle.
Given the proliferation of HTML and WebView/web-tech wrappers (Electron, Tauri, React Native etc.) there are now enough "good enough" solutions that most organizations that would underwrite the in-house R&D of a new Neuron Data or Delphi or Flash simply don't feel the need.
When it does happen — say Google Flutter — it's almost statistically impossible to keep the hydra of VPs and biz folks aligned over the decades of ongoing investment it takes to mature & form community around this kind of technology — see the recent Flutter team layoffs at Google.
[0] speaking from my experience building a cross-platform GUI solution in Rust for several years now; see pax.dev
Exactly. Many programmers don’t want to worry about edge cases, and cross platform GUI frameworks are essentially coding an “oops all edge cases” project.
Isn't the whole "Flutter team layoffs" narrative somewhat debunked at this point? My understanding is that some positions were cut and some were moved, but no more than any other engineering area at Google.
You could take a program that says you need a button in the window and it would make one for you on Qt, GTK or whatever else was supported, on any platform that you were compiling for.
We might as well have gone a step further: your programming language --> UI toolkit bindings for your language --> programming language independent GUI toolkit --> widgetsets for GTK, Qt, WPF, Win32 or whatever else --> executable for that specific platform
With that many layers of abstraction it's likely that we'd get the lowest common denominators for all functionality across platforms, but at least it would run better than web technology does, with the accessibility and platform look & feel you'd expect.
Of course, for whatever reason, seems like nobody wanted to undertake the borderline crazy effort of creating something like that, something foundational for others to build upon, so that's why we get super fragmented frameworks that are bound to specific languages nowadays and each of them have to reinvent a wheel a lot.
Now there is a generation of software developers who grew up with web technology, and they aren’t old enough to recall the days of native apps - they don’t know any way other than HTML.
Lol. One of good cross platform example is Calibre [1], built with Python and Qt. And it’s the only one I carried with me from Windows XP/10 to macOS, through Linux. Another is Sublime Text.
I’m not sure whether those toolkits abstracted over native GUI interfaces or whether they attempted to recreate a native look and feel or whether they attempted to provide their own look and feel across platforms, but in any case the problem isn’t languages and compilers, it’s that the expectations for a GUI toolkit are dramatically greater now than then. Here are a few things that are (I think) expected from GUI toolkits today, but not 30 years ago:
* Hardware acceleration (in particular abstracting over metal, opengl, direct x, vulkan, etc)
And if you want to emulate a native experience, getting keyboard shortcuts, focus behavior, and a billion other details correct is nearly impossible.
And by the way, today we have web engines that take care of most of these things for free and a huge pool of people who know how to build for them, so it’s often easier to leverage that capability than to essentially reinvent them.
And if people can contain their knee-jerk anti-electron reaction for a moment, I think that’s a pretty reasonable approach. I would really like to see something like an unlocked ChromeOS where the browser is the native interface, but unlike electron, we don’t ship a web browser with each app. Especially as webasm takes form, I could see this as a more compelling solution for cross-platform graphics with multi-language support than cross-language bindings or by trying to maintain a toolkit per language while trying to maintain some illusion of a consistent experience.
In some ways, expectations for UI toolkits have dropped too, though. Practically no UI toolkits created in the past 5-10 years come with a row recycling tableview/datagrid widget (table with column headers, sort by column, etc) for example, which used to be table stakes (which is why they’re present in Win32, MFC, AppKit, GTK, and Qt among others of the old guard). New toolkits that lacked a tableview would not have been taken seriously back then.
This has been a major blocker for my adoption of newer toolkits. I understand that it’s a result of mobile UI trends dominating the space, but that’s not helpful when I’m looking to build useful desktop apps, for which these widgets are crucial. Relying on third party libraries to fill these gaps (if they even exist) isn’t appealing either, adding yet another dependency to the pile and making a major part of my app subject to likely eventual abandonment by the library’s dev.
Yep that’s another one that’s frequently missing. Basically any scrollable displays of data that aren’t a simple single column list or a grid are entirely absent in newer UI toolkits.
The compilers of 30 years ago had incompatible behaviors between OSes, for instance C or C++ had a great deal of variation. And 30 years ago you had pre-OSX MacOS as well.
Now you can just choose 1 compiler such as GCC and it works the same on all platforms; even cross-compiling to a different CPU architecture works well and is far easier to setup (before it was a black art).
In what way does GCC play any role in cross platform GUIs whatsoever? It’s a very small niche on Windows, macOS, iOS and Android. Visual C++, respectively LLVM/clang are much more dominant on those, and even then they are barely the right tools for GUI (maybe except Windows, but even then competing with .NET).
"Ubiquitous Applications: Embedded Systems to Mainframe"
"To support a variety of platforms, Smalltalk uses a virtual machine approach to portability that allows applications to be easily migrated between platforms with little or no change to the code."
"… Smalltalk developers can work and deploy on Linux, Windows, AIX®, Sun Solaris, HP-UX, and OS/2®. You can also create applications to be deployed on the mainframe with VisualAge Smalltalk Server for OS/390 and z/OS."
Pre-Java there was a need to have UI applications that ran on Windows NT as well as Solaris and HP-UX. I worked with a commercial software package called Visix Galaxy. We developed in C++. It included libraries for each platform. It also had an interface builder very similar to those today (like the one in XCode). These were polished tools that made it easy to build beautiful GUIs.
Java was introduced slightly before the cutoff -- 23 May 1995, so almost exactly 29 years ago. The earliest ancestor of its Swing desktop GUI library, called Internet Foundation Classes, was released 16 December 1996.
I don't understand how Java is relevant here? Perhaps I'm missing your point.
My point was that making GUIs today should not be any easier than 30 years ago because we have a lot more complexity across different OSs, phones, and the web.
Update: I think I understand your comment. I think you latched on the very last past of my comment about "write-once deploy anywhere". I meant that as in people want to create their GUIs with one language and one toolkit and have them deployable across different stacks without having a custom version for each and every final target platform.
Yes, technically Java did deliver on that as a programming language and runtime. And I guess swing also deliver on that as a cross-platform UI toolkit. However, we don't see a lot of Java UI applications around, with the exception of a few big ones, so it's fair to say that in the end it didn't work out. Of course, Java as general purpose language and runtime is alive and doing well today.
Yes, as a longtime software developer people have been trying to solve this problem different ways my entire career. The closest we got was Java swing. And it works well enough for things like eclipse but for some reason, nobody wants to use it and they want to use things like Electron instead
Regarding the "for some reason":
Java Swing (and JavaFX, and Windows Forms for that matter) all suffer from lack of integration with modern web browsers. It is near impossible to find a way to combine these model-view-controller based user interfaces with the DOM in a reasonable way.
Horrible as it is, web browsers have managed to provide a common platform for user interface delivery. The browser wars have been fierce, and getting this foot between the door has cost several companies a lot of money. This technological monopoly is far from optimal, but I fear that we are stuck with it, as we are with QWERTY keyboards, USB thumb drives that must be unmounted manually, and the hopeless misery that is Bluetooth.
That’s because companies want you tethered to their servers. There are plenty good native apps that doesn’t require to have half GB to run them. Most SaaS coul be native if they want too, but hey, you have a 32GB laptop, right? And we want all your data anyway. Here is our Electron app!
> That’s because companies want you tethered to their servers.
It is slightly more nuanced, IMHO. For enterprise software it actually makes sense to use browser based software, because it saves the IT department a lot of hassle with local installations and version management.
Yes. In fact, IBM created SWT to implement Eclipse.
Ghidra is an example of a large, cross-platform application I use regularly that does use Swing. While it's a terrific reverse engineering tool, its UI leaves at least a little to be desired. Examples, not necessarily Swing's fault:
• Non-native text controls. This is particularly painful on macOS, where Ghidra text controls don't provide access to useful system services (Web search, dictionary look-up, translation, spell check, text-to-speech, sharing, … [it's an extensible list]) and don't honor custom key bindings defined in ~/Library/KeyBindings/DefaultKeyBinding.dict.
• Non-native file open/save and print/page setup dialog boxes.
• Non-native font selection with very limited options: can't choose weights other than standard or bold, can't choose widths (condensed, expanded, etc.), can't choose OpenType stylistic alternatives, etc.
• Per-window menu bars even on platforms where global menu bars are an option (KDE) or standard (macOS). As a consequence, no menu bar search or ability to remap menu item keyboard shortcuts on macOS.
• Other fiddly control differences. For example, on macOS, Option+Right/Left Arrow on a tree view node typically expands/collapses all descendants. On Ghidra, Option+Left Arrow collapses all, but Option+Right Arrow expands only children, with an additional level expanded for each subsequent Option+Right Arrow keypress. While Ghidra's behavior is arguably more useful, it's still inconsistent with platform norms.
• High DPI scaling inconsistent across platforms (works fine by default on macOS, requires fiddling on Windows and Linux).
• No integration with system-provided dark modes.
• No out-of-box support for installation as a native GUI application (macOS app, Windows Start Menu shortcut, Linux .desktop file). To be fair, with the arguable exception of Mac apps, this is out of scope for a GUI toolkit, and I suspect most people in Ghidra's target audience have no problem hand rolling a solution.
HTML was a huge advancement, but it is likely a local maximum.
The HTML / CSS stack comes with significant ergonomic hurdles (layout / positioning / "creative fidelity") and performance hurdles (inescapable GC pauses, constant overhead of constraint-solving layout system, DOM overhead in general.)
Can we do better? IMO the future GUI lingua franca is deeply inspired by HTML and will stand on the shoulders of that giant, but will:
- Build to LLVM native apps as well as websites
- Include React-style templating as a foundational concern
- Be fundamentally designed for visual building (think of the ergonomic differences between Webflow & Figma — if "an HTML" existed that "a Figma" could read & write natively, building front-ends would take a quantum leap)
WebAssembly makes all of this possible while still extending the Web and browser ecosystems.
We have far better compilers and even languages for cross-platform work, so it should be easier by now.