Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When XML Beats JSON: UI Layouts

engineering.instawork.com

Post reply on HN
Print view View original

151–160 of 274 posts

Re: When XML Beats JSON: UI Layouts

#151

Post by jancsika »

sacado2 wrote: 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.

It's funny to me that even in an XML shining example of purpose you've got non-semantic "" there likely because, "just float where I want, dammit!"

Just imagining a JSON that starts with

"dummy": "don't remove this or the API will mis-align this across two structs!!!"

Re: When XML Beats JSON: UI Layouts

#152

Post by vbezhenar »

akdor1154 wrote: post #139
vbezhenar wrote: post #74

Earlier quoted context omitted.

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

As opposed to json: `{"number": 12345678901234567890}` What does that look like when you parse it?

Mapping from string to number. Probably BigInteger for Java, whatever other standard integer for other languages.

Re: When XML Beats JSON: UI Layouts

#153

Post by zdragnar »

Zarel wrote: post #144
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…

None of the flaws you list apply to TSX, which essentially gives you the best of both worlds. I really wish SwiftUI had used JSX-style syntax, just because of how nice it looks.

Technically, tsx / jsx is just a macro to convert an xml-like syntax to plain javascript objects... Neither xml nor json.

Inline functions and classes dont exist in either, JSX doesnt have to deal with xml's namespaces, and you dont need to construct an entire document- fragments are defined in functions at as granular a level as you like.

I do agree personally that I prefer tsx over the other alternatives, just pointing out that it is a pretty nice step up over something like flex or xaml.

Re: When XML Beats JSON: UI Layouts

#154

Post by vbezhenar »

TomMarius wrote: post #89
vbezhenar wrote: post #74

Earlier quoted context omitted.

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

This is tag with name Number and with two attributes. Are you trying to invent XML sublanguage? It's possible. But with JSON it's already invented and there are multiple libraries for every programming language. What should I use to parse your format?

Re: When XML Beats JSON: UI Layouts

#155

Post by gpderetta »

DagAgren wrote: post #27
yoz-y wrote: post #8

Earlier quoted context omitted.

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.

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 m…

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.

Re: When XML Beats JSON: UI Layouts

#156

Post by mrlala »

OskarS wrote: post #79

You know, when XML looks like this, I don't mind it so much: The thing is, XML in the real world never looks like this . In the real world, XML has an avalanche of obscure namespaces, weird " 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.

That still looks extremely confusing.. if I didn't know who those people were, I would have a really hard time even noticing that there is a hierarchy in what you presented.

And even still, that just doesn't look intuitive to me. Probably because there is no distinction between an employee and a list of employees linked to a parent employee?

Re: When XML Beats JSON: UI Layouts

#157

Post by tenaciousDaniel »

Touche wrote: post #135
tenaciousDaniel wrote: post #72

Earlier quoted context omitted.

Would be interesting though to opt in to those behaviors. So something like Then you could mix and match functionalities. So if you have a list of labels, you could do the following:

You do opt into them, by using label. if you want an element with no behavior, that's what div and span are for.

Right, but this offers two benefits: (1) semantic naming, and (2) composed functionality. So for example, if you wanted an element that exposes label behavior and list-item behavior, you could do that. With html, you have to use 2 elements:

Re: When XML Beats JSON: UI Layouts

#158

Post by MH15 »

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 fully agree with this statement. My work is generally for the web, and HTML has the same issues. It's amazing how much removing a single tag in a nested tree can mess up VSCode's parsing engine. Just modifying the tags usually works on both open and close though.

Re: When XML Beats JSON: UI Layouts

#159

Post by kickopotomus »

m1el wrote: post #84
arethuza wrote: post #61

Earlier quoted context omitted.

{ "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"], "."]

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

Re: When XML Beats JSON: UI Layouts

#160

Post by [deleted] »

gjulianm wrote: post #131
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 don't agree very much with your take. - User interfaces are very prone to have big files, because there tend to be a lot of different components. I don't get how XML will add more bloat, other than having the tags for defining elements. - XAML lets you define custom controls. I'm not familiar with Android XML, but in any case it's not an issue of the language but of the framework. - Again, a fault of the framework.…

[deleted]
Post reply on HN