HN Explorer

Ask HN: Why has a GUI markup standard never taken off?

6 points by tabtab ↗ HN
Why is there no established GUI markup standard? If we had a standard "GUI browser", we could get desktop-like apps without having to bleep around with inconsistent JavaScript/CSS/DOM, etc., and without local installs. For "productivity" apps, users prefer GUI's, not web interfaces. You can fit more and do more on fewer screens.

The web/mobile focus distracted everyone, and the result is that the industry is missing a key standard. Amazon, IBM, Google, etc. could take away Microsoft's desktop advantage if they nurtured such. MS controls a big pie; come take some.

11 comments

[ 7.2 ms ] story [ 38.7 ms ] thread
PaulHoule
If you look at HTML 5, CSS, et al. and it is definitely becoming a GUI markup standard. That is, flexbox and grid layouts, progress bars, etc.

Note that people write advanced "Productivity" apps with web tech, such as Visual Studio Code. You can make web apps that look entirely like GUI apps.

Any other standard for GUIs would encounter the same problems. For instance it's clear that the font metrics are all messed up when you look at a plain install of a typical Linux distro. That means no way you can count on making an app where the text doesn't blow out of the bounds of where you're trying to fit it.

tabtab
While JavaScript-based kits can make GUI-like interfaces, they tend to be clunky and buggy after many years of trying. Newer browser versions or brands come along, and they break or act funny. There are too many layers and parts to the emulation. A single-purpose GUI-focused browser (and/or pluggin) is probably needed to do it right.

As far as font consistency, PDF's seem to mostly get it right such that text is in the same position and wrap in the same spot regardless of the viewing platform. We can swipe some ideas from them. A bounding box is one approach: you fully fit the given text into the box on both sides no matter what by adjusting the aspect ratio. Adjustments of a few percent are not going to stand out as odd.

The GUI browser would probably have to be vector coordinate-based, at least as an option. The "layout engine" could be on the server, which gives you more choices of layout engines, including the choice of "none". This would also simplify the GUI browser by pushing the layout to the server.

I'm not against the idea of including at least one layout engine on the client, but it opens a Pandora's box of complexity. Complexity is why web-based UI's suck rotting eggs to manage on multiple devices. It's easier to test when the server computes layout because it's then the same on a billion difference devices, unlike @&#% web browsers.

h2odragon
Because its a broad enough space, on the programmer and user sides, that there's not going to be One True Standard that works well enough for everybody.

Not everyone thinks the same way, and UI is close enough to "how the user thinks" that you've got to cater to the differences. Some people and situations need UI concepts that don't belong in the toolkit (dump ram to framebuffer for debugging by color); other users should have controls that have minimal effects and those controls wrapped in foam so they don't hurt themselves any more than necessary.

That breadth of "UI" is barely covered by the boiling chaos of interface ideas we're still watching evolve.

tabtab
Re: not going to be One True Standard that works well enough for everybody.

One could say that about anything, yet we have HTML, SQL, etc. as standards, despite their limits and imperfections.

Oracle Forms allowed a single client to handle multiple different applications. I don't know how it worked under the hood (it's proprietary), but it had characteristics of a "GUI browser" and at least got the job done. It shows one "GUI client" can serve multiple server-centric CRUD apps without local per-app installs. Focus on data-centric CRUD first. Things like word processors, flow-chart editors, and Photoshop clones can wait for a later stage or level. Walk before you run.

Some reference the X-Window system, but it's pixel-based, not vector, and has no input buffering feature, meaning every key-stroke has to make a round trip from client to server before it shows up on the screen. This was okay on LAN's, but questionable over HTTP.

maxharris
I'm working on a project to provide exactly this! It's a layout engine that takes a tree of components, emits boxes. Currently it's written in JavaScript and renders to canvas, but it also runs on node + node canvas, so you can do things like generating PDFs and other images server-side.

https://github.com/maxharris9/layout/tree/master/test/compon... https://github.com/maxharris9/jsx-layout

My friend is working on a native client that will run programs written for layout without a browser.

If you're interested in this, I'm open to DMs on twitter (@maxharris9)

photawe
Probably because there's no commercial interest in such a thing. Now, when you say "MS controls a big pie", I can tell you there are a lot of people really not satisfied with how MS handles things (myself included).

Hopefully, they (MS) will manage to keep their WinUI promise, and make it quite easy to develop (Windows) desktop apps.

As for platform-independence, there are a few attempts, but with just (a few) volunteers, it's hard to tackle such an insanely complicated issue.

tabtab
Re: I can tell you there are a lot of people really not satisfied with how MS handles things

Yes, they WANT competition for desktop/productivity app space to either motivate MS to do better, and/or provide alternatives. This will enable it.

Re: Hopefully, they (MS) will manage to keep their WinUI promise, and make it quite easy to develop (Windows) desktop apps.

Even if they did, one is pretty much stuck using MS's languages. Rather than write language-specific adopters, create a state-friendly GUI markup standard so any language that can read and write text and talk to the Internet can serve up GUI's.

Re: it's hard to tackle such an insanely complicated issue.

Base it off the Tk or QT kits rather than reinvent the GUI wheel.

photawe
I'm not familiar with Tk, and how well that works, but there are a lot of things a good GUI should do -- just think of databinding and such - it's very far from trivial to develop something that looks really good on all platforms, is easy to use, uses modern concepts (MVVM), and has decent language bindings (c#, c++, java)
tabtab
A lot of those issues would be "back end framework" issues if we had a decent GUI markup standard. Tk would just be a kit to build a GUI browser with, not the domain application itself. It would be roughly analogous to "WebKit" in HTML-land. When building a domain application, you don't normally set out to build a domain application "in" WebKit, you use HTML/HTTP/CSS/JS, which are then rendered via WebKit (at least partially). A web browser doesn't have to use WebKit.
unlinked_dll
I just think markup is a bad way to write UIs, or anything but documents imo/e. For anything above a toy you'll need to generate markup programatically, and congrats, you've invented the web browser.
tabtab
I'm not suggesting that one always write the UI in direct markup alone. Program-generated markup and/or an IDE (drag and drop) is perfectly possible. It's just the standard interface to a GUI browser. Once the standard catches on, "helper" tools will appear.

Re: congrats, you've invented the web browser.

Web browsers suck for GUI's. Positioning is a royal inconsistent pain (especially fonts); and they lack native widgets such as editable data grids, drop-down menus, tabs, combo-boxes, menu bars, dialog boxes, MDI, and more.