4 ms·

A lot of folks have given you the advice to learn one or more existing frameworks (Dear ImGui, Qt, Cocoa, etc). This is good advice, but I don't think anyone ha

by TheTon 5y ago

A lot of folks have given you the advice to learn one or more existing frameworks (Dear ImGui, Qt, Cocoa, etc). This is good advice, but I don't think anyone has yet articulated why it's good advice. I'll try ... Good UI frameworks are composable, and progressively expose their API users (developers) to their constituent parts, which can include systems such as drawing/rendering, animation, compositing, event handling, text editing, view hierarchy, navigation, accessibility, and so forth. As you build more complex applications with a UI framework, you naturally find yourself customizing default behaviors or implementing new controls or functionality on top of the existing capabilities. You start to see how the framework itself is built just by using it. Once you reach expert level with a UI framework, you will have a conceptual understanding of how high level features of the framework are implemented in terms of the lower level functionality. As an expert, you will feel confident that you could implement a new type of control, or reimplement existing functionality such that your version is a perfect peer to the built-in functionality from the library author on all important axes (developer API, performance, user experience, etc). In some cases this might be a lot of work, but at least you should know generally how to go about it if you had to. See if you can get to expert level with at least 2 different styles of UI frameworks. At that point, you will be capable of building your own.

PaulDavisThe1st 5y ago
> At that point, you will be capable of building your own. But almost certainly should not do so.
- travisgriggs 5y ago
  Why not? Doesn’t it depend on what your goals are?
travisgriggs 5y ago
Lotsa good wisdom here > Good UI frameworks are composable, and progressively expose their API users (developers) to their constituent parts, which can include systems such as drawing/rendering, animation, compositing, event handling, text editing, view hierarchy, navigation, accessibility, and so forth. I’m curious what would be good examples and bad examples for you here? My first real UI kit was with VisualWorks Smalltalk many years ago. For me, this idea of composability and exposure was really strong here. It wasn’t always the greatest code, but all the source was exposed in the class library, and so you could just use the SelectionInList or you could dig into it, put breakpoints in it, rally take it apart and learn how it all worked at whatever level of abstraction you wanted to wade into. UIKit/Cocoa didn’t provide that level of exposure because it’s a closed source binary, but there was a time when the documentation was pretty good. And much of that still persists today. And much of it was honed by many years of NextStep development, so there’s a certain consistency to much ( but not all) of it. So it hasn’t been as good, but it’s been decent. Then there’s been Android. This has been the worst. Early to market. Continuously evolved. Chasing the latest trend in UIs. Historically sparse documentation, and when you do find stuff through searching, good luck figuring out the relevancy. So this has been the worst for me. I’d be curious which of the toolkits you’ve advanced in have been strong in your rubric, and which less so?
- ddaalluu2 5y ago
  I agree with Android. I've been trying to get into it for the last 2 weeks now and it's such a mess and it feels really outdated and the flagship IDE leaves much to be desired. Very frustrating experience.
- TheTon 5y ago
  I was deliberately vague in my post about which to choose. There's surely something worth learning from every major UI toolkit in common use today. I'd say all the bad ones I've used have something in common: they were all written by people who never grokked a good UI toolkit before setting off and writing their own. But learning from them what not to do is useful too! I personally have learned the most from Cocoa, but systems like React and Dear ImGui have definitely shown me new ways to think recently. In terms of contrasting what's strong vs weak, look at how Cocoa changed from AppKit to UIKit. They kept a lot of the same ideas: such as runloops, target/action, view hierarchy, and the responder chain, but did away with some things that were redundant (NSCell) or poorly suited to producing fluid UIs (timer based animations). Put another way, they improved composability (everything is a view as opposed to some things being views, others cells, and others still windows), and they introduced a new low level system in CoreAnimation that provided compositing and animation and made it a fundamental building block. --- An unpopular opinion I hold is that a good API design is more important than source code. Like, pick any method on UIView: strong Cocoa programmers could write a workable implementation given just the method signature and the documentation if they had to. The design of the API and how it all fits together is the real magic. Once you get that, the implementation follows. ... on the other hand, Microsoft actually tried to do that once, and their implementation was bad: https://github.com/microsoft/WinObjC/tree/develop/Frameworks/UIKit https://github.com/microsoft/WinObjC/tree/develop/Frameworks...

by TheTon 5y ago

PaulDavisThe1st 5y ago

> At that point, you will be capable of building your own. But almost certainly should not do so.

travisgriggs 5y ago
Why not? Doesn’t it depend on what your goals are?

travisgriggs 5y ago

Lotsa good wisdom here > Good UI frameworks are composable, and progressively expose their API users (developers) to their constituent parts, which can include systems such as drawing/rendering, animation, compositing, event handling, text editing, view hierarchy, navigation, accessibility, and so forth. I’m curious what would be good examples and bad examples for you here? My first real UI kit was with VisualWorks Smalltalk many years ago. For me, this idea of composability and exposure was really strong here. It wasn’t always the greatest code, but all the source was exposed in the class library, and so you could just use the SelectionInList or you could dig into it, put breakpoints in it, rally take it apart and learn how it all worked at whatever level of abstraction you wanted to wade into. UIKit/Cocoa didn’t provide that level of exposure because it’s a closed source binary, but there was a time when the documentation was pretty good. And much of that still persists today. And much of it was honed by many years of NextStep development, so there’s a certain consistency to much ( but not all) of it. So it hasn’t been as good, but it’s been decent. Then there’s been Android. This has been the worst. Early to market. Continuously evolved. Chasing the latest trend in UIs. Historically sparse documentation, and when you do find stuff through searching, good luck figuring out the relevancy. So this has been the worst for me. I’d be curious which of the toolkits you’ve advanced in have been strong in your rubric, and which less so?

ddaalluu2 5y ago
I agree with Android. I've been trying to get into it for the last 2 weeks now and it's such a mess and it feels really outdated and the flagship IDE leaves much to be desired. Very frustrating experience.
TheTon 5y ago
I was deliberately vague in my post about which to choose. There's surely something worth learning from every major UI toolkit in common use today. I'd say all the bad ones I've used have something in common: they were all written by people who never grokked a good UI toolkit before setting off and writing their own. But learning from them what not to do is useful too! I personally have learned the most from Cocoa, but systems like React and Dear ImGui have definitely shown me new ways to think recently. In terms of contrasting what's strong vs weak, look at how Cocoa changed from AppKit to UIKit. They kept a lot of the same ideas: such as runloops, target/action, view hierarchy, and the responder chain, but did away with some things that were redundant (NSCell) or poorly suited to producing fluid UIs (timer based animations). Put another way, they improved composability (everything is a view as opposed to some things being views, others cells, and others still windows), and they introduced a new low level system in CoreAnimation that provided compositing and animation and made it a fundamental building block. --- An unpopular opinion I hold is that a good API design is more important than source code. Like, pick any method on UIView: strong Cocoa programmers could write a workable implementation given just the method signature and the documentation if they had to. The design of the API and how it all fits together is the real magic. Once you get that, the implementation follows. ... on the other hand, Microsoft actually tried to do that once, and their implementation was bad: https://github.com/microsoft/WinObjC/tree/develop/Frameworks/UIKit https://github.com/microsoft/WinObjC/tree/develop/Frameworks...