Live data from Hacker News

When XML Beats JSON: UI Layouts

engineering.instawork.com

81–90 of 274 posts

Re: When XML Beats JSON: UI Layouts

#81
post #52

Earlier quoted context omitted.

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.

"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.

Years of experience > "the article"

JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.

Re: When XML Beats JSON: UI Layouts

#82
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/

Re: When XML Beats JSON: UI Layouts

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

Re: When XML Beats JSON: UI Layouts

#84
post #41

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: The JSON format was invented by Douglas Crockford . If your document consists mainly in losely structured text with some annotation, you better use XML.

{ "type": "div", "children": [ "The ", { "type": "a", "attributes": { "href": " https://www.json.org/" }, "children": [ "JSON format" ] }, " was invented by ", { "type": "a", "children": [ "Douglas Crockford" ] } ] } I think I prefer the XML :-) Edit: I agree that tagged text is a clear win for XML - for pretty much everything else I'd go for JSON. Edit2: HN ate my formatting, but probably not a bad thing ;-)

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

Re: When XML Beats JSON: UI Layouts

#85

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…

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.

Re: When XML Beats JSON: UI Layouts

#86
post #52

Earlier quoted context omitted.

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.

"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.

Using child nodes to declare properties of an object is the main reason I dislike XML. Because some people use children, and some use attributes, and some use both. Granted, that isn't XMLs fault, but every time I to have get XML data into a usable format it feels like a struggle.

Re: When XML Beats JSON: UI Layouts

#87

Earlier quoted context omitted.

> You can't express number or array with XML Numbers can be expressed, they just have to be parsed on the client. For array, child elements are ordered and form an array naturally.

> Numbers can be expressed, they just have to be parsed on the client. But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure. > For array, child elements are ordered and form an array naturally. But you can't express array of 0-length this way without explicit knowledge about structure. And you can't distinguish array of 1-length from…

Odd that you would pick numbers. Those are not exactly but free in json. And dates are as likely to actually be a problem.

Re: When XML Beats JSON: UI Layouts

#88
post #41

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: The JSON format was invented by Douglas Crockford . If your document consists mainly in losely structured text with some annotation, you better use XML.

[deleted]

Re: When XML Beats JSON: UI Layouts

#89

Earlier quoted context omitted.

> You can't express number or array with XML Numbers can be expressed, they just have to be parsed on the client. For array, child elements are ordered and form an array naturally.

> Numbers can be expressed, they just have to be parsed on the client. But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure. > For array, child elements are ordered and form an array naturally. But you can't express array of 0-length this way without explicit knowledge about structure. And you can't distinguish array of 1-length from…

> But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure.

Re: When XML Beats JSON: UI Layouts

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

Post reply on HN