4 ms·

I've ranted many times that an open desktop-friendly GUI markup standard is sorely needed. Using HTML/DOM/JS/CSS to emulate real desktops keeps failing in pract

by tabtab 7y ago

I've ranted many times that an open desktop-friendly GUI markup standard is sorely needed. Using HTML/DOM/JS/CSS to emulate real desktops keeps failing in practice and is an IT labor drain. Tens of $billions are wasted. Desktops/mousing is still where the vast majority of "productivity" work happens. Making everything "responsive" was an over-used trend. It failed in productivity-ville. We are using UI kits designed around social networking to make CRUD apps in our shop, and it's a match made in hell. Developers don't care because it's job security, but if you step outside your paycheck, it's mowing lawns with tweezers. Let's do it right already. I'm not saying Silverlight II is the answer, but the fact it got attention is testament to the GUI Gap.

giancarlostoro 7y ago
Would it be too wrong if we took XAML and standardized it for other languages? Pretty sure it's generic enough. Look at Avalonia: https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia Seems they wanna spec it out: https://github.com/microsoft/xaml-standard https://github.com/microsoft/xaml-standard
- tabtab 7y ago
  I don't see interactivity as part of the standard. It's all static as far as I can tell. There are language-specific API's, but that defeats much of the purpose of a markup language: you have to use two languages: the XML, and then the language-specific API's. Lack of state-handling is part of why HTML/DOM gui's are Rube Goldberg devices.
  - giancarlostoro 7y ago
    I feel like RAD tooling is the best way to do UI work, it's a shame we keep going backwards on that.
    - tabtab 7y ago
      The problem with RAD has been that it makes the first 80% easy, but the last 20% a bear. You don't get enough control to give the customer what they really want and need. I've kicked around the idea of "staged rendering". The displayed elements are generated in stages, and one can alter the meta-data used in each stage as needed via event handlers. Thus, if you need to insert an extra CSS class into an element or even totally revamp a widget's HTML, you can by altering the appropriate stage. Earlier stages would have a draft "class" attribute for the HTML element which you can change or append to. In later stages, you can overwrite the entire HTML of that element, and the very latest stages allow you change or wipe large sections of pages, like the entire form block. Similar techniques can control SQL generation. This gives you RAD-esque automation without taking away control. The automation produces various DRAFTS which you can tweak as needed along the way. The jury is still out on my experiments. Still, we need an interactive GUI markup standard regardless.

by tabtab 7y ago

giancarlostoro 7y ago

Would it be too wrong if we took XAML and standardized it for other languages? Pretty sure it's generic enough. Look at Avalonia: https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia Seems they wanna spec it out: https://github.com/microsoft/xaml-standard https://github.com/microsoft/xaml-standard

tabtab 7y ago
I don't see interactivity as part of the standard. It's all static as far as I can tell. There are language-specific API's, but that defeats much of the purpose of a markup language: you have to use two languages: the XML, and then the language-specific API's. Lack of state-handling is part of why HTML/DOM gui's are Rube Goldberg devices.
- giancarlostoro 7y ago
  I feel like RAD tooling is the best way to do UI work, it's a shame we keep going backwards on that.
  - tabtab 7y ago
    The problem with RAD has been that it makes the first 80% easy, but the last 20% a bear. You don't get enough control to give the customer what they really want and need. I've kicked around the idea of "staged rendering". The displayed elements are generated in stages, and one can alter the meta-data used in each stage as needed via event handlers. Thus, if you need to insert an extra CSS class into an element or even totally revamp a widget's HTML, you can by altering the appropriate stage. Earlier stages would have a draft "class" attribute for the HTML element which you can change or append to. In later stages, you can overwrite the entire HTML of that element, and the very latest stages allow you change or wipe large sections of pages, like the entire form block. Similar techniques can control SQL generation. This gives you RAD-esque automation without taking away control. The automation produces various DRAFTS which you can tweak as needed along the way. The jury is still out on my experiments. Still, we need an interactive GUI markup standard regardless.