5 ms·

Sciter's author here... "Markup languages for a GUI where isn't needed..." You've missed big picture. Markup language defines DOM structure (tree of UI objec

Sciter's author here... "Markup languages for a GUI where isn't needed..." You've missed big picture. Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes. ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language. Either binary one (e.g. Windows dialog resources) or text based ones (XAML,HTML,QML, etc). And HTML parsing is not significantly slower (https://www.codeproject.com/Articles/14076/Fast-and-Compact-HTML-XML-Scanner-Tokenizer https://www.codeproject.com/Articles/14076/Fast-and-Compact-...) then deciphering of binary formats. Yet the Accessibility ... that thing alone mandates DOM tree to be present. Of course you can have UI where components are nailed down to pixel grids and colors but think about HighRes monitors, RTL languages, support of night/day theming, branding, etc. Considering all that you will quickly understand that you need all three components: DOM, style system for the DOM and code that changes state of that DOM. Just to have all this modular an manageable on the long run.

BubRoss 7y ago
I don't think I've missed much. > ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language. You are conflating DOM and markup language with heirarchy/dependencies. It isn't necessary to have a text language with lots of different overlapping rules and syntax. > And HTML parsing is not significantly slower It's not about speed, it's about unnecessary complexity just to get a layout heirarchy and dependencies. > UI where components are nailed down to pixel grids and colors That's a false dichotomy. UIs have been laying out their components without parsing text for almost half a century.
- c-smile 7y ago
  > a text language with lots of different overlapping rules and syntax. Could you elaborate more on this? What are those overlapping rules? > unnecessary complexity just to get a layout heirarchy and dependencies. I have no idea why you think it is so complex... DOM element is this: class Element { weak_ptr<Element> parent; vector<ptr<Element>> children; map<...> attributes; } And you will see EXACTLY the same structure in any GUI framework/system.
  - BubRoss 7y ago
    I'm talking about unnecessary complexity when laying out the gui, not implementation. There is no reason to introduce HTML with the various rules in various places, verbosity and indirection. It's a scenario that seems like when all you have is a hammer, everything looks like a nail. > And you will see EXACTLY the same structure in any GUI framework/system. I'm sure it works fine, but I wouldn't get stuck on thinking there is no other way.
    - c-smile 7y ago
      "a hammer" you mean Electron and it's full scale browser, right? "I wouldn't get stuck on thinking there is no other way" There is a way, named "Dear ImGUI", that does not use DOM structure but rather recreates its on each paint event.
      - BubRoss 7y ago
        You need to focus, no one is talking about electron. It's in its own world of nonsense. > There is a way, named "Dear ImGUI" I'm not talking about immediate GUIs (and they use a heirarchy for layout too of course). You put some example c++ and said every GUI has that same structure, which isn't necessarily true. A heirarchy doesn't have to be implemented with a tree of pointers. I'm not saying these things can't work, but saying 'this is how it must be done' is just not true.
        c-smile 7y ago
        > every GUI has that same structure, which isn't necessarily true I'd insist on EVERY here. Container holds list of children. Child holds reference to parent - typical tree implementation. If you have in mind something else - please show.
        BubRoss 7y ago
        You showed a few lines of C++. Even for heirarchy,this doesn't need to be a tree of pointers. It's not so bad if it is, but data can be represented as tables or arrays of attributes. Really in a ui the layout is about dependencies and doesn't strictly have to be hierarchy. It's not all that important, just saying that everything must be done in a certain way is ridiculous.
geezerjay 7y ago
> Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes. You've argued that UIs require a DOM. Ok, so UIs require a DOM. That still fails to make a case for needing a separate proprietary markup language to define a DOM, let alone a XML-based one. Even the Qt folks learned that lesson nearly a decade ago with the introduction of QML. https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML

BubRoss 7y ago

I don't think I've missed much. > ANY UI application uses DOM tree in either form. And so ANY application uses some sort of markup language. You are conflating DOM and markup language with heirarchy/dependencies. It isn't necessary to have a text language with lots of different overlapping rules and syntax. > And HTML parsing is not significantly slower It's not about speed, it's about unnecessary complexity just to get a layout heirarchy and dependencies. > UI where components are nailed down to pixel grids and colors That's a false dichotomy. UIs have been laying out their components without parsing text for almost half a century.

c-smile 7y ago
> a text language with lots of different overlapping rules and syntax. Could you elaborate more on this? What are those overlapping rules? > unnecessary complexity just to get a layout heirarchy and dependencies. I have no idea why you think it is so complex... DOM element is this: class Element { weak_ptr<Element> parent; vector<ptr<Element>> children; map<...> attributes; } And you will see EXACTLY the same structure in any GUI framework/system.
- BubRoss 7y ago
  I'm talking about unnecessary complexity when laying out the gui, not implementation. There is no reason to introduce HTML with the various rules in various places, verbosity and indirection. It's a scenario that seems like when all you have is a hammer, everything looks like a nail. > And you will see EXACTLY the same structure in any GUI framework/system. I'm sure it works fine, but I wouldn't get stuck on thinking there is no other way.
  - c-smile 7y ago
    "a hammer" you mean Electron and it's full scale browser, right? "I wouldn't get stuck on thinking there is no other way" There is a way, named "Dear ImGUI", that does not use DOM structure but rather recreates its on each paint event.
    - BubRoss 7y ago
      You need to focus, no one is talking about electron. It's in its own world of nonsense. > There is a way, named "Dear ImGUI" I'm not talking about immediate GUIs (and they use a heirarchy for layout too of course). You put some example c++ and said every GUI has that same structure, which isn't necessarily true. A heirarchy doesn't have to be implemented with a tree of pointers. I'm not saying these things can't work, but saying 'this is how it must be done' is just not true.
      - c-smile 7y ago
        > every GUI has that same structure, which isn't necessarily true I'd insist on EVERY here. Container holds list of children. Child holds reference to parent - typical tree implementation. If you have in mind something else - please show.
        BubRoss 7y ago
        You showed a few lines of C++. Even for heirarchy,this doesn't need to be a tree of pointers. It's not so bad if it is, but data can be represented as tables or arrays of attributes. Really in a ui the layout is about dependencies and doesn't strictly have to be hierarchy. It's not all that important, just saying that everything must be done in a certain way is ridiculous.

geezerjay 7y ago

> Markup language defines DOM structure (tree of UI objects). And you must have DOM in your application, either as tree of DOM nodes or tree of window nodes. You've argued that UIs require a DOM. Ok, so UIs require a DOM. That still fails to make a case for needing a separate proprietary markup language to define a DOM, let alone a XML-based one. Even the Qt folks learned that lesson nearly a decade ago with the introduction of QML. https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML