That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android. Best is to have an IR. Now maybe that IR can be turnt into native code. But we shouldn't be constrained. As an incoming framework author, SwiftUI is problematic for instance because it has a programming model which is dated. And I don't particularly enjoy the language either. Looked fine at first and then got more complex than I feel is needed.

oh yeah, disclaimer: I write UI frameworks and dabble in PLs.

▲

uncomputation an hour ago | parent | next [-]

How is SwiftUI dated? It uses a declarative model. I don’t see UI framework paradigms shifting that much.

	▲	aatd86 10 minutes ago \| parent [-]
		It is virtual dom like. We don't have access to a stable underlying element like we could with plain UIKit. You can build declarative models without this virtualdomness. But SwiftUI was created during the react boom so they went with the Zeitgeist, understandably. Now this is somewhat problematic if someone want to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).

▲

organsnyder 6 hours ago | parent | prev [-]

> That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android.

Is that something we should be engineering for right now?

	▲	aatd86 6 hours ago \| parent [-]
		Just like any engineering and business decision, this is a tradeoff. I probably don't see things from the same vantage point. Can't help but notice a trend however. What if this accelerates, especially with AI being an enabler?