3 ms·

I would not say that Web UI is that more complex than desktop UI. In principle. It is media that changed quite a lot - spectrum of devices that we need to show

I would not say that Web UI is that more complex than desktop UI. In principle. It is media that changed quite a lot - spectrum of devices that we need to show our UI on. We had pretty much fixed 80x24 character terminals, then we had 640x480 pixel grids, sometimes 800x600 and more. But at that times you can still assume that pixel is presented to the user as a square of 1/96 x 1/96 of inch. Such fix allowed us to use UI designs nailed down to pixels grids. That was time of flourishing WYSIWYG UI editors. Alice, designing her UI in Delphi (or VB) editor, can be sure that Bob will see it in the same way. Her cool 16px icons and bitmap fonts will make Bob and friends happy. When we needed some "extremely cool" stuff at that time we were providing bitmapped skins. Remember WinAmp (https://skins.webamp.org/ https://skins.webamp.org/)? Time is passing by and we have now huge variety of devices with different pixel densities (96ppi, 192ppi, 300+ ppi) and pixel grid sizes - from watches to wall sized TVs. But we still want to show the UI on all of them in reasonable manner. The solution is to change paradigm an so to use a) vectors for UI definitions and b) flexible/adjustable UI definitions that are detached from pixel grids. Web, as a UI platform, desperately needed vector UI with flexible layouts as the very same web page needs to be presented on all platforms|devices in reasonable manner. And so it was the first one that departed from fixed layouts. So UI design have changed from simple 2D painting (physical brushes and canvas, paint.exe ... Delphi/VB/Glade IDEs) to procedural and rule (layout, style) definitions. We speak now in quite different UI language and that's what was changed really.

TheOtherHobbes 4y ago
Web UIs should have been procedural from the start, but HTML's design confused semantics and visualisation. CSS was supposed to clarify this, but CSS isn't procedural either. So js was added to the mix to fill the gaps in what CSS can't do. But js doesn't componentise well, so React was invented as yet another layer to "simplify" everything else. So now we have a "proper" frontend dev language which sits on top of a virtual DOM which is still based on HTML etc. All of this could have been avoided by making Web 1.0 procedural and explicitly extensible and not baking content styling into HTML's semantics. There would have been some small additional complexity and it might have been harder for beginners to learn initially. But the current stack is far beyond non-developers anyway. I suspect there would have been at least a fighting chance of replacing everything with a single standard library that runs faster and could easily handle everything React does more simply and elegantly, including resolution-dependent rendering - probably something like iOS/Android, but even simpler, and using the browser explicitly as a VM/secure container.
- c-smile 4y ago
  HTML is nothing more than grouping definition of DOM elements. One of possible ways of defining element agglomerations. It is not bad or good, it just allows to make job done - to group (semantically link) DOM elements together. But the DOM element itself is what makes the difference. DOM element is the atomic block that a) can be attributed, b) may have states c) to be styled according to those attributes and states and d) can receive events. In that respect Web UI is more granular than desktop UI. On desktop you have windows (NSViews, GtkWidgets, etc) that are macro state machines. E.g. COMBOBOX, LISTVIEW that have predefined complex structures and expose quite few configuration options|styles. Web UI components are usually composed from many individually accessible and configurable DOM elements. And that creates an impression of Web UI complexity. But in fact Web UI is just a DOM element with styles and bunch of layout managers to replace those DOM elements - its vocabulary is conceptually simpler and more regular than desktop macro blocks. ReactJS (PReact, Mithril, Vue, etc) are not more than reactive DOM element aggregators - definitions of runtime assemblage of those LEGO bricks (DOM elements) in response of state/attributes changes. On top of those we have Web UI frameworks that are all about providing sets of components - predefined types of aggregates of DOM elements.

TheOtherHobbes 4y ago

Web UIs should have been procedural from the start, but HTML's design confused semantics and visualisation. CSS was supposed to clarify this, but CSS isn't procedural either. So js was added to the mix to fill the gaps in what CSS can't do. But js doesn't componentise well, so React was invented as yet another layer to "simplify" everything else. So now we have a "proper" frontend dev language which sits on top of a virtual DOM which is still based on HTML etc. All of this could have been avoided by making Web 1.0 procedural and explicitly extensible and not baking content styling into HTML's semantics. There would have been some small additional complexity and it might have been harder for beginners to learn initially. But the current stack is far beyond non-developers anyway. I suspect there would have been at least a fighting chance of replacing everything with a single standard library that runs faster and could easily handle everything React does more simply and elegantly, including resolution-dependent rendering - probably something like iOS/Android, but even simpler, and using the browser explicitly as a VM/secure container.

c-smile 4y ago
HTML is nothing more than grouping definition of DOM elements. One of possible ways of defining element agglomerations. It is not bad or good, it just allows to make job done - to group (semantically link) DOM elements together. But the DOM element itself is what makes the difference. DOM element is the atomic block that a) can be attributed, b) may have states c) to be styled according to those attributes and states and d) can receive events. In that respect Web UI is more granular than desktop UI. On desktop you have windows (NSViews, GtkWidgets, etc) that are macro state machines. E.g. COMBOBOX, LISTVIEW that have predefined complex structures and expose quite few configuration options|styles. Web UI components are usually composed from many individually accessible and configurable DOM elements. And that creates an impression of Web UI complexity. But in fact Web UI is just a DOM element with styles and bunch of layout managers to replace those DOM elements - its vocabulary is conceptually simpler and more regular than desktop macro blocks. ReactJS (PReact, Mithril, Vue, etc) are not more than reactive DOM element aggregators - definitions of runtime assemblage of those LEGO bricks (DOM elements) in response of state/attributes changes. On top of those we have Web UI frameworks that are all about providing sets of components - predefined types of aggregates of DOM elements.