[tabtab]

What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose.

HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features. It's a matter of focus. The SGML browser's only job is to do GUI's right. But HTML browsers have 100's of jobs. If changes harm a few of those, they become roadkill.

But using JavaScript as the starting point of a SGML may be the only way to gain momentum. However, the end game should be using mostly markup to manage a GUI, not JavaScript.

Standard and common GUI idioms and behaviors should be done in a declarative fashion using such markup, such as having a button open (make visible) a given window. While some client scripting may be needed, most of the processing could and should be done at the server if the SGML browser does most of the UI grunt-work.

[orange8]

> What's really needed is a standard GUI markup language (SGML)

What's wrong with HTML? Isn't it already everywhere, including in all browsers?

> HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features.

HTML and JS are two different languages. One is a markup language, the other a scripting language. If changes to the markup language break a library in the scripting one, its clearly the library that needs fixing. Expecting browser makers to somehow keep their HTML engines backward compatible with JS libraries isn't really realistic or practical.

[tabtab]

Re: "What's wrong with HTML?"

It doesn't handle "state" well, and lacks common GUI idioms like menu bars, tool-bars, editable data grids, combo-boxes, model dialog boxes/windows, MDI, and others. Perhaps HTML can be modified to do those well, but it probably wouldn't be "HTML" anymore.

Re: "If changes to the markup language break a library in the scripting one, its clearly the library that needs fixing."

I'm comparing the emulation of desktop GUI's via HTML + DOM + CSS + JavaScript + JavaScript libraries to something that natively handles GUI's. Those 5 parts together have proven fragile. The chain is as strong as the weakest link.

Re: "Expecting browser makers to somehow keep their HTML engines backward compatible with JS libraries isn't really realistic or practical."

That's why we need a dedicated GUI markup language and browser (or pluggin). You would be very careful about breaking GUI's if GUI's are your tool's only job. HTML (current) browser makers have a lot of other concerns. Breaking a GUI emulator library is just collateral damage to them that makes them yawn.

Those who tried to do something somewhat similar failed because they put too much on their plate: Flash and Java Applets. They tried to be entire virtual OS's, making them a hacker haven. Lesson: don't be an application programming language, don't be a compiler, don't be an OS, don't be a code editor, don't be a toaster, just be a GUI browser and only a GUI browser.

[orange8]

> It doesn't handle "state" well

It is a markup language, just like the SGML you talked about. In-fact, it started out as a subset of SGML. If it could handle state, it would not be a markup language. The same applies for any desktop GUI that uses a custom markup language to declare a UI.

> via HTML + DOM + CSS + JavaScript + JavaScript libraries to something that natively handles GUI's. Those 5 parts together have proven fragile

They have proven so fragile, that the whole web, billions of pages handling all sorts of things from banking to social media run on top of them. Not to mention PWA mobile apps and cross-platform desktop apps like VS Code. And it is actually 4 parts, all platforms have libraries.

> That's why we need a dedicated GUI markup language and browser (or pluggin).

We already have one, maybe you just don't like it, don't understand it or its not cool/edgy enough for your tastes. It's called HTML.

[PretzelFisch]

I would just say HTML is a document markup, not an application ui. And you need css to make a none-document look nice.

[pjmlp]

That is what XHTML was supposed to become, but then people decided to misuse HTML and make it into HTML 5.

So now appreciate what HTML has turned into.

[azhenley]

I like your idea and Microsoft probably hoped for XAML to become that standard.

[thelazydogsback]

WPF was great to program in for the most part -- was able to write some really compelling and complex UI's in it, and UI programming isn't really my thing.

[pjmlp]

XAML kind of follows (in spirit) the ideas behind XHTML, and its related standards.

https://www.w3.org/standards/xml/components

[tabtab]

It's fairly close to what I have in mind, but it's also mostly static, I believe. It would need enhancements to handle interaction and UI updates better.

And I'm not sure about its cross-platform abilities, but I haven't tested the limits.

[WorldMaker]

> It's fairly close to what I have in mind, but it's also mostly static, I believe. It would need enhancements to handle interaction and UI updates better.

XAML Behaviors and Storyboards have been around since very early in XAML history. They aren't fun to write by hand, which is why originally they were a "Blend thing" focused for Designers mostly (and a lot of the XML namespaces still have "Blend" or "Expression" keywords in them) and the non-Designer Developer story for them has always lagged behind, which sometimes seems a shame because they can also be really powerful.

> And I'm not sure about its cross-platform abilities, but I haven't tested the limits.

There was the brief period where Silverlight was very cross-platform. Xamarin and Uno and Avalonia all seem healthy and to imply that XAML works well cross-platform.