When XML Beats JSON: UI Layouts • Hacker News Board

Re: When XML Beats JSON: UI Layouts

#201

Post by teyc » Wed, Oct 30, 2019, 8:11 PM UTC

Implementations of layout in source code tend to suffer hard-to-diff from a source control point of view.

Everytime you move an existing component into a wrapper, the identation breaks how the diff shows up.

Perhaps we need a XML formatter that instead of pretty formats, sets the indentation to 0, when we commit code changes. However, that makes the source hard to read.

So instead of a diff that reads line

   - 
   -  foo
   - 
   + 
   +   
   +    foo
   +   
   +

We get

Another problem is with the end tags, it is difficult as in the previous example to tell which opening tag an end tag is for.

A pretty formatter could solve this problem too.

foo

Perhaps the level of indentation could be added visually too

foo

but then we bring back the problem of the ugly diffs, gah!

Re: When XML Beats JSON: UI Layouts

#202

Post by Pmop » Wed, Oct 30, 2019, 8:27 PM UTC

forgottenpass wrote: post #177

nodamage wrote: post #90

At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…

I think qt widgets (not-qml, it's different and I haven't used it) uses XML without many of those problems. Layouts are trees of widgets. Layouts are themselves widgets so repetition in the tree can be reduced. You use XML, C++, or both to define a widget. The UI Compiler will turn that XML into C++. That means further code reuse can leverage the C++ type system. All widgets are QWidgets, and MyProgressBar inherits f…

Qt is really good for doing UI, in my opinion, both QML and non-QML. They do a really good job at keeping things coherent and concise, which really helps first-time users, specially after learning the basics.

Re: When XML Beats JSON: UI Layouts

#203

Post by CuriousCosmic » Wed, Oct 30, 2019, 8:30 PM UTC

jcelerier wrote: post #190

nodamage wrote: post #90

At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…

> For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. I've done a bit of WPF and a fair amount of Qt Widgets, and never once did the actual XML content matter since it was mostly putting the control at a place that looks good in a UI designer. > Which leads to more bloat. I'd like to know your definition of "b…

Chiming with my prior experience: My problem with Qt's approach is that their editor is atrocious despite their XML schema for UI layout being excellent.

Qt's XML schema makes sense and very easily translates to the C++ it generates. If one wishes they can write the XML themself using just their knowledge of the Qt Property System, the Layout System, and the very basics of how the XML is laid out. If they want to just use a designer tool, that's fine too however Qt's UI designer makes life very difficult from the perspective of version control and actual usability.

The UI designer doesn't respect any Canonical form of the UI files. This means that each time you save the file it more or less jumbles the entire thing up based on however it decided to hold it in memory. This turns tiny changes (what should be maybe 2-3 lines of XML) into massive ones (100s to 1000s of lines of XML shuffled just enough to shake off any semblance of contiguous history in the VCS). Likewise, it adds arbitrary property data to items that 95/100 times are unintended (setting default geometry sizes based on the sizes of the UI elements in the demo window) or are simply meaningless (storing the default value as a user selected property despite the user requesting to use the default).

It doesn't help that the UI of the designer is finicky as hell (layouts) and adding custom UI components is a hassle via the editor while it is exceedingly easy in the XML.

It's a bunch of small things like that that have resulted in teams I've worked on in the past refusing or at least strongly discouraging the committing of changes made by UI designer into VCS. It's really a shame too since a good UI editor is a boon for development and Qt has a really nice UI library.

Re: When XML Beats JSON: UI Layouts

#204

Post by andrewflnr » Wed, Oct 30, 2019, 8:32 PM UTC

teyc wrote: post #201

Implementations of layout in source code tend to suffer hard-to-diff from a source control point of view. Everytime you move an existing component into a wrapper, the identation breaks how the diff shows up. Perhaps we need a XML formatter that instead of pretty formats, sets the indentation to 0, when we commit code changes. However, that makes the source hard to read. So instead of a diff that reads line - - foo -…

You can pass -b to git diff to get exactly your first result. I would lean toward editor tooling for the latter case, myself.

Re: When XML Beats JSON: UI Layouts

#205

Post by wry_discontent » Wed, Oct 30, 2019, 8:34 PM UTC

postalrat wrote: post #147

wry_discontent wrote: post #133

Earlier quoted context omitted.

Working with Clojurescript and Reagent (or Hiccup) has ruined JSX for me. It's so verbose and absurdly hard to work with relatively.

Why is JSX so much more verbose? The end tags?

It's primarily the end tags, yes, but there's also the className shorthand in reagent that's nice.

[div.btn.blue.p-4 {:disabled true} "Button Text"]

Re: When XML Beats JSON: UI Layouts

#206

Post by andrekandre » Wed, Oct 30, 2019, 8:36 PM UTC

cfv wrote: post #75

XML also has a LONG history of being used for UI in stuff like QT, which is great. The one problem I see is that as developers, we shouldn't give a rat's ass about the otuput format's readability when compared to the API ergonomics. If the API for describing the UI is good enough (Can I do stuff like "App.Transition(App.findOne(Sidebar), 500, {width:"1%"}, {width:"30%"}, Ease.EASE_IN_OUT)" or is it a 300loc tutorial?…

it isnt that important for me either, and imo shouldn’t be...BUT

when you are in a formal setting, people like to code review, and in that case, in the absence of some special diff tool, people will complain they can’t review your ui changes in github and suddenly your format matters alot more than before

Re: When XML Beats JSON: UI Layouts

#207

Post by yellowapple » Wed, Oct 30, 2019, 8:55 PM UTC

weberc2 wrote: post #143

ChrisSD wrote: post #71

Earlier quoted context omitted.

TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.

I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)

What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments).

That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions.

¹: https://man.openbsd.org/pf.conf

²: https://man.openbsd.org/smtpd.conf

³: https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5

⁴: https://otpcl.github.io

Re: When XML Beats JSON: UI Layouts

#208

Post by fnordsensei » Wed, Oct 30, 2019, 8:57 PM UTC

52-6F-62 wrote: post #111

sacado2 wrote: post #103

Earlier quoted context omitted.

Quite readable but it's a hell to parse. The first argument is the name of the element, but what is the second one? If it is a string or an array, it's the first child, but if it's an object, it's the attribute set?

Maybe something more like: [ "div", [ "The ", [ "a", { "href": "https://www.json.org/" }, [ "JSON format" ] ], " was invented by ", [ "em", "Douglas Crockford" ], "." ] ] With all children being encapsulated in an array... edit: though it again gets confusing when the 0 index is sometimes the element type and sometimes the straight text... so never mind I guess the problem persists.

That's is roughly how it's done in Reagent[1]/re-frame[2]:

  [:div "The" [:a {:href "https://www.json.org/"} "JSON format"]
   " was invented by " [:em "Douglas Crockford"] "."]

The fact that EDN[3] supports keywords makes it a bit easier to parse. Representing HTML in EDN this way was first done in a library called Hiccup[4], so it’s usually called “Hiccup” even when encountered outside of the original library.

1: https://holmsand.github.io/reagent/

2: https://github.com/Day8/re-frame

3: https://github.com/edn-format/edn

4: https://github.com/weavejester/hiccup

Re: When XML Beats JSON: UI Layouts

#209

Post by patsplat » Wed, Oct 30, 2019, 9:10 PM UTC

hyperman1 wrote: post #32

Interesting to see the history here: XML was created and solved a lot of problems. So on the bandwagon everybody jumps. Then it became bloated and fragmented, so the world switches mostly to JSON. But on the XML side, the baby was thrown out with the bath water, while JSON started developing its own abuses. TOML and YAML come in and muddy the waters a bit more. This is only 1 article, but maybe the world is ready to…

YAML predated / was concurrent with JSON. Both were in reaction to the bloat of XML.

Re: When XML Beats JSON: UI Layouts

#210

Post by dfox » Wed, Oct 30, 2019, 9:18 PM UTC

unlinked_dll wrote: post #186

falcolas wrote: post #137

Earlier quoted context omitted.

> The simplicity of JSON is an advantage: it prevents people from mucking it up with too much nonsense like this. JSONs simplicity was out the window before it became a formal spec. The original designer of JSON omitted comments from the final spec because people were using them to create processing directives. There are multiple differing implementations of JSON parsers, the most notable differences between them bei…

>EDIT: Oh, and instead of CDATA, we now simply base64 encode arbitrary objects and pack them into JSON encoded strings. Is this really an improvement? I think that's more of an indictment of HTTP than XML or JSON. Maybe we should have a better standard for exchanging non-textual data with websites.

CDATA still does not allow you to include even arbitrary sequences of unicode codepoints, not to mention arbitrary binary data.

On the other hand HTTP is in fact a binary protocol and there is perfectly good way to transport sets of binary objects with associated metadata: MIME multipart/whatever. With multipart/byteranges even being part of HTTP itself and multipart/form-data being one of the "core web technologies".