
When XML Beats JSON: UI Layouts - creolabs
https://engineering.instawork.com/when-xml-beats-json-ui-layouts-53c7f1d3fdb7
======
nodamage
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 more bloat.

\- Editing XML kind of sucks. You're more at risk of making silly typos that
won't be caught at compile time.

\- XML namespaces make an already verbose language even more verbose, not to
mention just generally confusing.

\- At some point you will need to access your user interface from your
application code. Which means you end up with silly stuff like findViewById()
to bridge the gap, adding even more boilerplate to your code.

\- You essentially have to learn two different sets of APIs which do the same
thing. _< Button title="blah"/> vs button.setTitle("blah")_. Why?

The only real strengths of XML are that 1) it's declarative, 2) it's
hierarchical, and 3) it's diffable. But code can be too, without all of these
other drawbacks.

Fortunately it seems like the industry is starting to figure this out with
things like SwiftUI and Jetpack Compose. I really think we're going to look
back in a few years and think it was ridiculous that we used to do this stuff
in XML.

~~~
SigmundA
Its funny WinForms was just code. The designer generated the code or you code
do it by hand.

You could read it and understand it because it was the same language you used.
If there was a problem you could debug it.

I never felt more productive than when my UI declaration was just code.

Inevitably you need to mix some logic in the layout language and then debug it
(For each render this thing, binding syntax etc.) now you have a weird
programming language that is hard to debug and remember syntax for, or you
could just use a normal programming language, maybe one that supports some
declarative constructs.

SwiftUI gives me hope, would like to see something similar show up for the
.Net World.

~~~
nobleach
The IDE wrote code and kinda hid it from you in a partial class. And every
once in awhile, one would have to get in there and muck around with the
generated code. This had the potential to break things pretty badly.

~~~
SigmundA
Normally didn't do much in the partial class other than reference it.

You could override what it was doing in the main class file though if needed
pretty easy. Again if it did break it was just aode and threw a normal
exception in the designer, usually revolved around something that didn't work
right in DesignMode so you had to check for that explicitly.

------
OskarS
You know, when XML looks like this, I don't mind it so much:

    
    
        <Employee name="Michael Scott" title="Regional Manager">
          <Employee name="Dwight Schrute" title="Ass. Regional Mgr" />
          <Employee name="Jim Halpert" title="Head of Sales">
            <Employee name="Andy Bernard" title="Sales Rep" />
            <Employee name="Phyllis Lapin" title="Sales Rep" />
          </Employee>
          <Employee name="Pam Beesly" title="Office Administrator" />
        </Employee>
    

The thing is, XML in the real world _never looks like this_. In the real
world, XML has an avalanche of obscure namespaces, weird "<![CDATA" things,
unreadable attributes, incomprehensible structure, and god knows what else.

The simplicity of JSON is an advantage: it prevents people from mucking it up
with too much nonsense like this. Of course, you CAN make unreadble JSON as
well, XML just makes it so much easier.

~~~
falcolas
> 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 being some allow comments while others treat them as
errors. There's also JPATH, JSON Schema, and JSON Transform.

JSON is the new XML. It has been and will continue to be abused to fit all the
possible corner-cases, at the expense of simplicity and readability. Just like
XML.

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?

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

~~~
dfox
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".

------
m1el
> JSON for lists, XML for trees No. JSON is a recursive data structure that
> can represent trees as well.

It's easy to make a concise representation of DOM trees as JSON:
[http://m1el.github.io/jsonht.htm](http://m1el.github.io/jsonht.htm)

I find it really sad that people don't know or consider s-expressions to
represent trees.

    
    
        (Department {:name "Scranton Branch"}
          (Employee {:name "Michael Scott" :title "Regional Manager"}
            (Department {:name "Sales"}
              (Employee {:name "Dwight Schrute" :title "Ass. Regional Mgr"})
              (Employee {:name "Jim Halpert" :title="Head of Sales"}
                (Employee {:name "Andy Bernard" :title="Sales Rep"})
                (Employee {:name "Phyllis Lapin" :title="Sales Rep"})))
            (Employee {:name "Pam Beesly" :title "Office Administrator")))

~~~
gambler
This reminds me of an old joke about binary XML:

    
    
       <byte> 
       <bit>1</bit> <bit>1</bit> <bit>0</bit> <bit>1</bit>
       <bit>0</bit> <bit>1</bit> <bit>1</bit> <bit>0</bit>
       </byte>
    

_> It's easy to make a concise representation of DOM trees as JSON:
[http://m1el.github.io/jsonht.htm](http://m1el.github.io/jsonht.htm) _

It is not concise. Here is an example of a single div tag overhead:

    
    
       ["div",{"class":"some classes"}, ... ]
    
       <div class="some classes"> ... </div>
    

Also, it does not represent DOM trees as JSON. It represents DOM trees as _S-
Exressions encoded via JSON_. The s-expression above can be written directly
as:

(div (class= "some classes") ... )

So why does it need to be wrapped in a format that's verbose, underspecified,
doesn't have comments, doesn't have namespaces and doesn't have any notion of
metadata?

~~~
m1el
> So why does it need to be wrapped in a format that's verbose,
> underspecified, doesn't have comments, doesn't have namespaces and doesn't
> have any notion of metadata?

Because the OP article doesn't even consider s-expressions, so I'm working
with the tools I was given.

Personally, I find it frustrating that EDN (or some other form of s-exprs)
aren't widely adopted.

------
sacado2
What XML is also very good at is: representing tagged text, what is called
"mixed content" in XML terminology.

Just try to write the JSON equivalent of:

    
    
        <div>The <a href="https://www.json.org/">JSON format</a> was invented by <em>Douglas Crockford</em>.</div>
    

If your document consists mainly in losely structured text with some
annotation, you better use XML.

~~~
Kuinox
So Jupyter Notebooks should be XML instead of JSON. Right ?

~~~
dnautics
Honestly, they should be _markdown_. This would also solve the versioning
problem.

~~~
wodenokoto
And where would you store the output?

R uses markdown + a separate file with the output cached and while the non-
rendered file is easier to version the whole thing is a lot more difficult to
handle.

------
hyperman1
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 discuss the
possibility that the pendulum swung too far?

~~~
falcolas
The moment we added JSON schema (not to mention JSON transforms) and started
to create a JSON version of XPath, we started down the same path that hurt
XML.

Throw in parsers that all act differently (some parse comments, some don’t),
and processing directives, and it becomes clear that yes, the pendulum has
swung too far.

~~~
com2kid
> The moment we added JSON schema

There is an amazing JSON schema syntax out there, 100% better than the
official one. It is called TypeScript, and I am sad that the TS compiler can't
be made to pop out JSON validators (their philosophy being nothing at all
runtime).

There is a project (I forget its name) that will insert itself into your build
steps and use TS type definitions to validate JSON.

Seriously the TS syntax is _great_ , why is anything else being used to write
a schema?

The only thing I'd add to the TS syntax is the proposals to add field
validation using regexs, or some type of field name validation format. There
are times when TS can't model my JS objects, e.g. I have a bunch of GUID field
names that map to objects of a certain type, and I have some other field names
that are 100% not GUIDs, I promise, mapping to some other stuff.

------
mettamage
XML is so awesome for UI layouts. I had a thesis that I worked on that was
basically a subset of HTML (check the SMIL specification for something
similar, albeit a bit more complicated, SMIL used to be a W3C recommendation).

It was so easy to understand that every person who was able to use a computer
would pick it up quickly. This was not the case for HTML, my guess is because
there are a ton of HTML tags and that can be overwhelming for a certain type
of audience, whereas here there are at most 10 tags to learn.

The framework I'm talking about still exist, it's called XIMPEL [1] (sadly
SMIL kind of died). It may seem like a weird thing, but IMO it's the only
open-source framework that has an intuitive way to make non-linear
storytelling easy on the web easy. People can kind of hack a choose your own
adventure media story with YouTube, but XIMPEL really is so much better at it
because it's actually made for that purpose. And the biggest reason why XIMPEL
is simpel because it uses XML as its template language.

People just see the tags as lego blocks and build non-linear media essays,
stories or even small (media-focused) games with it.

[1] [http://www.ximpel.net/](http://www.ximpel.net/)

~~~
tenaciousDaniel
As someone who has only used html (as in, no other xml-based UI), I'm really
curious why it's necessary to even define the tags at all.

Why not allow authors to define their own names? Like

    
    
      <SomeWrapper>
        <SomeChild />
      </SomeWrapper>
    

Then internal functionality can be attached to each element via attributes,
like how aria roles work.

~~~
nidificate
This already exists. They are called custom elements.

[https://html.spec.whatwg.org/multipage/custom-
elements.html#...](https://html.spec.whatwg.org/multipage/custom-
elements.html#custom-elements)

[https://github.com/w3c/webcomponents/](https://github.com/w3c/webcomponents/)

[https://developer.mozilla.org/en-
US/docs/Web/Web_Components/...](https://developer.mozilla.org/en-
US/docs/Web/Web_Components/Using_custom_elements)

~~~
tenaciousDaniel
Yep, to some degree. Though what I would _love_ in an xml-based UI description
language is the ability to opt into default system behaviors, while
maintaining the ability to use whatever semantic naming convention that fits
my application.

I wrote this code in another comment, but imagine if you could _hook_
functionality to an element via defined attributes. With custom elements, you
have to add the functionality via a script, and they aren't system functions
(from what I can remember, I may be wrong).

    
    
      <LabelList list>
        <LabelItem label listItem>
        </LabelItem>
      </LabelList>
    

In the above code:

\- the LabelList element hooks into the systems "list" behavior

\- the LabelItem element hooks into the systems "label" behavior

\- the LabelItem element hooks into the systems "listItem" behavior

~~~
warp
Maybe the is="" attribute gets you partway there?

    
    
        <ul is="label-list">
            <li is="list-item">foo</li>
        </ul>
    

EDIT: google's documentation:
[https://developers.google.com/web/fundamentals/web-
component...](https://developers.google.com/web/fundamentals/web-
components/customelements#extendhtml)

------
jrochkind1
I don't disagree that JSON is better than XML for their "list" example,and
that XML is better than JSON for their "UI layout" example. BUT:

> This means there’s no officially supported way to represent the list of
> movies in an element attribute. We can hack this by encoding the list into
> an attribute using a comma delimiter:
    
    
          <Users>
             <User
              first="Michael"
              last="Scott"
              favoriteMovies="Diehard, Threat Level Midnight" />
            
    

So, that's because you're doing it wrong. XML has NO PROBLEM with hieararchy,
REALLY. Of COURSE there's a supported way to encode hieararchy.

    
    
          <Users>
            <User>
              <first>Michael</first>
              <last>Scott</last>
              <favoriteMovies>
                <title>Diehard</title>
                <title>Threat Level Midnight</title>
              </favoriteMovies>
            </User>

~~~
shawabawa3
You should have read the next paragraph. They do use that as an example

    
    
        <Users>
          <User>
            <FirstName>Michael</FirstName>
            <LastName>Scott</LastName>
            <FavoriteMovies>
              <Movie>Diehard</Movie>
              <Movie>Threat Level Midnight</Movie>
            </FavoriteMovies>
          </User>

~~~
jrochkind1
Fair! Why the heck did the author first try to tell us XML had no "officially
supported way" to do this then?

~~~
Slartie
Because it was about encoding a list of things in an _attribute_. Attribute!
Using nested elements is not exactly a solution for that requirement.

------
tobr
If XML is better at representing trees, and JSON is a tree, does that mean
that XML is better at representing JSON than JSON?

~~~
lucideer
Yes.

Consider a comparison of examples using JSON schema:

    
    
      {
        "$schema": "http://json-schema.org/draft-04/schema#",
        "description": "Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'",
        "definitions": {
            "schemaArray": {
                "type": "array",
                "minItems": 1,
                "items": { "$ref": "#" }
            }
        }
      ...
    
    
      <schema schema="http://json-schema.org/draft-04/schema#">
        <description>Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'</description>
        <definitions>
            <schemaArray>
                <type>array</type>
                <minItems>1</minItem>
                <items ref="#" />
            </schemaArray>
      ...
    

_$schema_ and _$ref_ are differentiated by convention in JSON, and require
repeated consideration in every parsing scenario to treat them as exceptions
relative to actual values within the JSON document. In the XML representation,
the distinction is implicit and handled automatically for you by every parser.

~~~
pytester
>$schema and $ref are differentiated by convention in JSON, and require
repeated consideration in every parsing scenario to treat them as exceptions
relative to actual values within the JSON document.

This is a _good_ thing. The main issue with XML is how ridiculously
overcomplicated and overengineered its design was. This isn't just a matter of
usability, it has security implications because it increases the attack
surface of anything that uses it (e.g. the XML billion laughs attack).

~~~
lucideer
> _This is a good thing. The main issue with XML is how ridiculously
> overcomplicated and overengineered its design was._

Citing element attributes as an example of such complexity is hardly
reasonable. The JSON example above contains the same complexity, just moved to
the application/implementation space, instead of the parser (so your app is
more complex to handle it).

> _e.g. the XML billion laughs attack_

Also not a great example. This is a simple DOS attack, of which there are many
other examples: zip bombs, yaml bombs, etc. None of these invalidate yaml nor
zip themselves.

There are also far worse attacks on XML than the billion laughs attack (XXE
attacks are an entire category in the OWASP top 10).

What these attacks have in common is that they use references. They aren't
unique to XML because any format wanting to handle references (like JSON
schema!) will have to account for them.

The difference is, since references aren't built into the JSON spec, you have
to do it yourself (and protect against attack like this in your own code).
Since XML handles this at spec. level, common XML parsers can account for &
mitigate for this for you (which fyi, modern ones do).

\---

Side note (and a vote in favour of JSON):

By your own metric, JSON is actually "more complex" (in a good way) than XML
in one area: value types. XML values are strings. Having value types is one
massive advantage of JSON imo.

In that sense, it would be nice to see a language that combines both of these
"complexities", to form something better.

~~~
Mikhail_Edoshin
I would disagree about having more value types. JSON has more syntax for value
types, but it only has four: string, integer, float, and boolean. XML has less
syntax for value types (everything is serialized as a string), but it has a
way to define types of attributes with XML Schema and there you get much more
primitive types already (decimal, date & time, binary). XML approach is more
uniform: it uses schema to look up all the parsing rules. JSON uses syntax for
some types and (ad-hoc) schema-like logic for others.

------
superqd
I stopped reading at the example describing how to provide an org chart
relation as XML. The argument here failed for me, and made the notion of what
is "clean" code or "clean" structure even more subjective than ever.

The JSON version of the employee org chart is much more semantic and human
understandable (to me) as it "cleanly" describes the relationship for reports
as a property called "reports" (for those who manage people - they have that
property).

But the org chart as XML was anything but obvious to my human eyes, as it was
just nested employee elements and at first glance, looked like a single list
of employees. Visually interpreting it to know who's a manager, and who
reports to whom seems far more difficult in the XML.

But, again, it's in the eyes of the beholder, and one person's clean solution
is another person's confusing tangle of brackets.

~~~
kgwxd
They both looked fine to me but human readability shouldn't be the primary
goal of a data format. I think the example is bad for both formats because it
conflates tree data structures and logical hierarchy. The memory model of the
application consuming the data would likely look like that, but that doesn't
mean that's how it should be stored/transmitted, that should be probably be
flattened, with each employee having a "manager" property.

~~~
superqd
Yeah, that is a good point. It does seem to come up a lot in regards to data
formats, that of how human readable they are. So I don't think it's without
value, but shouldn't be what they are optimized for since it's usually
software doing the reading most of the time, and not human eyes.

------
tambourine_man
Who would've thunk that different tools excel at different tasks?

We need more articles like this, to remember us that we should consider what's
best for the task at hand and not what's trendy.

~~~
beatgammit
Yup, use object notation for passing around objects, use a markup language for
markup. It's almost like reading the names gives a hint as to what it was
designed for and probably best at.

My sniff test is that if you're editing it by hand, JSON is a poor format
because you'll want the benefit of a schema or at least a user-friendly
format. If you're not, the syntax doesn't really matter so we should evaluate
it on technical merits (verbosity, computational complexity for
serialization/deserialization, memory footprint, etc).

I use:

\- config file formats for config files (usually TOML or INI format) \- data
formats for data (JSON, protocol buffers, etc) \- markup formats (Markdown,
XML/HTML) or code for markup

I really don't get why people try to force all use cases onto the same format.
Use whatever is well suited for the task, preferring familiarity over
unnecessary technical benefits.

------
cfv
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?) then the storage format at the
end of the day is not THAT important, at least for me, a guy who does a lot of
GUI work every day.

~~~
andrekandre
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

------
taude
Good thing we've had XML defining layouts for many years, despite many of the
technologies that used the pattern being dead. XML as a layout definition vs
XML as data were topics devs discussed heavily 15 years ago, too. So many Java
frameworks used Xml to describe the user interfaces (like JavaServer Faces,
early Tapestry, etc.). At one time, I worked with a lot was Adobe Flex which
used MXML to define user interfaces [1], don't forget about Microsoft's XAML.

It's actually amazing to me how many of Flex's great ideas live on in other
frameworks not dependent on the Flash Player, and looking at some modern day
React often reminds me if it.

[1] [http://flex.apache.org/doc-getstarted.html](http://flex.apache.org/doc-
getstarted.html)

------
sparsely
Good article, but for some reason he doesn't mention one the best XML UI
systems: WPF.

~~~
robbya
WPF is Windows Presentation Foundation.

[https://docs.microsoft.com/en-us/visualstudio/xaml-
tools/des...](https://docs.microsoft.com/en-us/visualstudio/xaml-
tools/designing-xaml-in-visual-studio?view=vs-2019)

------
wil421
Having worked with SOAP/XML extensively at my past job I can say for web
services I much prefer REST/JSON. JSON is much easier to work with and key
value pairs make it much easier to get what you need. Parsing an XML tree can
become a nightmare very quickly.

> However, we’ve created another problem in the form of inconsistency: some
> user properties are represented as element attributes, others as child
> elements.

Exactly. I’ve seen XML with element attributes and child elements all over the
pace. No rhyme or reason for any of it. It’s especially bad in older systems.

I pushed hard at my last job for the SOA team to build REST/JSON web services.
Oracle sold them a product to bridge the gap and they got End Of Life
announcements 6 months later! Glad I’m gone.

~~~
hagreet
1\. Why is parsing a tree which is encoded in JSON easier? 2\. Why does it
matter if an element is in an attribute or in child elements. You need some
kind of schema anyway, right?

~~~
wil421
It depends on the API of the system. I’ve worked on middleware that would not
be able to get an attribute, it lacked the capability. Other systems used
JavaScript and it was much easier with JSON

See this link on stack exchange[1].

[1] [https://stackoverflow.com/questions/17604071/parse-xml-
using...](https://stackoverflow.com/questions/17604071/parse-xml-using-
javascript)

> //Gets Street name
> xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue;

I’d much prefer something like jsonObj.address[0].street;. Personally I like
to work with objects over parsing documents trees.

------
marcosscriven
One thing I really miss when working on JSON vs XML data are comments. A
workaround is to make the comment a valid string in the data, but still not as
good as having the ability to comment an arbitrary line.

~~~
moron4hire
XML has comments. They are the same as HTML comments. <!-- comment goes here
-->

~~~
marcosscriven
That was indeed my point - whereas one can't in JSON.

~~~
moron4hire
I must have read your post three times and still thought you said " _and_
XML". I'm sorry.

------
ChrisMarshallNY
The main reason that I use XML (occasionally) is because of XML Schema. It's a
very precise data description that can be semantically verified.

Otherwise, I try to use JSON, where possible, because I am not a masochist.

~~~
laggan
I actually found JSON Schema to be FAR FAR FAR easier to use than XML Schema.

[https://json-schema.org/](https://json-schema.org/)

~~~
ChrisMarshallNY
You are correct.

I LOATHE XML Schema. I have used it for years, and have never memorized it. I
still need to look it up like a n00b, every time I use it.

But the simple fact of the matter is, is that so many people and projects have
inculcated it into hundreds (if not thousands) of toolsets and specs (Like
-Ick- WSDL), that it really is the only viable game.

People tend to like JSON precisely because it eschews the kind of overhead
that is the definition of XML Schema.

------
red_admiral
I've seen a lot of XML vs. JSON discussion that misses the point why
developers like me love JSON so much, at least until things get really big, or
you want to add another 9 to your reliability [1].

JSON is so easy to get started with. Some of this is precisely because of the
lack of schema.

In Java with the GSON library, encoding/decoding is one function call and for
the things I've been doing this just works at least 90% of the time. I've
managed to add a JSON option to several endpoints in an application in
something like 1-2 hours, including writing tests.

Back when I did Java as a full-time job and we were working with XML a lot,
there were whole proccesses and workflows and validations and annotations to
get the thing working properly. I think you also had to add a few extra stages
to the maven compile process back then to get the schemas and all properly set
up and loaded. It's not so much a fault of XML as a format, as of the whole
"enterprise" tooling that we were asked to use around it. I really hope that
this has got easier now.

It's almost as if the XML library people were thinking in the waterfall model
where you specify everything up front, and the GSON people were thinking in
the agile model.

[1]
[https://rachelbythebay.com/w/2019/07/21/reliability/](https://rachelbythebay.com/w/2019/07/21/reliability/)

~~~
Rebelgecko
Using GSON is great if you're encoding/decoding straightforward data
structures. However if you're using it for serialization for more complicated
objects (especially with polymorphism!) it gets zany really quickly.

------
tasogare
The ability to extend an existing element with attributes is super useful in
XML. To do an equivalent in JSON is quite ugly.

------
adamstep
Author here. The meta-point of my post is that different formats have their
advantages and disadvantages, and it's good to understand those when deciding
on what's appropriate for a given use case. So I'm glad to see a discussion
weighing the pros and cons in the thread!

I see some comments saying that JSON can represent trees just as well as XML,
which is technically true. However, XML natively supports a distinction
between node metadata (via properties) and relationships (via child elements)
that has to be implied in JSON. For pure-data, this may not matter . But in
cases like UI layouts, it's helpful to have the format distinguish between
node properties and child components. As others have mentioned, the document
use case is also a natural fit for XML by clearly separating the content from
markup.

------
castwide
I'd expand on his premise by saying that XML beats JSON for structured
documents, which also happens to be a practical way to represent a UI layout.

------
bullen
Seems XML is having a revival on HN so I'll just repost my XML editor:

I would love to know what people think of my XML node-graph/tree editor I made
before JSON became mainstream (my excuse):
[http://rupy.se/logic.jar](http://rupy.se/logic.jar)

\- You link/unlink nodes (I called them entities! Xo) by right-click-dragging
between them.

\- You copy stuff by right-click-dragging to an empty space.

\- You delete by grabbing something by left-click-holding and pressing the
delete key.

\- Oh, and nodes are completely tree structure expandable, just drag-drop
attributes on nodes and nodes inside nodes.

(I know, not super intuitive; but very handy once you know about these.)

The editor uses lightweight rendering so you can have a ton of elements with
good performance.

------
onion2k
No one should really be writing UI code by modifying a file by hand because
UIs are often complex and deep, so the file structure used to store the UI
data doesn't need to be human-readable.

This is true for any data - once you hit a moderate level of complexity
_neither_ JSON or XML really work - you need to build a tool to manipulate the
underlying data rather than changing it directly. If you do that then it
doesn't matter how readable or 'ugly' the data is because a human being
shouldn't need to access it directly. This leads to other benefits you can
optimize for like size or parsing speed or redundancy instead.

~~~
kreco
Following what you say we should only have binary format.

I think you underestimate the convenience of a text format.

It does not only provide a simple way to generate it, but also provide a way
to modify it _by hand_.

~~~
yoz-y
And have readable and understandable diffs!

One of the biggest issues with the most popular 'tool-only language' (Excel)
is that there is no reasonable way to audit changes. Same goes for UIs that
are backed by inscrutable file formats.

~~~
DagAgren
Readable and understandable diffs is not a property of text files. It is very
easy to design tools and formats that use text files, yet do not give you
diffs that are readable or understandable.

Readability and understandability depend on more strict requirements that a
text file format may or may not have. Many do, but far from all do.

For instance, JSON files do not have requirements on the ordering of keys.
When making a small change to a JSON file, it is entirely legal to reorder
every single key, completely destroying the diff, and an automatic tool may
very well do this.

And as a counter-example, we could easily use a binary representation of JSON
data, but use a diffing tool that normalises key ordering to provide diffs
that are _more_ readable and understandable than a text diff of a JSON file,
even without malicious reordering of lines.

~~~
gpderetta
But this means you need diff tools, version control systems and editors (edit:
and merge tools) for every single format, which while nice in theory (hey
plugins!), in practice doesn't work well. Text is nice because it sort of a
minimum common denominator.

Of course semantic diffs would be nice; even, or especially, for code for
example but while they do exist they haven't seen much uptake because they do
not integrate well with existing tooling.

------
dukoid
Another reason why XML might be better for UI Layouts (in addition to typed
nodes) is that it allows mixed content, making it more concise in the case
where marked up text is included.

------
thequailman
While not really JSON, HyperScript[1] is much easier to grok than XML to me.
It allows you to define layouts really naturally using standard JS objects.
Mithril[2] specifically implements it really well.

1 -
[https://github.com/hyperhype/hyperscript](https://github.com/hyperhype/hyperscript)

2 - [https://mithril.js.org/index.html#dom-
elements](https://mithril.js.org/index.html#dom-elements)

------
dangerface
> XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.

Who says this? XML is a great general markup language that every one all ready
knows, it's a perfectly valid choice for most things, please use it.

Just don't make yet another bloated outdated markup language like YAML, any
"optimisations" turn out to be opinion that doesn't justify the time spent
learning a new language.

Do you really want to be known as the guy that made YAML? No you don't.

------
whereareyouwow
Reminds me of jasonette ([https://jasonette.com/](https://jasonette.com/)) ...

Whether it is JSON or XML, what I particularly like about both approaches is
that both are fundamentally HATEOAS
([https://en.wikipedia.org/wiki/HATEOAS](https://en.wikipedia.org/wiki/HATEOAS))

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

    
    
       - <panel>
       -  <textblock>foo</textblock>
       - </panel>
       + <vpanel>
       +   <panel>
       +    <textblock>foo</textblock>
       +   </panel>
       + </vpanel>
    

We get

    
    
       + <vpanel>
         <panel>
         <textblock>foo</textblock>
         </panel>
       + </vpanel>
       

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.

    
    
        <vpanel id="vertical-wrapper">
        <panel id="heading">
        <textblock>foo</textblock>
        </panel><!-- heading -->
        </vpanel><!-- vertical-wrapper -->
    

Perhaps the level of indentation could be added visually too

    
    
        <vpanel id="vertical-wrapper">   <!-- vertical-wrapper  -->
        <panel id="heading">             <!--   heading         -->
        <textblock>foo</textblock>       <!--     textblock     -->
        </panel>                         <!--                   -->
        </vpanel>                        <!--                   -->
    

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

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

------
mattsanders
This is just a simple case of serialization. Having worked on 10+ game engines
and other scene graph based applications I would prefer a more flexible
reference based approach.

Instead of hard coding your hierarchy into the structure of XML or JSON.
Define some basic type information (unique id and node type).

If you have situations where an object can be referenced before it is defined
simply make a proxy loading type that listens for it to load.

After that it is a cakewalk:

[

{

    
    
      id: "UUID OR Rolling Number Per File OR DB Index OR ...",
    
      type: "business",
    
      name: "Dunder Mifflin Paper Company, Inc."
    
      description: "look at me I can be a root type for the graph OR one of many!"
    
      offices: [
    
       list of ids of objects of type "office" or object that wraps this with other metadata (relation object)
    
      ]
    
     },
    
     ... potentially other business entries,
    
     {
      id: see above...
      type: "office",
      name: "Scranton Branch",
      description: "This can describe each branch"
      departments: [
       list of ids of objects of type "department" or object that wraps this with other metadata
      ]
     },
     ... other offices,
     {
      id: see above...,
      type: "department",
      name: "sales",
      members: [
       list of ids of objects of type "employee" or object that wraps this with other metadata
      ]
     },
     ... other departments,
     {
      id: see above...,
      type: "employee",
      title: "manager",
      name: "Michael Scott",
      reports: [
       list of ids of objects of type "employee" or object that wraps this with other metadata
      ]
     },
     {
      id: see above...,
      type: "employee",
      title: "sales man",
      name: "Dwight Schrute",
      reports: [
       id of self since Dwight needs someone he can trust,
       {
        id: see above...,
        type: "report_meta",
        reportee: id of Pam,
        visibility: "secret"
       }
      ]
     },
     ... other employees,
     etc.,
     etc.
    ]

------
usrusr
The JSON examples are not even valid, the "$reports" properties on department
are written as comma separated lists without enclosing array brackets.

I guess XML might be perfect for when you can't decide between singular and
plural and want to leave the problem to others...

Because that's the biggest problem besides charset encoding that JSON helps
solving: in JSON, you can be unmistakably clear that a given property is to be
interpreted as a list of values, even when the current number is less than
two. In XML you can just vaguely communicate that intent with an intermediary
"plural element" unless you go full schema.

    
    
      <A><Bs><B/><Bs/><A/>
    

isn't half as clear as

    
    
      {"bs":[{}]}
    

(attributes unrelated to this difference omitted)

------
bcheung
If you are going to make the case for one being better than the other then
show the same data in 2 different formats side by side.

The article only shows 1 example in 1 format and then moves onto another
point.

The reader is left to imagine what the difference is in their head.

------
swsieber
I really like the idea of a constrained language for UI declarations, like the
angularJS/vue templates and XML instead of UI in code. It makes generating
test code for the UIs tractable.

Here's my take on what's possible for generating support code for UI tests
when the UI is written in a declarative, easily-parseable language:
[https://samsieber.tech/posts/2019/06/type-
safe-e2e-testing-d...](https://samsieber.tech/posts/2019/06/type-
safe-e2e-testing-dsls-in-kotlin/)

------
chadlavi
JSON is a data structure. XML is a text markup. Don't mix them up.

~~~
thesuperbigfrog
XML is also a transform specification with XSLT
([https://en.wikipedia.org/wiki/XSLT](https://en.wikipedia.org/wiki/XSLT)).

XML is also a query language with XQuery
([https://en.wikipedia.org/wiki/XQuery](https://en.wikipedia.org/wiki/XQuery)).

XML is also a nested structure path specifier with XPath
([https://en.wikipedia.org/wiki/XPath](https://en.wikipedia.org/wiki/XPath)).

XML is also a file format with SVG
([https://en.wikipedia.org/wiki/Scalable_Vector_Graphics](https://en.wikipedia.org/wiki/Scalable_Vector_Graphics)),
OpenOffice XML
([https://en.wikipedia.org/wiki/OpenOffice.org_XML](https://en.wikipedia.org/wiki/OpenOffice.org_XML)),
OpenDocument
([https://en.wikipedia.org/wiki/OpenDocument](https://en.wikipedia.org/wiki/OpenDocument)),
ePUB
([https://en.wikipedia.org/wiki/EPUB](https://en.wikipedia.org/wiki/EPUB)),
DocBook
([https://en.wikipedia.org/wiki/DocBook](https://en.wikipedia.org/wiki/DocBook)),
and many others
([https://en.wikipedia.org/wiki/List_of_XML_markup_languages](https://en.wikipedia.org/wiki/List_of_XML_markup_languages)).

XML is also an data/object serialization format with libraries like Jackson
([https://github.com/FasterXML/jackson](https://github.com/FasterXML/jackson)),
YAXLib
([https://github.com/sinairv/YAXLib](https://github.com/sinairv/YAXLib)),
Boost
([https://www.boost.org/doc/libs/1_38_0/libs/serialization/exa...](https://www.boost.org/doc/libs/1_38_0/libs/serialization/example/demo_xml.cpp)),
Pyxser ([https://github.com/dmw/pyxser](https://github.com/dmw/pyxser)), and
many others.

XML may not be as elegant as JSON, but it has a wide variety of uses and wide
adoption across many programming languages (libraries), and disciplines.

------
adamlett
I have yet to read anything that convinces me that XML is good for _anything_.
Just because XML in certain cases is less bad than some other cherry-picked
technology, doesn't mean that there aren't other better options.

See also Erik Naggum's legendary rant:
[https://www.schnada.de/grapt/eriknaggum-
xmlrant.html](https://www.schnada.de/grapt/eriknaggum-xmlrant.html)

~~~
sacado2
Well, for instance, let's take the HTML code of your comment (which happens to
be a valid XML document):

    
    
        <span class="commtext c00">I have yet to read anything that convinces me that XML is good for <i>anything</i>. Just because XML in certain cases is less bad than some other cherry-picked technology, doesn&#x27;t mean that there aren&#x27;t other better options.<p>See also  Erik Naggum&#x27;s legendary rant: <a href="https:&#x2F;&#x2F;www.schnada.de&#x2F;grapt&#x2F;eriknaggum-xmlrant.html" rel="nofollow">https:&#x2F;&#x2F;www.schnada.de&#x2F;grapt&#x2F;eriknaggum-xmlrant.html</a></span>
    

What would be the JSON/YAML/TOML equivalent?

~~~
adamlett
In order for me to answer that, you must be more specific about the _purpose_
of the representation.

For the purpose of authoring comments on Hacker News (HN), I for one am
grateful= that HN doesn't make us type out HTML. I also doubt very much that
HN stores our comments in a different representation (e.g. HTML) than the one
they were authored in.

~~~
sacado2
That's a very good point. Thing is, markdown (or a subset of it, as on HN) is
very limited. Great for short comments, bad when you want to do something a
little more complex, like a blog post (I _always_ end up addding some HTML
here and there in my markdown blog posts, when I want to include a video for
instance).

The other problem is that HN comments and all those markdown-like formats are
very _ad hoc_. If I copy/paste my reddit comments on HN, or the other way
around, it won't always work as expected. In both cases, it has to be
translated to HTML to be displayed by the browser, too.

So, the context would be: an export format for complex, multi-paragraphs
textual documents with meta-information.

~~~
adamlett
_So, the context would be: an export format for complex, multi-paragraphs
textual documents with meta-information._

If you add the condition that it be human-readable, I admit I am not able to
point to an existing format that is obviously better suited for this than XML.

------
ivankolev
Android UI is xml based and it works relatively well there

------
zmix
From their documentation:

> HXML does not use CSS.

I wonder why? XML is perfectly stylable with CSS. Why not let the user reuse
their knowledge?

Somewhat canoncial: [https://www.w3.org/Style/styling-
XML.en.html](https://www.w3.org/Style/styling-XML.en.html)

Also: [https://duckduckgo.com/?q=xml+css](https://duckduckgo.com/?q=xml+css)

------
nitwit005
If it's purely a choice between XML and JSON, I'd agree that XML is a bit
better. I'd prefer to use neither.

Most of these UI layout formats are essentially complex domain specific
languages, paired with IDE support. I don't see any particular need to base
them on XML, which was intended for marking up documents.

------
michaelmior
The XML example seemed odd to me as written. In the JSON case, yes there was a
prefixed key "$reports", but it told me what the relationship was. Looking at
the XML, what does it mean for an Employee to be nested inside another
Employee?

~~~
jimktrains2
Sounds like the list of employees should have been nested in a <reports> and
not left directly inside the employee.

------
lbruder
Where Tk beats everything else. "pack" and "grid" are still way ahead of the
established layout stuff. And Tcl is the perfect language for Tk. Sadly people
are put off by its seemingly strange syntax and semantics...

------
imvetri
This doesn't seem to solve any problem related to UI. Because tree can be
converted to a list and vice versa. The added advantage is tree structure is
natural.

But the way article is put forward is as if using json we cannot achieve tree
structure

------
julius_set
All this talk about representing UI elements in either JSON, XML and / or code
but what it’s state? How the hell is neatly encapsulated next to the UI in XML
and JSON. Dynamic URLs? Dynamic Ids, dynamic image urls?

------
crooked-v
XML is old hat. We should obviously be defining configurations using JSX now.

------
mwkaufma
XML vs JSON (vs code) devolves into bike-shedding because it positions the
discussion in the wrong place. Developing layout in plaintext, rather than a
WYSIWYG editor, is a priori impedance-mismatched.

------
underwater
I find JSON better for random lookups, and XML good for sequential reads. UI
falls into the later basket: start at the root, read the children, etc, etc.

------
commandlinefan
XML also supports id references, which are built into the parser - to my
knowledge, there's no JSON equivalent (nor, do I think, could there be).

------
wiso
No mention of XAML.

------
dandare
I am not familiar with Xcode: is there an easy way to get the exploded 3D view
of DOM in a browser? Maybe a browser extension?

~~~
nkrisc
Firefox used to do this, but looks like they haven't for a while. Guess it's
been longer than I thought since I used it.

[https://developer.mozilla.org/en-
US/docs/Tools/3D_View](https://developer.mozilla.org/en-US/docs/Tools/3D_View)

------
gagan2020
Yes, XML flavor beats JSON in UI layouts. We call that flavor HTML.

------
neves
Everybody knows that Yaml is the one true file format!

------
zeptoon
XML in most cases is a pain in the ass to deal with relative to JSON and it
isn't new or the rage anymore. A lot of hot technologies initially have this
in common. They're so cool and flashy and new that everyone's willing to
overlook the actual mechanics of working with them -- for a while. JSON is
just more convenient to work with 90-95% of the time, so everyone ends up
preferring it and so it tends to win out.

------
unilynx
One thing that's contrary to how XML is historically used but helps a lot.. do
not use child elements where an attribute suffices:

eg, don't do this, from the article:

    
    
      <Users>
        <User>
          <FirstName>Michael</FirstName>
          <LastName>Scott</LastName>
          <FavoriteMovies>
            <Movie>Diehard</Movie>
            <Movie>Threat Level Midnight</Movie>
          </FavoriteMovies>
        </User>
        ...
      </Users>
    
    

but write it like this

    
    
      <Users>
        <User FirstName="Michael" LastName="Scott">
          <FavoriteMovies>
            <Movie Title="Diehard" />
            <Movie Title="Threat Level Midnight" />
          </FavoriteMovies>
        </User>
        ...
      </Users>  
    

Much easier to query for a specific element (eg, try to XPath or CSS Selector
query for all of Michael Scott's favourite movies with the first syntax), and
the schema is a lot easier to write and reason about

(I don't have to wonder if multiple LastNames might be allowed, if I can set a
xml:lang attribute on any of them, if the ordering of FirstName and Lastname
elements is constrained, etc etc)

