6 ms·

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 y

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.

throwaway894345 2y ago
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) * More complex layouts * Animations * Much hateful text rendering (e.g., right-to-left language support): https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/ * Accessibility 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.
- jwells89 2y ago
  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.
  - euroderf 2y ago
    Tableview? Try a Treeview. For Go UI kits you can count the treeviews on one hand.
    - jwells89 2y ago
      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.
elteto 2y ago
Why would it be easier now? What does a better compiler get you in terms of building a cross-platform UI toolkit? We now have GPUs, mobile OSs with their own separate UI abstractions, the web, WebAssembly, etc. And people want write-once deploy anywhere. You didn’t have any of that 30 years ago.
- shrubble 2y ago
  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).
  - Longhanks 2y ago
    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).
- hulitu 2y ago
  >You didn’t have any of that 30 years ago. Java ?
  - avhon1 2y ago
    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.
    - anthk 2y ago
      Inferno looked nice.
amelius 2y ago
We have HTML now, which is a great advancement. Don't forget about that.
- zackbrown 2y ago
  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.
gonzo41 2y ago
I'm still super disappointed that javafx died.
- mark38848 2y ago
  Anything related to Java dying is a win in my book
- obdev 2y ago
  JavaFX is alive. Check out what do people work on using JavaFX: https://www.jfx-central.com/links https://www.jfx-central.com/links
  - michaelsbradley 2y ago
    cljfx is worth a look too! https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
- winrid 2y ago
  It's not dead. I just launched an app this year with it. Users love it.
zackbrown 2y ago
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
- rohansingh 2y ago
  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.
  - zackbrown 2y ago
    Budget was cut because priorities were stacked and Flutter wasn't high enough. That's exactly the existential risk when beholden to "the hydra."
  - kernal 2y ago
    Yes. Layoffs were across all departments.
- bugbuddy 2y ago
  Maybe Google execs watched Theo’s JS frameworks review? https://m.youtube.com/watch?v=WJRf7dh5Zws https://m.youtube.com/watch?v=WJRf7dh5Zws
- TheCleric 2y ago
  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.
KronisLV 2y ago
I really think that the Lazarus Component Library took the right approach: https://en.wikipedia.org/wiki/Lazarus_Component_Library https://en.wikipedia.org/wiki/Lazarus_Component_Library I wonder why the idea of widgetsets never really went anywhere: https://en.wikipedia.org/wiki/Widgetset https://en.wikipedia.org/wiki/Widgetset 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. Either way, FreePascal/Lazarus were pretty amazing for RAD: https://en.wikipedia.org/wiki/Lazarus_(software) https://en.wikipedia.org/wiki/Lazarus_(software) except that the community and ecosystem isn't exactly getting bigger.
- supportengineer 2y ago
  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.
  - skydhash 2y ago
    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. [1]: https://calibre-ebook.com/ https://calibre-ebook.com/
    - supportengineer 2y ago
supportengineer 2y ago
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
- smokel 2y ago
  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.
  - skydhash 2y ago
    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!
    - smokel 2y ago
      > 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.
- wiseowise 2y ago
  Isn’t Eclipse written using SWT?
deleted 2y ago
[deleted]

throwaway894345 2y ago

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) * More complex layouts * Animations * Much hateful text rendering (e.g., right-to-left language support): https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/ * Accessibility 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.

jwells89 2y ago
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.
- euroderf 2y ago
  Tableview? Try a Treeview. For Go UI kits you can count the treeviews on one hand.
  - jwells89 2y ago
    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.

elteto 2y ago

Why would it be easier now? What does a better compiler get you in terms of building a cross-platform UI toolkit? We now have GPUs, mobile OSs with their own separate UI abstractions, the web, WebAssembly, etc. And people want write-once deploy anywhere. You didn’t have any of that 30 years ago.

shrubble 2y ago
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).
- Longhanks 2y ago
  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).
hulitu 2y ago
>You didn’t have any of that 30 years ago. Java ?
- avhon1 2y ago
  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.
  - anthk 2y ago
    Inferno looked nice.

amelius 2y ago

We have HTML now, which is a great advancement. Don't forget about that.

zackbrown 2y ago
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.

gonzo41 2y ago

I'm still super disappointed that javafx died.

mark38848 2y ago
Anything related to Java dying is a win in my book
obdev 2y ago
JavaFX is alive. Check out what do people work on using JavaFX: https://www.jfx-central.com/links https://www.jfx-central.com/links
- michaelsbradley 2y ago
  cljfx is worth a look too! https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
winrid 2y ago
It's not dead. I just launched an app this year with it. Users love it.

zackbrown 2y ago

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

rohansingh 2y ago
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.
- zackbrown 2y ago
  Budget was cut because priorities were stacked and Flutter wasn't high enough. That's exactly the existential risk when beholden to "the hydra."
- kernal 2y ago
  Yes. Layoffs were across all departments.
bugbuddy 2y ago
Maybe Google execs watched Theo’s JS frameworks review? https://m.youtube.com/watch?v=WJRf7dh5Zws https://m.youtube.com/watch?v=WJRf7dh5Zws
TheCleric 2y ago
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.

KronisLV 2y ago

I really think that the Lazarus Component Library took the right approach: https://en.wikipedia.org/wiki/Lazarus_Component_Library https://en.wikipedia.org/wiki/Lazarus_Component_Library I wonder why the idea of widgetsets never really went anywhere: https://en.wikipedia.org/wiki/Widgetset https://en.wikipedia.org/wiki/Widgetset 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. Either way, FreePascal/Lazarus were pretty amazing for RAD: https://en.wikipedia.org/wiki/Lazarus_(software) https://en.wikipedia.org/wiki/Lazarus_(software) except that the community and ecosystem isn't exactly getting bigger.

supportengineer 2y ago
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.
- skydhash 2y ago
  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. [1]: https://calibre-ebook.com/ https://calibre-ebook.com/
  - supportengineer 2y ago

supportengineer 2y ago

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

smokel 2y ago
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.
- skydhash 2y ago
  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!
  - smokel 2y ago
    > 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.
wiseowise 2y ago
Isn’t Eclipse written using SWT?

deleted 2y ago

[deleted]