3 ms·

what really got to me was the insane amount of churn, forcing me to touch decades-old code once written and long forgotten I know this is a Linux-centric artic

what really got to me was the insane amount of churn, forcing me to touch decades-old code once written and long forgotten I know this is a Linux-centric article, but I think Win32 (+WINE) is really the answer to having a stable GUI API.

_factor 2y ago
HTML and CSS with a sprinkle of JS, combined with the hardened web standardization we see today paints a pretty clear picture. JavaScript is here to stay, web browsers are here to stay, they can make GUIs that are durable. I find it comical that X was the chosen target in this article, as it will most certainly be more than crufty in 5, let alone 20 years from now.
- Chris2048 2y ago
  Surely that's a webpage, not a GUI?
  - encrypted_bird 2y ago
    If the interface layer between a user and a webpage is graphical, then that website has a GUI.
    - Chris2048 2y ago
      Then anything on a screen is a GUI, as is every website. Yet, most would consider the term to refer to purpose-build interfaces, rather than those build upon the 'GUI' of a web-browser - which has it's own idiosyncrasies.
      - jakelazaroff 2y ago
        Is an interface within a web browser not purpose-built? I think of “GUI” in contrast to “CLI” — which, yes, is inclusive of almost everything you interact with on a computer, including websites.
      - bawolff 2y ago
        If google docs doesn't count as a GUI then i dont know what does.
      - pmontra 2y ago
        Every native toolkit has its own idiosyncrasies. Some are closer to the OS official look, which changes along the years, some are different. I'm for a relaxed definition: if it's graphical it's a GUI, if it's text it's a TUI. Then we have larger or smaller rendering libraries. The browser is a particularly large one but often it's got the advantage of automatic app updates.
- userbinator 2y ago
  The web stuff churns even more - a lot more.
  - duskwuff 2y ago
    There's a lot of churn in what's used in green-field development, but browsers rarely drop support for old features, outside of extraordinary cases like the Flash plugin. Old web sites will usually work just fine in a modern browser.
    - eek2121 2y ago
      Disagree. many old features have been dropped. The blink tag, for example.
    - pajko 2y ago
      Regarding old features, Manifest V2 -> Manifest V3 was so painful to some that they dropped Chrome.
      - duskwuff 2y ago
        I'm talking about compatibility for web content, not for browser extensions which are a more volatile environment.
  - VMG 2y ago
    but rarely in a backwards incompatible way - browsers still render very old sites
- toast0 2y ago
  I'd prefer XCB over Xlib, but while X may feel crufty today and maybe even more in 5 or 20 years... it will probably still run. If you integrate with an html+js viewer, do you link it into your binary? If so, what are its dependencies and will they be around? If not, will you still be able to use the same viewer in 5-20 years or will it have some breaking change that requires additional work? Worst case, you run VcXsrv in Wine, because win32+wine is the future proof platform; but if we're all running Wayland then, Xwayland should work, and I'd bet money if there's a replacement for Wayland in the next 5-20 years, it will have an available X server even if it can't integrate with Wayland clients.
  - o11c 2y ago
    Yeah, XCB is a case where the new thing actually is a major improvement over the old. Nobody should be using Xlib by choice these days.
- Cthulhu_ 2y ago
  I've yet to see that proven though; alongside web technology based GUIs is also the concept of evergreen applications, that is, stuff that gets updated and kept up to date all the time, and force pushed to end users. And while on paper a web application built 20 years ago still works today as it was, the same can't be said about the technology used to develop and build these; there's a ridiculous amount of churn in the libraries and frameworks, to the point where you have to set up your github actions or whatever to frequently keep your stuff up to date, because if you run more than six months behind, any updates will break your carefully balanced setup. Of course, that's a choice. Ultimately there's no real need to use Typescript, a framework, or a collection of libraries, and if you do choose them, there's the huge complex but fragile ones like Angular and React and their ecosystems, or smaller ones leveraging modern web tech developments or solving only a single problem. (I'm aware React was intended that way originally but in practice it's a whole ecosystem you're pulling into your application)

_factor 2y ago

HTML and CSS with a sprinkle of JS, combined with the hardened web standardization we see today paints a pretty clear picture. JavaScript is here to stay, web browsers are here to stay, they can make GUIs that are durable. I find it comical that X was the chosen target in this article, as it will most certainly be more than crufty in 5, let alone 20 years from now.

Chris2048 2y ago
Surely that's a webpage, not a GUI?
- encrypted_bird 2y ago
  If the interface layer between a user and a webpage is graphical, then that website has a GUI.
  - Chris2048 2y ago
    Then anything on a screen is a GUI, as is every website. Yet, most would consider the term to refer to purpose-build interfaces, rather than those build upon the 'GUI' of a web-browser - which has it's own idiosyncrasies.
    - jakelazaroff 2y ago
      Is an interface within a web browser not purpose-built? I think of “GUI” in contrast to “CLI” — which, yes, is inclusive of almost everything you interact with on a computer, including websites.
    - bawolff 2y ago
      If google docs doesn't count as a GUI then i dont know what does.
    - pmontra 2y ago
      Every native toolkit has its own idiosyncrasies. Some are closer to the OS official look, which changes along the years, some are different. I'm for a relaxed definition: if it's graphical it's a GUI, if it's text it's a TUI. Then we have larger or smaller rendering libraries. The browser is a particularly large one but often it's got the advantage of automatic app updates.
userbinator 2y ago
The web stuff churns even more - a lot more.
- duskwuff 2y ago
  There's a lot of churn in what's used in green-field development, but browsers rarely drop support for old features, outside of extraordinary cases like the Flash plugin. Old web sites will usually work just fine in a modern browser.
  - eek2121 2y ago
    Disagree. many old features have been dropped. The blink tag, for example.
  - pajko 2y ago
    Regarding old features, Manifest V2 -> Manifest V3 was so painful to some that they dropped Chrome.
    - duskwuff 2y ago
      I'm talking about compatibility for web content, not for browser extensions which are a more volatile environment.
- VMG 2y ago
  but rarely in a backwards incompatible way - browsers still render very old sites
toast0 2y ago
I'd prefer XCB over Xlib, but while X may feel crufty today and maybe even more in 5 or 20 years... it will probably still run. If you integrate with an html+js viewer, do you link it into your binary? If so, what are its dependencies and will they be around? If not, will you still be able to use the same viewer in 5-20 years or will it have some breaking change that requires additional work? Worst case, you run VcXsrv in Wine, because win32+wine is the future proof platform; but if we're all running Wayland then, Xwayland should work, and I'd bet money if there's a replacement for Wayland in the next 5-20 years, it will have an available X server even if it can't integrate with Wayland clients.
- o11c 2y ago
  Yeah, XCB is a case where the new thing actually is a major improvement over the old. Nobody should be using Xlib by choice these days.
Cthulhu_ 2y ago
I've yet to see that proven though; alongside web technology based GUIs is also the concept of evergreen applications, that is, stuff that gets updated and kept up to date all the time, and force pushed to end users. And while on paper a web application built 20 years ago still works today as it was, the same can't be said about the technology used to develop and build these; there's a ridiculous amount of churn in the libraries and frameworks, to the point where you have to set up your github actions or whatever to frequently keep your stuff up to date, because if you run more than six months behind, any updates will break your carefully balanced setup. Of course, that's a choice. Ultimately there's no real need to use Typescript, a framework, or a collection of libraries, and if you do choose them, there's the huge complex but fragile ones like Angular and React and their ecosystems, or smaller ones leveraging modern web tech developments or solving only a single problem. (I'm aware React was intended that way originally but in practice it's a whole ecosystem you're pulling into your application)