3 ms·
I think they adopted them for good reason and they are good at what they are made for: web pages. It shines in situations where content, behaviour and presentat
by kall 6y ago
I think they adopted them for good reason and they are good at what they are made for: web pages. It shines in situations where content, behaviour and presentation are seperate concerns.
A good example is a CMS/wordpress (which as we know makes up a third of the internet or something): Editors are concerned with content, themes are concerned with presentation, plugins are concerned with behaviour.
Applications, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there. If it does, its a different separation like M-V-C.
I think all the successful user interface things introduced in the last few years are going for an all in one code approach for good reason: SwiftUI, Flutter, Jetpack Compose, React Native... I may be a little mobile focused?
The options that ios/mac os/android offered for a while to create UI structure seperate from code where not very popular with developers which often preferred to construct and modify the entire UI tree with code "manually".
What‘s the state of the art in windows and linux UI programming?
- c-smile 6y ago> Applications, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there. I think you are making critical mistake here. IAccessible & Co. (https://docs.microsoft.com/en-us/windows/win32/api/oleacc/nn-oleacc-iaccessible https://docs.microsoft.com/en-us/windows/win32/api/oleacc/nn...) maps nearly directly onto HTML DOM tree. So no matter what CSS you have there your UI will accessible. The thing is that accessibility works acceptable only on semantic DOM trees. HTML and its DOM was designed with that in mind. Flutter's DOM is not, it is not semantic - it is a Dart code that defines visual structure for particular screen layout. Mobile applications are significantly less demanding (more simple in UI terms) - they have very reduced set of components and layouts. Essentially all mobile UIs are built with <radio>,<checkbox>,<button> and <list> vocabulary. The reason is simple: most of the time mobile apps are serving "reading user" role. While desktop is the place for "writing user"s (a.k.a "content generation" role). Desktop is the place where you must support different editing, object manipulation paradigms - UI on desktop is more rich. Just check apps on your mobile - 90% of them are very close UI-wise.
- kall 6y agoI agree that a UI is well expressed as a tree, for the sake of accessibility and other reasons. I don‘t see why there is any reason to seperate the declaration of that tree from the application code. The flutter approach is bad, but all established desktop and mobile UI frameworks provide accessibility support as good or better than HTML. In fact, HTML is ill equipped to express capital A Applications in an accessible form and needs ARIA as a bandaid to make it work. The application runtime knows about the UI tree by the time the app is running and can tell accessibility tools about it. Wether you write it down explicitly or not doesn‘t matter. It only matters for web "pages" which are original not something that is running at all.