I haven't seen any cleverness in reactive code that one wouldn't encounter in a non-reactive code base. It is true that one may need to learn new abstractions, but a more imperative coding style requires lots of glue code, much of it having inconsistent quality. You'll end up needing ramp-time no matter how you go. Building UI involves the same problems and trade-offs whether using reactive programming techniques or not.
Conal Elliott's work, while super interesting, does not cover the entirety of reactive programming. I found this[1] write-up to be helpful in defining what reactive programming is and it's value. The author is a member of the team working on Swift Concurrency.
And SwiftUI is compatible with anything from UIKit, so it actually doesn't hold anyone back who wants to try to do something non-trivial. If you watch the demos, particularly from the most recent WWDC, you'll see it actually makes quite complex behavior much more doable. Does that reduce the value of esoteric framework knowledge? Perhaps it does, but that means engineers now have more time to spend on the product not less.
Conal Elliott's work, while super interesting, does not cover the entirety of reactive programming. I found this[1] write-up to be helpful in defining what reactive programming is and it's value. The author is a member of the team working on Swift Concurrency.
And SwiftUI is compatible with anything from UIKit, so it actually doesn't hold anyone back who wants to try to do something non-trivial. If you watch the demos, particularly from the most recent WWDC, you'll see it actually makes quite complex behavior much more doable. Does that reduce the value of esoteric framework knowledge? Perhaps it does, but that means engineers now have more time to spend on the product not less.
[1]https://www.oreilly.com/content/why-reactive/