4 ms·

Good GUI layer should be language agnostic. Reasons: 1. GUI is non-trivial. That is not just about problems of CPU/GPU rasterization (30...40% of all GUI probl

Good GUI layer should be language agnostic. Reasons: 1. GUI is non-trivial. That is not just about problems of CPU/GPU rasterization (30...40% of all GUI problems). There are others that we usually forget about: accessibility, customization/styling, DPI and screen device size awarness, etc. 2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run. 3. Rust is is not that good to be a language-behind-UI. Ownership graph of GUI objects can be quite complex, contain loops and can be not known at compile time. Something GCable plays significantly better in this respect. That's why JS is so popular in UI. Sciter's script is even better than JS but that's another story. So "GUI 2021" as a subject of blogging makes sense, but "Rust GUI 2021" is a bit hopeless I think.

lmm 6y ago
> 2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run. Disagree. Anything that uses a C ABI has to keep track of ownership externally, and that tends to be error-prone; you end up with excessive copying, leaks, or both. And this is a particularly thorny problem for GUIs because, as you say, ownership of GUI objects can be complicated. So it makes a lot of sense to have a Rust-specific GUI library that leverages Rust's ownership-tracking capabilities to make this easier.
- c-smile 6y ago
  UI and BL (business logic layer) can interact by messages. Think about Protocol Buffers (https://developers.google.com/protocol-buffers https://developers.google.com/protocol-buffers ) or JSON/BSON as a core of communication protocol // App side: window* pw = new Window(); pw->willReceiveMessage("account.modified", cb1); pw->willReceiveMessage("account.closed", cb2); pw->willReceiveMessage("account.wantsNew", cb3); .... pw->loadUI("accounts-view.htm"); .... pw->fireMessage("account.show", accountData: json) Messaging, as a concept, is simple and data ownership is crystal clear.
  - lmm 6y ago
    Sure, but at the cost of not being able to share logic between the two layers and giving up most of the advantages of native UI. For example, you can't have an encapsulated component that combines user input with validation that comes from the business logic - you'd have to have an input box that sends a message to the business layer when the user inputs a value and then the business layer does the validation and sends a message back.
    - c-smile 6y ago
      > you can't have an encapsulated component that combines user input with validation that comes from the business logic. Why not? On UI layer I can always do: var response = bl.sendMessage("account.validate", accountData); if( response && response.valid) ... else if( response && !response.valid ) Again, we are doing the messaging for years now, AJAX/REST are messaging protocols ... I am not saying that this is the only way... In Sciter you can use custom native UI components extending existing DOM - they can handle event, do custom painting, etc. And you can design those components in Rust, C, Go or whatever you like.
      - lmm 6y ago
        > Why not? On UI layer I can always do: var response = bl.sendMessage("account.validate", accountData); if( response && response.valid) ... else if( response && !response.valid ) Like I said, you're no longer encapsulating the validation in the component, where it logically belongs from a business point of view. You're being forced to distort your architecture for these operational concerns. And it gets worse as your structures and UI get more complicated - e.g. if I want to validate several fields within a single database transaction, that's the sort of thing that Rust's ownership system is ideal for - each datastructure can know how to validate itself given a borrowed connection handle. > Again, we are doing the messaging for years now, AJAX/REST are messaging protocols ... Yes, and the overhead of having to serialise everything is the biggest problem with web UI. If you're going to separate the UI from the business logic like that then why even bother making a native UI at all?
  - 6y ago
raphlinus 6y ago
A major motivation of the Crochet prototype is the Rust implementation of the widget tree can be driven by scripts.
- c-smile 6y ago
  Try to consider other way around. Native application is: 1. HTML - declaration of UI structure (think about accessibility here to). 2. CSS - declaration of how that UI structure shall be presented to the user. 3. script - declaration (too, sic!) of how UI structure (a.k.a. DOM) shall be updated in response to user events and application events/state. 4. Native code of application - generates events for UI, provide data to be presented, consumes UI events data updates from UI. I mean that native languages in Sciter/Rust, Sciter/C++, Sciter/Go applications are talking more with script rather than to particular UI objects. And that script plays a role of declarative/configurational layer translating linear application logic into asynchronous UI concepts. UI and business logic talk with each other in terms of messages - loosely coupled layers, separation of concerns and memory organization, all that.
rapsey 6y ago
2. Like what? Name a good cross platform GUI C lib. 3. Remains to be seen.
- c-smile 6y ago
  Being a creator of Sciter (https://sciter.com https://sciter.com), I would insist it is good in the sense: 0. Really cross platform: Win, Mac, Linux, Mobiles, IoT. 1. Uses stable (10+ years) and compact API - 30 functions really 2. Uses well known and time proven constructs: HTML/CSS 3. Battle tested, in production since 2006, Sciter UI works on 460 mln PCs and Macs. Ah, and Sciter/Rust is already here: https://github.com/sciter-sdk/rust-sciter https://github.com/sciter-sdk/rust-sciter
chrismorgan 6y ago
#1 is a non-sequitur. Yes, GUI is non-trivial. But why would that mean that a good GUI layer should be language-agnostic? It just means that if it’s not, you will need to do more work to make it good. #2 is nonsense. You assert it makes no sense to invest in only-for-Rust GUI libraries, with no support whatsoever; I flatly disagree. Part of my reasoning is that, if nothing else, an exclusive-to-Rust GUI will be ploughing new ground because of the differences that are forced on the GUI library by the differences in the language, and it will come up with new ideas that will help others in other languages, progressing the state of the art. So yeah, I think it makes a lot of sense, even if it is only available for Rust (though the potential for smooth cross-language operation definitely excites me—I said to Raph a few days ago that I was interested to note that it was actually this that was exciting me the most about the Crochet architecture, that you can have the GUI library in one language and use it entirely from a separate language). But then also as imm says, if you use bindings to something else, you’re throwing away a significant advantage of using Rust. (Similarly, you’ll want to be careful if you’re exposing Rust code to other languages to make sure that you’re not harming either side because of the difference in philosophies.) And if I want to work in Rust, why should I care about C/C++/Delphi? Why should I make compromises on the sort of GUI library I can have just because other languages exist? (Sure, there are definite advantages to pooling resources across language ecosystems, but there are costs as well, that’s my point, and why I think it is unreasonable to say say “it makes no sense” as you did.) #3 is brimming full of assumptions that there is good cause to suspect are false. You were present in the Towards Principled Reactive UI thread a few days ago (https://news.ycombinator.com/item?id=24599560 https://news.ycombinator.com/item?id=24599560), which is basically all about developing models that don’t depend on complex ownership graphs. Sure, GC languages work better for the traditional breed of observer-based GUIs, but that’s not the only feasible approach—it’s merely the simplest to implement at the library level, which is why it got so popular. So Rust is probably not a good language for supporting that particular traditional style of UI, but there’s reason to suspect that it may actually be very good for other types of UIs.
deleted 6y ago
[deleted]

lmm 6y ago

> 2. It makes no sense to invest in development of only-for-Rust GUI libraries. Just use in Rust something ready that has stable plain-C ABI. And so people from C/C++, Delphi can use it too. That would be more robust on the long run. Disagree. Anything that uses a C ABI has to keep track of ownership externally, and that tends to be error-prone; you end up with excessive copying, leaks, or both. And this is a particularly thorny problem for GUIs because, as you say, ownership of GUI objects can be complicated. So it makes a lot of sense to have a Rust-specific GUI library that leverages Rust's ownership-tracking capabilities to make this easier.

c-smile 6y ago
UI and BL (business logic layer) can interact by messages. Think about Protocol Buffers (https://developers.google.com/protocol-buffers https://developers.google.com/protocol-buffers ) or JSON/BSON as a core of communication protocol // App side: window* pw = new Window(); pw->willReceiveMessage("account.modified", cb1); pw->willReceiveMessage("account.closed", cb2); pw->willReceiveMessage("account.wantsNew", cb3); .... pw->loadUI("accounts-view.htm"); .... pw->fireMessage("account.show", accountData: json) Messaging, as a concept, is simple and data ownership is crystal clear.
- lmm 6y ago
  Sure, but at the cost of not being able to share logic between the two layers and giving up most of the advantages of native UI. For example, you can't have an encapsulated component that combines user input with validation that comes from the business logic - you'd have to have an input box that sends a message to the business layer when the user inputs a value and then the business layer does the validation and sends a message back.
  - c-smile 6y ago
    > you can't have an encapsulated component that combines user input with validation that comes from the business logic. Why not? On UI layer I can always do: var response = bl.sendMessage("account.validate", accountData); if( response && response.valid) ... else if( response && !response.valid ) Again, we are doing the messaging for years now, AJAX/REST are messaging protocols ... I am not saying that this is the only way... In Sciter you can use custom native UI components extending existing DOM - they can handle event, do custom painting, etc. And you can design those components in Rust, C, Go or whatever you like.
    - lmm 6y ago
      > Why not? On UI layer I can always do: var response = bl.sendMessage("account.validate", accountData); if( response && response.valid) ... else if( response && !response.valid ) Like I said, you're no longer encapsulating the validation in the component, where it logically belongs from a business point of view. You're being forced to distort your architecture for these operational concerns. And it gets worse as your structures and UI get more complicated - e.g. if I want to validate several fields within a single database transaction, that's the sort of thing that Rust's ownership system is ideal for - each datastructure can know how to validate itself given a borrowed connection handle. > Again, we are doing the messaging for years now, AJAX/REST are messaging protocols ... Yes, and the overhead of having to serialise everything is the biggest problem with web UI. If you're going to separate the UI from the business logic like that then why even bother making a native UI at all?
- 6y ago

raphlinus 6y ago

A major motivation of the Crochet prototype is the Rust implementation of the widget tree can be driven by scripts.

c-smile 6y ago
Try to consider other way around. Native application is: 1. HTML - declaration of UI structure (think about accessibility here to). 2. CSS - declaration of how that UI structure shall be presented to the user. 3. script - declaration (too, sic!) of how UI structure (a.k.a. DOM) shall be updated in response to user events and application events/state. 4. Native code of application - generates events for UI, provide data to be presented, consumes UI events data updates from UI. I mean that native languages in Sciter/Rust, Sciter/C++, Sciter/Go applications are talking more with script rather than to particular UI objects. And that script plays a role of declarative/configurational layer translating linear application logic into asynchronous UI concepts. UI and business logic talk with each other in terms of messages - loosely coupled layers, separation of concerns and memory organization, all that.

rapsey 6y ago

2. Like what? Name a good cross platform GUI C lib. 3. Remains to be seen.

c-smile 6y ago
Being a creator of Sciter (https://sciter.com https://sciter.com), I would insist it is good in the sense: 0. Really cross platform: Win, Mac, Linux, Mobiles, IoT. 1. Uses stable (10+ years) and compact API - 30 functions really 2. Uses well known and time proven constructs: HTML/CSS 3. Battle tested, in production since 2006, Sciter UI works on 460 mln PCs and Macs. Ah, and Sciter/Rust is already here: https://github.com/sciter-sdk/rust-sciter https://github.com/sciter-sdk/rust-sciter

chrismorgan 6y ago

#1 is a non-sequitur. Yes, GUI is non-trivial. But why would that mean that a good GUI layer should be language-agnostic? It just means that if it’s not, you will need to do more work to make it good. #2 is nonsense. You assert it makes no sense to invest in only-for-Rust GUI libraries, with no support whatsoever; I flatly disagree. Part of my reasoning is that, if nothing else, an exclusive-to-Rust GUI will be ploughing new ground because of the differences that are forced on the GUI library by the differences in the language, and it will come up with new ideas that will help others in other languages, progressing the state of the art. So yeah, I think it makes a lot of sense, even if it is only available for Rust (though the potential for smooth cross-language operation definitely excites me—I said to Raph a few days ago that I was interested to note that it was actually this that was exciting me the most about the Crochet architecture, that you can have the GUI library in one language and use it entirely from a separate language). But then also as imm says, if you use bindings to something else, you’re throwing away a significant advantage of using Rust. (Similarly, you’ll want to be careful if you’re exposing Rust code to other languages to make sure that you’re not harming either side because of the difference in philosophies.) And if I want to work in Rust, why should I care about C/C++/Delphi? Why should I make compromises on the sort of GUI library I can have just because other languages exist? (Sure, there are definite advantages to pooling resources across language ecosystems, but there are costs as well, that’s my point, and why I think it is unreasonable to say say “it makes no sense” as you did.) #3 is brimming full of assumptions that there is good cause to suspect are false. You were present in the Towards Principled Reactive UI thread a few days ago (https://news.ycombinator.com/item?id=24599560 https://news.ycombinator.com/item?id=24599560), which is basically all about developing models that don’t depend on complex ownership graphs. Sure, GC languages work better for the traditional breed of observer-based GUIs, but that’s not the only feasible approach—it’s merely the simplest to implement at the library level, which is why it got so popular. So Rust is probably not a good language for supporting that particular traditional style of UI, but there’s reason to suspect that it may actually be very good for other types of UIs.

deleted 6y ago

[deleted]