6 ms·
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
by NewLogic 6y ago
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.
- hombre_fatal 6y agoPeople 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.
- tabtab 6y agoWhy 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.)