We did use to do things generically, but more-or-less the wrong kind of generic. Android is a great example of this. I don't know how things are done now, but

We did use to do things generically, but more-or-less the wrong kind of generic. Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc. Of course, devices got better. That set grew to ldpi, mdpi, hdpi, xhdpi, xxhpdi, and xxxhdpi. There's also tvdpi for televisions. It was supposed to be generic. It became a mess, because they were operating at the wrong level of abstraction. But whats more; in the beginning, the `dpi` of a device was actually a consistent way to determine the screen size! I saw many apps in the day rely on this; they'd change the text sizes and paddings and even high level UI organization upon render by conditionally checking the dpi of the device. Its generic, right? Its not like I'm saying "if screen width is above 750px, render X" (cough css). I know less about android as we approach closer to today, but I'm familiar with another problem they had concerning foldables. Android apps were never designed, from the start, to be able to respond to changes in screen size! So that required some new frameworks to be put in place, and old apps had to update. Point being; our UIs have gotten more complex, because the problems they're solving have gotten more complex. We had HTML; a truly pure form of "generic UI design". But, it was designed for documents, not applications, so we built CSS and JS and wrote ourselves into the mess we're in today. Android had some ideas around generic UIs, but they too did not predict what people would actually be using their platform for and where technology was going. SwiftUI is another stab at this, and maybe they'll get it right. I don't know. But, I think technology is settling a bit, and with that settling comes a greater understanding of what UI designers need from their frameworks.