5 ms·

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed.

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is starting with a Minimum Viable Product, cutting some corners and consciously making tradeoffs. And if success comes, then try to organically grow from there.

zem 4y ago
i am just interested enough in new gui toolkits that i have read through a bunch of blogposts, articles, and github repo docs for a ton of emerging ones. my overall impression is that if a lot of these "architecture astronaut" concerns are not at least planned for up front, they will never be implemented, so i welcome the OP's thoroughness in documenting the various issues to be taken into account.
- stephc_int13 4y ago
  I don't think that GUI toolkits that are in use today were born in their final form, or that everything was planned from the start. I think that unfortunate early design decisions can lead to dead-ends, or extremely painful evolution, of course, and knowledge can help, but paralysis is in my opinion an ever bigger issue. Making the perfect GUI Toolkit starts by making one that is Good Enough for some use cases.
game-of-throws 4y ago
Maybe you know this, but he already released an MVP for a GUI library: https://github.com/linebender/druid https://github.com/linebender/druid
- stephc_int13 4y ago
  Not an MVP but an early demo, from my point of view.
tayistay 4y ago
A more scrappy approach is what I'm trying to do with my library, rui [1]. Just get something out there. Also, it's really in service of my (already released) app, as opposed to trying to be a successful open source project. If others happen to like it, great! That said, I think Druid is a good Minimum Viable Product. I just needed GPU acceleration for my app, and wanted something closer to SwiftUI, which I'm used to. [1] https://github.com/audulus/rui https://github.com/audulus/rui
Diggsey 4y ago
This approach doesn't work for GUI frameworks IMO. When building an application, you're looking for a GUI library that meets a set of requirements. If it doesn't meet those requirements you're not going to use it: as an application developer you're not going to want to rewrite the fundamentals of the GUI library, so there's no opportunity for that library to improve. Maybe it would work if there was no other choice, but in the end you can always use bindings to GTK or some other mature non-Rust UI framework, or use web-view based option. In order for a pure Rust solution to succeed in the general case, it needs to meet all of these constraints from the get-go, but of course that's an insurmountable task. For that reason, I think the best approach is to not try to "solve" GUI yet, but instead focus on the pre-requisutes: - Window creation. - Text rendering. - Compositing. - Accessibility. - etc. ie. all of the things mentioned in the article can be separated out and tackled one at a time. For that reason I think the author has taken exactly the right approach.
raphlinus 4y ago
“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, would be better. But that is not in fact my goal, it is to yearn for the sea. I am, quite deliberately, spending a lot of risk points. In addition to using a language which may (see elsethread) not be a good fit for expressing UI at all, I'm building a GPU 2D renderer from scratch, also using compute shader techniques which have not been proven, and I am designing a reactive architecture that is not just a simple adaptation of React. Any of these could fail, as have some of my previous attempts. But I think they will be interesting failures, in that we'll learn something, and if all the pieces do come together, it will be a UI toolkit capable of performance completely untouchable by the existing state of the art. In turn, I'm interested in how that could open up new creative possibilities constrained by current implementations. So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work.
- mwcampbell 4y ago
  I think another great counterpoint to dogmatic incrementalism is Gary Bernhardt's classic talk "A Whole New World": https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
- joshka 4y ago
  >So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work. I love this response - stealing it :)
  - deleted 4y ago
    [deleted]
deleted 4y ago
[deleted]

zem 4y ago

i am just interested enough in new gui toolkits that i have read through a bunch of blogposts, articles, and github repo docs for a ton of emerging ones. my overall impression is that if a lot of these "architecture astronaut" concerns are not at least planned for up front, they will never be implemented, so i welcome the OP's thoroughness in documenting the various issues to be taken into account.

stephc_int13 4y ago
I don't think that GUI toolkits that are in use today were born in their final form, or that everything was planned from the start. I think that unfortunate early design decisions can lead to dead-ends, or extremely painful evolution, of course, and knowledge can help, but paralysis is in my opinion an ever bigger issue. Making the perfect GUI Toolkit starts by making one that is Good Enough for some use cases.

game-of-throws 4y ago

Maybe you know this, but he already released an MVP for a GUI library: https://github.com/linebender/druid https://github.com/linebender/druid

stephc_int13 4y ago
Not an MVP but an early demo, from my point of view.

tayistay 4y ago

A more scrappy approach is what I'm trying to do with my library, rui [1]. Just get something out there. Also, it's really in service of my (already released) app, as opposed to trying to be a successful open source project. If others happen to like it, great! That said, I think Druid is a good Minimum Viable Product. I just needed GPU acceleration for my app, and wanted something closer to SwiftUI, which I'm used to. [1] https://github.com/audulus/rui https://github.com/audulus/rui

Diggsey 4y ago

This approach doesn't work for GUI frameworks IMO. When building an application, you're looking for a GUI library that meets a set of requirements. If it doesn't meet those requirements you're not going to use it: as an application developer you're not going to want to rewrite the fundamentals of the GUI library, so there's no opportunity for that library to improve. Maybe it would work if there was no other choice, but in the end you can always use bindings to GTK or some other mature non-Rust UI framework, or use web-view based option. In order for a pure Rust solution to succeed in the general case, it needs to meet all of these constraints from the get-go, but of course that's an insurmountable task. For that reason, I think the best approach is to not try to "solve" GUI yet, but instead focus on the pre-requisutes: - Window creation. - Text rendering. - Compositing. - Accessibility. - etc. ie. all of the things mentioned in the article can be separated out and tackled one at a time. For that reason I think the author has taken exactly the right approach.

raphlinus 4y ago

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, would be better. But that is not in fact my goal, it is to yearn for the sea. I am, quite deliberately, spending a lot of risk points. In addition to using a language which may (see elsethread) not be a good fit for expressing UI at all, I'm building a GPU 2D renderer from scratch, also using compute shader techniques which have not been proven, and I am designing a reactive architecture that is not just a simple adaptation of React. Any of these could fail, as have some of my previous attempts. But I think they will be interesting failures, in that we'll learn something, and if all the pieces do come together, it will be a UI toolkit capable of performance completely untouchable by the existing state of the art. In turn, I'm interested in how that could open up new creative possibilities constrained by current implementations. So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work.

mwcampbell 4y ago
I think another great counterpoint to dogmatic incrementalism is Gary Bernhardt's classic talk "A Whole New World": https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
joshka 4y ago
>So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work. I love this response - stealing it :)
- deleted 4y ago
  [deleted]

deleted 4y ago

[deleted]