This is a good counter-argument to the React proposition. It's 5 years on, and both Apple and Google are now adopting the model for themselves via SwiftUI and J

This is a good counter-argument to the React proposition. It's 5 years on, and both Apple and Google are now adopting the model for themselves via SwiftUI and JetPack Compose, but, is it actually the best way to do things? If you're used to toolkits that give you a basically fixed set of components, in which creating new components is considered an advanced operation and there's no assistance with data binding, then something like React seems like a breath of fresh air. I've done a bit of JetPack Compose, and also some JavaFX and of course HTML5 stuff. On the web React is an upgrade simply because the DOM isn't meant for UI and HTML has no notion of components at all. On Android, well, the classical Android UI toolkit was never that great. It's a Java Swing era API with three different clock classes in it! I can't comment on UIKit, never used it. Maybe a better comparison would be to something like JavaFX, which pre-dates the crazy for functional programming but benefited from the years of experience with classical toolkits like Swing/GTK etc. And here, it gets hard to really get excited by React. The blog post isn't wrong - the React model requires a ton of concepts, abstractions, and complicated infrastructures to try and recreate things that come for free in OOP toolkits. JavaFX supports data flow and binding because every property is both observable and bindable via lazy dataflow graphs. So your UI can indeed be a pure function of the model, but instead of re-execute/cache/memoize/diff, you assemble the computation graph for whatever needs to be reactive. Most of the time, you don't actually need to do anything complicated here and can write code as a straightforward imperative calculation. Creating components is likewise pretty easy, albeit JavaFX is currently in a sorry state where the open source community around it doesn't maintain the documentation properly, so it's hard to link to a tutorial that demonstrates this. But basically you get a pay-as-you-go approach in which you can just group some widgets in a class, or you can be a bit more ambitious and inherit from Control which gives you things like proper focus/tab order management, the ability to control properties using CSS and so on. When I read code written with JetPack Compose, the feeling it gives isn't really that great compared to the OOP style. The way it totally changes the core programming model of the language looks like an absolute nightmare to teach to new programmers. The most fundamental rules of the programming language are suddenly up for grabs - what looks like straight line imperative code actually isn't, variables might retain their state beyond the scope of a function call ... or might not ... and it seems like React/Compose codebases invariably degrade into tons of tiny functions passing giant amounts of stuff around on the stack, with lots of obscure performance problems that come from the game playing with the core execution model and all the diffing/patching going on behind the scenes. In the end I find I agree with the author. Good UI is not in fact a pure function and the FP model is a poor fit. There is too much implicit state that is best encapsulated in the UI framework, and with an actually well designed OOP framework data binding just isn't painful enough to justify the costs.