| This article is weird linking together many unrelated strands of thought. Like linking reactive programming to “reactive” UIs, when really they mean UIs that are forgiving to their users instead of breaking down. Or how by coding on the web we’ve lost the immediacy of a UI that runs on our desktop, and the primitives (like undo/redo stacks) that make desktop user interfaces friendlier, at least without having to build them ourselves. And that new UI frameworks show up claiming to solve the problems that React creates with complexity, by forgoing the functionality that React provides that they pretend is unimportant by hiding behind toy examples. There’s actually not much in this article that doesn’t resonate with a jaded millenial like myself who knows their computer history, but could have been expressed more cohesively. |
I have some dream of a sort of user-interface system that exposes controls and data more directly to the user, independent of the author's stylistic choices. Sort of like semantic HTML with style-sheets that are configured on a per-user basis. It would be analogous to the unix shell in the sense that it would allow small programs to easily inter-operate, like plan9's pumbing or something. Instead of having a big monolithic program like kdenlive or blender, you would have a number of modifiable general-use programs that can be re-arranged to fit many use-cases in an extensible way.
But instead of that it just seems like every toolkit or library wants to be highly specialized and complex, and provide for a very specific use-case rather than making the most general-possible user interface that is universal. Programmers should not be concerned with the appearance of their UIs like window decorations or the layout of buttons or text fields, for the same reason they should not be concerned with the minutia of optimizing assembly-code. It leads to a non-portable design. That should be left up to the system.