9 ms·

I don't understand why we have to keep reinventing GUI toolkits and layout engines over and over again. Why can't this domain be smarter like Compiler world an

I don't understand why we have to keep reinventing GUI toolkits and layout engines over and over again. Why can't this domain be smarter like Compiler world and build pluggable components? So something like, a react-engine that renders the recently changed display node. The react-engine is offered as an API/library layer, it could be run in browser where it works with DOM, it could be run in a desktop where it works with GUI nodes of native GUI toolkit. So now going from each OS to another, you don't have to learn gazillion different ways to specify the layout. The type of nodes displayed on your GUI app changes from each environment to another. So you get to have the same programming techniques and you can get a web-app or a desktop app.

forgot-my-pw 8y ago
So you're asking all the OS vendors to get together and implement a universal UI toolkit? Good luck with that.
- projektfu 8y ago
  It's hard to get a single OS vendor to implement a universal UI toolkit on their own OS. Thankfully, Apple standardized around Cocoa/ObjC. Microsoft keeps proliferating new, incompatible ways to approach application development. Linux has multiple incompatible toolkits pretty much by design.
Hemospectrum 8y ago
It's one thing to draw some widgets. That's the "easy" problem (to borrow some AI jargon). It's totally another thing to specify how these widgets read and write the model in which the business logic is encoded. If you want to animate transitions between valid model states, it all gets ten times as complicated. And then when you try to make it performant by eliminating redundant redraws, it becomes an even bigger mess. There is no simple and obvious solution that tackles all of the above. The reactive UI model (not just Flutter, but all React-like frameworks) is an ongoing attempt to do a better job of all of it, with varying success. Existing UI toolkits, before the introduction of this model, were not designed for it. They were built on the assumption that the future would be a giant object graph caught in a tangle of callback methods. If you want to make a reactive UI populated by native widget objects, you have to figure out how to plumb all their mutable state back into the reactive model. That's an enormous investment of labor. Writing a new toolkit from the ground up is a huge amount of work in absolute terms, but in relative terms it's the easy way out.
- guix992 8y ago
  Thanks for your reply - it was a pretty insightful rebuttal. Do you think in the future it might be possible for say Flutter to: 1. Refactor flutter into a layout engine and gui widgets 2. Provide the layout engine as an interface on all desktop OSes. Something like a standardized syscall like interface. 3. Anyone can implement a new GUI toolkit to this layout engine interface. 4. For desktop OSes, the number of styling options is less than full blown CSS capabilities(in HTML dom) and these options get compiled out, making execution of native apps GUI slightly faster than DOM apps. Basically, desktop GUI styling is a subset of DOM CSS styling. 5. We use a JSX like templating language to specify UI that either gets compiled to HTML or generates native GUI widgets. Not sure all of my thoughts are 100% fleshed out but does this sound feasible in future?
  - projektfu 8y ago
    I like the sound of orthogonal components.
baybal2 8y ago
Both GTK and Qt can render to HTML

forgot-my-pw 8y ago

So you're asking all the OS vendors to get together and implement a universal UI toolkit? Good luck with that.

projektfu 8y ago
It's hard to get a single OS vendor to implement a universal UI toolkit on their own OS. Thankfully, Apple standardized around Cocoa/ObjC. Microsoft keeps proliferating new, incompatible ways to approach application development. Linux has multiple incompatible toolkits pretty much by design.

Hemospectrum 8y ago

It's one thing to draw some widgets. That's the "easy" problem (to borrow some AI jargon). It's totally another thing to specify how these widgets read and write the model in which the business logic is encoded. If you want to animate transitions between valid model states, it all gets ten times as complicated. And then when you try to make it performant by eliminating redundant redraws, it becomes an even bigger mess. There is no simple and obvious solution that tackles all of the above. The reactive UI model (not just Flutter, but all React-like frameworks) is an ongoing attempt to do a better job of all of it, with varying success. Existing UI toolkits, before the introduction of this model, were not designed for it. They were built on the assumption that the future would be a giant object graph caught in a tangle of callback methods. If you want to make a reactive UI populated by native widget objects, you have to figure out how to plumb all their mutable state back into the reactive model. That's an enormous investment of labor. Writing a new toolkit from the ground up is a huge amount of work in absolute terms, but in relative terms it's the easy way out.

guix992 8y ago
Thanks for your reply - it was a pretty insightful rebuttal. Do you think in the future it might be possible for say Flutter to: 1. Refactor flutter into a layout engine and gui widgets 2. Provide the layout engine as an interface on all desktop OSes. Something like a standardized syscall like interface. 3. Anyone can implement a new GUI toolkit to this layout engine interface. 4. For desktop OSes, the number of styling options is less than full blown CSS capabilities(in HTML dom) and these options get compiled out, making execution of native apps GUI slightly faster than DOM apps. Basically, desktop GUI styling is a subset of DOM CSS styling. 5. We use a JSX like templating language to specify UI that either gets compiled to HTML or generates native GUI widgets. Not sure all of my thoughts are 100% fleshed out but does this sound feasible in future?
- projektfu 8y ago
  I like the sound of orthogonal components.

baybal2 8y ago

Both GTK and Qt can render to HTML