Hacker News Reader

Comment by fleabitdev | Hacker News Reader

Unlike Windows, Apple and Android have managed to publish modern UI libraries for their own platforms - but in both cases, this involved migrating the whole platform to a new programming language (Swift and Kotlin, respectively). If I remember right, C# also has a few features which were only added to make Windows Forms and WPF more ergonomic.

I'm starting to suspect that general-purpose languages just aren't flexible enough to keep up with changing fashions in UI development. Whenever somebody comes up with a new UI paradigm, you're not going to be able to take full advantage of it until somebody designs a new programming language with that paradigm in mind.

If so, this might explain why the Windows team keeps pushing new desktop UI libraries, only to abandon them within a few years - they just don't have the willingness or resources to migrate away from C# and C++, and so the quality of their UI libraries is stuck in 2006.

View on HN

The issue is the React paradigm, which is a bit questionable to begin with. It's a sort of fake OOP in a trenchcoat pretending to be something else, whilst abusing the language in ways that requires compiler plugins. My experiences with Compose and SwiftUI have been ... not that great. I kinda wish people would just have kept investing in their OOP toolkits.

You're right that reactive UI is a poor fit for most languages (especially JavaScript!), but I think the problem is more general than that.

Good UI architecture needs some convenient and efficient way to propagate state changes between different parts of the UI framework [0]. This requirement sits in an awkward place, halfway between imperative programming and functional programming. It just isn't in the day-to-day vocabulary of any mainstream language, not even modern imperative languages which have a bit of functional programming mixed in.

I don't think OOP is any better at fulfilling this requirement. Being able to offload half of your program into a visual editor is nice, but it's cold comfort if the other half of your program ends up being a tangled mess of callbacks and data binding.

[0]: https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....

We already have a solution for most UI presented in this paper [1]. Functional programming let you represent the solution in a much nicer way after you've hidden the oop/imperative machinery away. But it's a complete package where the declarative part is only the shell. The UI part of any application should be considered as an external module, (like the data access layer) and the code architecture should reflect this. In an extreme way, if you can't create a telnet interface to you GUI software, that means your interface is already too coupled to the rest of the code.

[1]: https://dl.acm.org/doi/10.1145/62402.62404

Yes you're absolutely right that these language dialects keep emerging because regular languages don't have quite the right features for reactive computations. Still, OOP was originally designed for GUIs and is a great fit for that, it's easier to build functional stuff on top than the other way around (apparently, judging from experience of having used both).

The closest I found to what I mean is that JavaFX has a whole observables framework, and there's ReactFX that builds a lot of stuff on top of it. With a small change that I prototyped in the past you can do what React Compiler is trying to do, where you run code and record what properties are read then register dependencies and re-run on change. It's quite a natural fit.

Kotlin wasn’t designed with Compose in mind. They shoehorned it via compiler plugin.

The explanation is easy, the usual WinDev versus DevDiv politics.

Reply on news.ycombinator.com