That falls apart as soon as the author with the locked paragraph leaves the document open while they’re doing something else, preventing others from editing.
The framework layer of WPF is implemented in C#. WinUI is all C++, including the framework and the compositor that makes the DirectX calls.
In the framework layer, typical UI updates are faster because the WinUI data binding system uses code-generation rather than the reflection-like runtime binding system that WPF has.
WinUI also includes the rather incredible Windows.UI.Composition API’s, with things like ExpressionAnimation that enable lots of cool animations (like parallax, sticky header, or cursor-relative) at a stable 60 FPS.
Disclosure: I work at Microsoft on the Windows team.
It’s not that different from things like Protocol Buffers, and for application code it’s mostly a hidden implementation detail. The API you’re calling (like the Composition API’s in the Minesweeper example) might be calling into a separate process but you don’t have to care.
I appreciate that the UI is fresh. I'm tired of the trend of desktop apps not taking advantage of larger screens and instead just shoe-horning mobile "feed" designs into a floating window.
Not convinced that tagging is better than channels for large teams. Seems like there would be an explosion of tags to keep track of.
I’m guessing the magic layout things are intentional because SwiftUI is designed to make it easy to have one app feel native on iPhone, iPad, Apple Watch, Mac and AppleTV, which all have their own design language and ergonomics.
As long as it provides ways to override defaults and take full control where needed, this seems reasonable. I’m guessing you can drop a Metal view into your SwiftUI app, so quit complaining :)
They just happen to be handling it entirely within their view component instead of making it a function on some controller/ViewModel/whatever object that then goes and updates the bool. Each framework then has its own code gen or library or runtime magic that makes that bool change get reflected in other views.
The article is just demonstrating storing application state directly in views. Which you can do in any UI framework and works fine for small apps, but quickly falls over if the state affects multiple views. That’s the whole point of the various Model-View-* patterns, and doesn’t become less relevant just because the UI framework offers reactivity or data-binding.