
Ask HN: Why has a GUI markup standard never taken off? - tabtab
Why is there no established GUI markup standard? If we had a standard &quot;GUI browser&quot;, we could get desktop-like apps without having to bleep around with inconsistent JavaScript&#x2F;CSS&#x2F;DOM, etc., and without local installs. For &quot;productivity&quot; apps, users prefer GUI&#x27;s, not web interfaces. You can fit more and do more on fewer screens.<p>The web&#x2F;mobile focus distracted everyone, and the result is that the industry is missing a key standard. Amazon, IBM, Google, etc. could take away Microsoft&#x27;s desktop advantage if they nurtured such. MS controls a big pie; come take some.
======
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.

------
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.

------
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/layout/tree/master/test/components)
[https://github.com/maxharris9/jsx-layout](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.

