Comment by tabtab | Hacker News Reader

Comment by tabtab | Hacker News Reader

GUI's, such as a GUI Markup Standard. Mobile UI conventions stole the show, but IN PRACTICE gui's still rule the office and productivity world.

Yet, our current web standards are GUI and CRUD un-friendly. To be desktop-like in a browser requires giant JavaScript libraries which are clunky and buggy.

GUI's may no longer be sexy, but they still run the backlots of the world and that's not likely to change within the next decade or more. Mobile UI's are a sub-set of rich GUI's, which logically means they don't have the same full ability. I could list several UI patterns GUI's do with fewer human eye and finger movements.

So, let's create a state-friendly GUI markup standard so we can have rich GUI's in browsers without requiring bloated buggy JS/CSS libraries.

And somewhat related, our current web standards have too many "positioning problems" such that they can't replace PDF's. PDF's are needed because end users (non-IT office workers) want WYSIWYG documents; they can't afford to go to CSS school.

What makes you certain any theoretical GUI markup standard would improve on the industry standard of Electron and Chromium wrapped web components? Just need to look at the utility and performance of vscode to see what is currently possible.

People who set out to invent "better GUI tools" always eventually realize it's no the specifics of the programming language used to build them that's hard. It's high level things like state management.

iOS doesn't even have a stable answer to React, yet. The problem isn't JS/CSS.

Why is state management a problem? Could you give a sample scenario? Have all screens be tied to an application session instead of managing page per page. A given screen stays put the entire session (although may be hidden or removed as needed). Its state would be hierarchically addressable & examinable, such as requesting "scopeA:screenB.panelC.widgetD.value". (Scoping clause optional.) I have some further suggestions for state and scope management that would take up too much space here.

The Oracle Forms client seemed to somehow pull it off. (It used a proprietary markup, not XML.) There are deficiencies with the Oracle Forms model, but it proved a browser-like GUI client approach can work. Companies loved Oracle Forms before Java ruined it. They weren't pretty, but cheap and practical to create and maintain. The Oracle Forms devs were 3x more productive than our MVC team and it took about 1/5 the code to do the same thing. Productivity died in CRUDville; we de-evolved. (Same for desktop VB & Delphi like tools, although they required per-PC reinstalls for app upgrades, unlike Oracle Forms.)

Reply on news.ycombinator.com