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

141–150 of 274 posts

Re: When XML Beats JSON: UI Layouts

#141

Post by wil421 »

thrower123 wrote: post #134
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.

Agreed WSDLs are the only thing I love about SOAP and they are missing from REST. Most tools can import a WSDL and generate the code and structure for you.

Sometimes even getting a sample of the expected JSON format can be hard. If you’re not versioning you’re APIs you can break everything if the schema changes.

I used to debate this with the SOA manager. Swagger looks ok but never dealt with it in production or saw it in the wild with our customers.

Re: When XML Beats JSON: UI Layouts

#142

Post by zamalek »

nodamage wrote: post #99
gunn wrote: post #97

Earlier quoted context omitted.

It also has the advantage over code that it can be modified with a visual interface designer.

There's no reason this can't be done with code as well. See: SwiftUI

System.Windows.Forms works in the same way (the UI is serialized to code). WPF was designed many years after that because it allows different disciplines to work together.

Designers would most likely be familiar with XML given their HTML background, but they wouldn't necessarily know C#.

If Swift UI expresses the full fidelity of the API in the designer (e.g. expressing custom states and animations, keyframes, etc. on a custom button), then my point doesn't apply. If the full range of designer responsibilities cannot be achieved without dropping into code, then Swift UI isn't a real counterexample.

Re: When XML Beats JSON: UI Layouts

#143

Post by weberc2 »

ChrisSD wrote: post #71
weberc2 wrote: 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.

TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.

I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)

Re: When XML Beats JSON: UI Layouts

#144

Post by Zarel »

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.

Re: When XML Beats JSON: UI Layouts

#145

Post by postalrat »

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

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

Re: When XML Beats JSON: UI Layouts

#146

Post by weberc2 »

TravHatesMe wrote: post #73
weberc2 wrote: 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.

You’re welcome to your opinion. I disagree that XML is ideal for representing tree structures or anything else for that matter. I’ve used XML a lot (including for UIs and other tree-like data structures), but ever since JSON became popular I haven’t found myself missing it.

Re: When XML Beats JSON: UI Layouts

#147

Post by postalrat »

wry_discontent wrote: post #133
mdtusz wrote: post #127

Earlier quoted context omitted.

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.

Why is JSX so much more verbose? The end tags?

Re: When XML Beats JSON: UI Layouts

#148

Post by wil421 »

kgwxd wrote: post #128
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…

I still work with SOAP occasionally. I'd never recommend anyone start a new project with it, but I've never had to manually parse anything. Did the framework you had to work with not provide decent XSD/Class code generation and serialization/deserialization tools?

Yes and no. I worked with several middleware systems, a few disparate systems, and a couple very old systems. Right now I’m working on a few web service integrations with SerivceNow for Microsoft Teams, ticketing, and CMDB stuff, it has decent tools.

When you are hacking systems together for large/old enterprises the water gets muddy fast.

Re: When XML Beats JSON: UI Layouts

#149

Post by vharuck »

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…

My problem with the nested XML org chart is that relationships are described in the documentation instead of the code. The JSON version has more text but encodes more information. That's one less thing I need to write code for.

Re: When XML Beats JSON: UI Layouts

#150

Post by theandrewbailey »

moron4hire wrote: post #109
marcosscriven wrote: post #68

One thing I really miss when working on JSON vs XML data are comments. A workaround is to make the comment a valid string in the data, but still not as good as having the ability to comment an arbitrary line.

XML has comments. They are the same as HTML comments.

What do JSON comments look like?
Post reply on HN