When XML Beats JSON: UI Layouts • Hacker News Board

Re: When XML Beats JSON: UI Layouts

#131

Post by gjulianm » Wed, Oct 30, 2019, 2:33 PM UTC

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. Visual Studio, for example, checks your XAML for errors, both when writing and when compiling.

- I don't think namespaces are confusing (most programming languages have some concept of namespaces), but I agree that one could have more facilities to avoid specifying namespaces everywhere.

- Yes, but most of the time you shouldn't access the user interface from the application code, as coupling them tends to create ugly code that is prone to mistakes and failures. For me, this is an actual advantage of XML for UI, it makes it more difficult to create an interface out of spaghetti code.

- Well, one is declarative and the other one imperative. As long as you want to have both types, it doesn't matter what language you use.

For me, there's not that much of a difference between SwiftUI/Jetpack Compose and equivalent XML code. UI definitions are going to be messy no matter what.

Re: When XML Beats JSON: UI Layouts

#132

Post by gagan2020 » Wed, Oct 30, 2019, 2:34 PM UTC

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

Re: When XML Beats JSON: UI Layouts

#133

Post by wry_discontent » Wed, Oct 30, 2019, 2:35 PM UTC

mdtusz wrote: post #127

m1el wrote: post #78

> 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 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"} (…

There's a beautiful symmetry between s-expressions and XML which is why it's not really all that annoying to work with once you approach it as an s-expression.

Working with Clojurescript and Reagent (or Hiccup) has ruined JSX for me. It's so verbose and absurdly hard to work with relatively.

Re: When XML Beats JSON: UI Layouts

#134

Post by thrower123 » Wed, Oct 30, 2019, 2:41 PM UTC

wil421 wrote: post #46

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

When they did work, WSDLs were pretty slick.

Technically, there are REST/JSON equivalents, but I don't see them actually used much in the wild - so much of the time with REST APIs you are stuck with whatever half-baked, out-of-date documentation that somebody may or may not have written, or just randomly poking at it through trial and error to discover how it works.

Re: When XML Beats JSON: UI Layouts

#135

Post by Touche » Wed, Oct 30, 2019, 2:52 PM UTC

tenaciousDaniel wrote: post #72

Touche wrote: post #59

Earlier quoted context omitted.

The tags are defined so that there is reasonable default behavior. For example is used to label a form field. Clicking the label focuses the form field.

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.

Re: When XML Beats JSON: UI Layouts

#136

Post by akdor1154 » Wed, Oct 30, 2019, 2:53 PM UTC

Kuinox wrote: post #64

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.

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

Well yep, but that ship has long sailed.

Re: When XML Beats JSON: UI Layouts

#137

Post by falcolas » Wed, Oct 30, 2019, 2:54 PM UTC

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.

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

Re: When XML Beats JSON: UI Layouts

#138

Post by BubRoss » Wed, Oct 30, 2019, 2:58 PM UTC

TravHatesMe wrote: post #100

BubRoss wrote: post #81

Earlier quoted context omitted.

Years of experience > "the article" JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.

Your opinion != Everyone's opinion Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.

I didn't say any of that. JSON is a tree structure, that isn't an opinion.

Re: When XML Beats JSON: UI Layouts

#139

Post by akdor1154 » Wed, Oct 30, 2019, 2:58 PM UTC

vbezhenar wrote: post #74

tasogare wrote: post #69

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…

As opposed to json: `{"number": 12345678901234567890}`

What does that look like when you parse it?

Re: When XML Beats JSON: UI Layouts

#140

Post by superqd » Wed, Oct 30, 2019, 3:01 PM UTC

kgwxd wrote: post #123

superqd wrote: post #98

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

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…

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.