When XML Beats JSON: UI Layouts

What UI framework using XML is there where you can end up making silly typos that won't be caught at compile time? Or basically any sort of typo? I would expect any decent XML UI framework is going to have some sort of validation schema defined which will be quite stringent as to what is allowed at a particular level. Not that I like XML Schema.

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

Code generally isn't declarative or hierarchical unless your language is those things as well. A declaratively defined interface in C# would end up being some like a bunch of strings or enums passed to some object constructors. At that point I'd rather a an XML implementation that can be verified and processed with tools.

"- 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 frequently write WPF code these days and don't find it any more verbose than attempting the same thing in C# statements. If anything, it's less verbose and it has the added benefit that it's all organized in the same group of files.

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

I don't know about Android, but in WPF, you just add a name attribute to your ui element and reference it by name.

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

Hasn't really been my experience. Syntax errors are caught by the editor typically and further errors do get caught at compile time for XAML at least. Some errors don't get caught, but these are the same errors that would get missed if I attempted the same thing in C# code.

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

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

> 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 "bloat".It's not like 100kb or 500kb of XML are going to translate into 100kb or 500kb executables or runtime memory use, since the XML is generally only used at compile time before translation into code.

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

well, Qt's main IDE marks the UI xml files as read-only so not much chance of that on that side.

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

... no, you will just refer directly to a variable that was generated in a precompilation pass - you can inherit from or compose the generated object depending on if you prefer to type `ui->myLabel.setText` or `this->myLabel.setText`.

> You essentially have to learn two different sets of APIs which do the same thing. vs button.setTitle("blah"). Why?

You don't if you just use the UI designer.