3 ms·
I mean, both of those get things right. XAML/WPF tries to make the interface cleanly human editable in code, but is incredibly verbose, and the "can be human ed
by gecko 11y ago
I mean, both of those get things right. XAML/WPF tries to make the interface cleanly human editable in code, but is incredibly verbose, and the "can be human editable" constraint ends up being "is only human editable" pretty quickly. Interface Builder is a lot more intuitive and powerful, but it's more of an all-or-nothing affair, in my opinion.
Beyond that, though, they have way more in common than they do different. I'm not sure it makes sense to talk of one of them as a better model than the other, versus maybe a better implementation of the same workflow.
- thewarrior 11y agoAccording to http://stackoverflow.com/questions/2442340/how-does-cocoa-compare-to-microsoft-qt http://stackoverflow.com/questions/2442340/how-does-cocoa-co... WPF is better.
- kybernetyk 11y agoWell, as there's no Cocoa on Windows and no WPF on OS X it doesn't really matter. Also that SO post reads a lot like "I can't stand Interface Builder" (which is understandable if you aren't prepare to embrace it). I find the Cocoa model of not having to do anything with XML far better for my sanity. But then again I guess there are people who prefer XML artistry to drawRect overriding. :)