When XML Beats JSON: UI Layouts

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.

Accessing objects from code is not a problem due to compile time code generation, no findById just access the field. Due to the powerful macro system in Haxe you even get in code autocomplete for objects defined in xml before running compilation.

For code reuse it allows easy way of defining custom widget classes based on xml file and using custom widgets in xml file.

In my experience with Qt bloat usually comes from graphical editors that add unnecessary properties you wouldn't have set in code or GUI systems that don't support creating reusable subcomponents.

1. The xml denotes that the whole thing should be wrapped in a div, and shouldn't just be considered a paragraph. With only lists you can't denote what kind of level you're at, unless you force each level to always carry the same meaning (which makes the format weaker than XML).

2. Setting "bold" to true isn't the same thing as emphasizing the text. Typically 'em' is italic, but more importantly a nested 'em' should no longer be italic. To achieve this with JSON you're forced to combine formatting and structure in a way that CSS was designed to prevent.

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.

I should clarify and say code can be declarative with the correct language support. I agree that it's probably not well suited to C# in its current state.

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

Here are two examples I would consider overly verbose in XAML:

1. Triggers, DataTriggers, EventTriggers, MultiTriggers, etc. Here we're dealing with the fact that XML is not a programming language and lacks basic control structures, so we've gone ahead and defined our own mini-programming language just so conditional values can be expressed in XML. Why?

2. Anything having to do with overriding ControlTemplates.

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

Ever make a typo in a binding?

I agree that Visual Studio is really good at helping you out where it can, but at the end of the day we're still trying to shoehorn programming constructs (objects, properties, enums, etc) into a document language format by shoving everything into XML attributes (where everything is a string) and there is a fundamental impedance mismatch between the two. Good tooling only goes so far.