3 ms·

What's really sad imho isn't that XUL is gone (when I considered using it, I quickly gave it up for mostly the same reasons that several others already wrote ab

What's really sad imho isn't that XUL is gone (when I considered using it, I quickly gave it up for mostly the same reasons that several others already wrote about ITT)… … no, what's really sad is that there is still no satisfying solution to the problem that XUL was trying to solve, i.e.: the need for a native cross-platform GUI lib; and apart from the special situation of the likes of Mozilla (where a Web browser engine is the central major part of the product and its UI anyways so it makes sense that they use that engine for what little and relatively simple and not performance-sensitive GUI is added to or around the browser view as well)… … apart from very few such cases, Web isn't the answer either. In particular, Electron apps suffer from the unnecessarily enormous added deadweight of the de-facto-integrated browser and while its performance is good enough for simple use cases, it quickly becomes limiting when the UI gets more complex or when you need to integrate stuff that is performance-sensitive or requires a different rendering. There are a couple cross-platform UI libs out there, but compared to other domains (where it's often easier to find a satisfying lib), I find that they all have some major problems, in particular: * Qt, which did look promising in its Nokia days, went down a sore downhill shitslope since Microsoft mole Stephen Elop threw it out to Digia, where (especially since splitted out as QTCOM) the licensing focus of Qt has shifted from "make it more open and permissive so as to gain wide dev community/traction" (the strategy under Nokia) to "try to force devs into commercial licensing schemes and monetize to the max you can milk out of it while it lasts"… and as a consequence, more and more previously Qt-oriented devs looking elsewhere. * neither GTK nor Flutter are satisfying answers either. I think there is really a big window of opportunity and gap to be filled by a new modern cross-platform UI toolkit with wide portability (at least Windoze, Linux, MacOS, iOS, Android, embedded; though a Vulkan-based renderer can be made to run pretty much anywhere), a permissive open source license, a C interface/wrap to allow a wide programming language binding support, and an easily extensible and themable set of basic widgets.

le-mark 4y ago
It’s a tough problem and the fact that in 2023 there is no defacto solutions is a good indicator. Certainly there are contenders and they’ll be commented here. In my experience selling a cross platform shareware app around 2010 (when that was still a thing) the best practice if you wanted a consistent user experience was to use the platform native framework and make the application code as modular and independent as possible. My sense is that is mostly the same today.
- EntrePrescott 4y ago
  I don't even require "native" in the sense of a look and feel identical to that of the platform-specific GUI framework provided by the vendor of that platform… that would indeed be an additional layer of difficulty for a cross platform framework… and the degree to which the different cross-platform toolkits with an own rendering manage to mimick it is quite variable. But I don't even need that. I'm fine with the widgets/UIs of my applications having their own styling that, while (apart from my own special widgets) staying close enough to be understandable by everyone, don't totally closely match the exact current style / "look&feel" of the apps of the platform vendors. What I did mean with "native" in my last comment was simpler than that: I just meant "native" as in: not a web app or similar detached via abstraction layers and bundled with a browser that interprets it, but a natively compiled app that is directly linked to the rendering GUI lib. That would even be enough for me. But even for that, I find there isn't a satisfying cross-platform solution.
  - c-smile 4y ago
    > but a natively compiled app that is directly linked to the rendering GUI lib. That's Sciter. It is a standalone embeddable library that does not use browser engine. It has its own HTML/CSS rendering engine that draws stuff using DirectX, Vulkan (Win/Lin) and Metal(MacOS). It is used in many (~500 mln installations) applications that are considered native. Like Norton and other antiviruses (https://sciter.com/#customers https://sciter.com/#customers)
c-smile 4y ago
Check my Sciter ( https://sciter.com https://sciter.com ) It is embeddable HTML/CSS/JS/ UI layer by design. If you want to check how it feels in real life application then check https://notes.sciter.com/ https://notes.sciter.com/ . That's monolithic, portable executable (~7mb) that includes Sciter itself and HTML/CSS/JS/ resources of the application ( https://gitlab.com/c-smile/sciter.notes/-/tree/main/src/res https://gitlab.com/c-smile/sciter.notes/-/tree/main/src/res )
- EntrePrescott 4y ago
  So I Had a quick look at https://sciter.com/prices/ https://sciter.com/prices/ and my understanding is that it does not satisfy the "permissive open source license" criterion of my last comment. In fact, it seems that it's not open source at all (a choice that I respect, but that comes with its own set of problems, see below). In particular: the "FREE" option means Free as in free beer (i.e. zero cost), but not "FREE" as in libre: it doesn't give me access to the source code, only to "binary form as it is published on the site". And if I want "Access to sources, 1 year", I have to choose between one of a number of commercial license options that for cross-platform (*) range from "INDIE+" (limited to "companies having three or less employees") for 620 US$ + 310$ per following year(s), via "BUSINESS+" (to escape the limit on employee count) for 2720 US$ + 1720 US$ per following year(s)… both of which still require me to mention “this code contains Sciter engine” in “about” screens or the like… a requirement which only goes away with the "ENTERPRISE++" option which is on a "Please contact us for the price" basis… as is the "OEM/FIRMWARE" option for embedded stuff. (*) cross platform, as per https://sciter.com/sciter/crossplatform/ https://sciter.com/sciter/crossplatform/ meaning Windows, Mac OSX and Linux / other Unixes (GTK3 based), whereas mobile OSes are mentioned as: > "Other OSes: In principle Sciter can be ported to any OS that has graphical primitives ready. For example Sciter can be compiled to run on iOS. Or with some effort to work on Android using either existing Cairo backend or Skia graphics layer" In our case, even aside from the the licensing and the "with some effort" for Android that makes me wary and that I can't evaluate for lack of access to the source code, It just so happens that we have a number of other libs to integrate, some of which add their own rendering (which requires access to e.g. a Vulkan context, not merely HTML/CSS or other high-level UI elements)… so that I can't justify to blindly pay that much upfront before even having a possibility to evaluate the source code first, just on blind hope, for a UI toolkit that may or may not, depending on the source code that I don't have access to otherwise, turn out to very hard or even impossible to integrate with the other libs. Sorry, but I'll have to pass.
fschuett 4y ago
Azul[1] is my solution for that, it is based on WebRender, so basically the same as XUL, but in a more modern way. I didn't get around to finish it in 2019, but I will work on it this year, maybe I'll get it to be mature enough to post it here. > wide portability (at least Windoze, Linux, MacOS, iOS, Android, embedded: Azul is Windows-Linux-Mac only, don't underestimate the effort to properly port something to a new platform > "though a Vulkan-based renderer can be made to run pretty much anywhere": WebRender is OpenGL + using software rendering as a fallback > a permissive open source license: MPL-2.0 > a C interface/wrap to allow a wide programming language binding support: yes > and an easily extensible and themable set of basic widgets: also yes, but the CSS styling works a bit differently depending on whether you want convenience or speed Check the screenshots[2], I personally use it for developing GIS applications. [1] https://azul.rs/ https://azul.rs/ [2] https://github.com/fschutt/azul/releases/tag/1.0.0-alpha1 https://github.com/fschutt/azul/releases/tag/1.0.0-alpha1
- nicoburns 4y ago
  Interesting. I'd definitely written azul off as abandoned. Webrender seems like a bit of a double-edged sword. On the one hand it has an incredibly rich and mature feature set. On the other hand it's woefully documented and constantly updating.
nicoburns 4y ago
There are a number of up-and-coming Rust-based frameworks in this niche: - https://github.com/iced-rs/iced https://github.com/iced-rs/iced (probably the most usable today) - https://github.com/vizia/vizia https://github.com/vizia/vizia - https://github.com/marc2332/freya https://github.com/marc2332/freya - https://github.com/linebender/xilem https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record) What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have: - https://github.com/rust-windowing/winit https://github.com/rust-windowing/winit (cross-platform window creation) - https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12) - https://github.com/linebender/vello https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu) - https://github.com/DioxusLabs/taffy https://github.com/DioxusLabs/taffy (UI layout algorithms) - https://github.com/pop-os/cosmic-text https://github.com/pop-os/cosmic-text (text rendering and editing) - https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit (cross-platform accessibility APIs) In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)

le-mark 4y ago

It’s a tough problem and the fact that in 2023 there is no defacto solutions is a good indicator. Certainly there are contenders and they’ll be commented here. In my experience selling a cross platform shareware app around 2010 (when that was still a thing) the best practice if you wanted a consistent user experience was to use the platform native framework and make the application code as modular and independent as possible. My sense is that is mostly the same today.

EntrePrescott 4y ago
I don't even require "native" in the sense of a look and feel identical to that of the platform-specific GUI framework provided by the vendor of that platform… that would indeed be an additional layer of difficulty for a cross platform framework… and the degree to which the different cross-platform toolkits with an own rendering manage to mimick it is quite variable. But I don't even need that. I'm fine with the widgets/UIs of my applications having their own styling that, while (apart from my own special widgets) staying close enough to be understandable by everyone, don't totally closely match the exact current style / "look&feel" of the apps of the platform vendors. What I did mean with "native" in my last comment was simpler than that: I just meant "native" as in: not a web app or similar detached via abstraction layers and bundled with a browser that interprets it, but a natively compiled app that is directly linked to the rendering GUI lib. That would even be enough for me. But even for that, I find there isn't a satisfying cross-platform solution.
- c-smile 4y ago
  > but a natively compiled app that is directly linked to the rendering GUI lib. That's Sciter. It is a standalone embeddable library that does not use browser engine. It has its own HTML/CSS rendering engine that draws stuff using DirectX, Vulkan (Win/Lin) and Metal(MacOS). It is used in many (~500 mln installations) applications that are considered native. Like Norton and other antiviruses (https://sciter.com/#customers https://sciter.com/#customers)

c-smile 4y ago

Check my Sciter ( https://sciter.com https://sciter.com ) It is embeddable HTML/CSS/JS/ UI layer by design. If you want to check how it feels in real life application then check https://notes.sciter.com/ https://notes.sciter.com/ . That's monolithic, portable executable (~7mb) that includes Sciter itself and HTML/CSS/JS/ resources of the application ( https://gitlab.com/c-smile/sciter.notes/-/tree/main/src/res https://gitlab.com/c-smile/sciter.notes/-/tree/main/src/res )

EntrePrescott 4y ago
So I Had a quick look at https://sciter.com/prices/ https://sciter.com/prices/ and my understanding is that it does not satisfy the "permissive open source license" criterion of my last comment. In fact, it seems that it's not open source at all (a choice that I respect, but that comes with its own set of problems, see below). In particular: the "FREE" option means Free as in free beer (i.e. zero cost), but not "FREE" as in libre: it doesn't give me access to the source code, only to "binary form as it is published on the site". And if I want "Access to sources, 1 year", I have to choose between one of a number of commercial license options that for cross-platform (*) range from "INDIE+" (limited to "companies having three or less employees") for 620 US$ + 310$ per following year(s), via "BUSINESS+" (to escape the limit on employee count) for 2720 US$ + 1720 US$ per following year(s)… both of which still require me to mention “this code contains Sciter engine” in “about” screens or the like… a requirement which only goes away with the "ENTERPRISE++" option which is on a "Please contact us for the price" basis… as is the "OEM/FIRMWARE" option for embedded stuff. (*) cross platform, as per https://sciter.com/sciter/crossplatform/ https://sciter.com/sciter/crossplatform/ meaning Windows, Mac OSX and Linux / other Unixes (GTK3 based), whereas mobile OSes are mentioned as: > "Other OSes: In principle Sciter can be ported to any OS that has graphical primitives ready. For example Sciter can be compiled to run on iOS. Or with some effort to work on Android using either existing Cairo backend or Skia graphics layer" In our case, even aside from the the licensing and the "with some effort" for Android that makes me wary and that I can't evaluate for lack of access to the source code, It just so happens that we have a number of other libs to integrate, some of which add their own rendering (which requires access to e.g. a Vulkan context, not merely HTML/CSS or other high-level UI elements)… so that I can't justify to blindly pay that much upfront before even having a possibility to evaluate the source code first, just on blind hope, for a UI toolkit that may or may not, depending on the source code that I don't have access to otherwise, turn out to very hard or even impossible to integrate with the other libs. Sorry, but I'll have to pass.

fschuett 4y ago

Azul[1] is my solution for that, it is based on WebRender, so basically the same as XUL, but in a more modern way. I didn't get around to finish it in 2019, but I will work on it this year, maybe I'll get it to be mature enough to post it here. > wide portability (at least Windoze, Linux, MacOS, iOS, Android, embedded: Azul is Windows-Linux-Mac only, don't underestimate the effort to properly port something to a new platform > "though a Vulkan-based renderer can be made to run pretty much anywhere": WebRender is OpenGL + using software rendering as a fallback > a permissive open source license: MPL-2.0 > a C interface/wrap to allow a wide programming language binding support: yes > and an easily extensible and themable set of basic widgets: also yes, but the CSS styling works a bit differently depending on whether you want convenience or speed Check the screenshots[2], I personally use it for developing GIS applications. [1] https://azul.rs/ https://azul.rs/ [2] https://github.com/fschutt/azul/releases/tag/1.0.0-alpha1 https://github.com/fschutt/azul/releases/tag/1.0.0-alpha1

nicoburns 4y ago
Interesting. I'd definitely written azul off as abandoned. Webrender seems like a bit of a double-edged sword. On the one hand it has an incredibly rich and mature feature set. On the other hand it's woefully documented and constantly updating.

nicoburns 4y ago

There are a number of up-and-coming Rust-based frameworks in this niche: - https://github.com/iced-rs/iced https://github.com/iced-rs/iced (probably the most usable today) - https://github.com/vizia/vizia https://github.com/vizia/vizia - https://github.com/marc2332/freya https://github.com/marc2332/freya - https://github.com/linebender/xilem https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record) What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have: - https://github.com/rust-windowing/winit https://github.com/rust-windowing/winit (cross-platform window creation) - https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12) - https://github.com/linebender/vello https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu) - https://github.com/DioxusLabs/taffy https://github.com/DioxusLabs/taffy (UI layout algorithms) - https://github.com/pop-os/cosmic-text https://github.com/pop-os/cosmic-text (text rendering and editing) - https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit (cross-platform accessibility APIs) In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)