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

71–80 of 274 posts

Re: When XML Beats JSON: UI Layouts

#71

Post by ChrisSD »

weberc2 wrote: post #52
hyperman1 wrote: post #32

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…

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.

Re: When XML Beats JSON: UI Layouts

#72

Post by tenaciousDaniel »

Touche wrote: post #59
tenaciousDaniel wrote: post #43

Earlier quoted context omitted.

As someone who has only used html (as in, no other xml-based UI), I'm really curious why it's necessary to even define the tags at all. Why not allow authors to define their own names? Like Then internal functionality can be attached to each element via attributes, like how aria roles work.

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:

Re: When XML Beats JSON: UI Layouts

#73

Post by TravHatesMe »

weberc2 wrote: post #52
hyperman1 wrote: post #32

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…

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.

Re: When XML Beats JSON: UI Layouts

#74

Post by vbezhenar »

tasogare wrote: post #69
vbezhenar wrote: post #44

Earlier quoted context omitted.

Representing is easy task. You need to parse that representation. And XML here is worse than JSON for typical programming graphs. You can't express number or array with XML. XML Schema helps to add more structure, but JSON does not need that, array and numbers are built-in. And I would say, that XML Schema is too powerful and that's usually not needed by developers. JSON is just a fine medium, simple enough and power…

> 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 an ordinary value without explicit knowledge about structure.

Re: When XML Beats JSON: UI Layouts

#75

Post by cfv »

XML also has a LONG history of being used for UI in stuff like QT, which is great.

The one problem I see is that as developers, we shouldn't give a rat's ass about the otuput format's readability when compared to the API ergonomics. If the API for describing the UI is good enough (Can I do stuff like "App.Transition(App.findOne(Sidebar), 500, {width:"1%"}, {width:"30%"}, Ease.EASE_IN_OUT)" or is it a 300loc tutorial?) then the storage format at the end of the day is not THAT important, at least for me, a guy who does a lot of GUI work every day.

Re: When XML Beats JSON: UI Layouts

#76

Post by hagreet »

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…

1. Why is parsing a tree which is encoded in JSON easier? 2. Why does it matter if an element is in an attribute or in child elements. You need some kind of schema anyway, right?

Re: When XML Beats JSON: UI Layouts

#77

Post by adamlett »

sacado2 wrote: post #50
adamlett wrote: post #28

I have yet to read anything that convinces me that XML is good for anything . Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options. See also Erik Naggum's legendary rant: https://www.schnada.de/grapt/eriknaggum-xmlrant.html

Well, for instance, let's take the HTML code of your comment (which happens to be a valid XML document): I have yet to read anything that convinces me that XML is good for anything . Just because XML in certain cases is less bad than some other cherry-picked technology, doesn't mean that there aren't other better options. See also Erik Naggum's legendary rant: https://www.schnada.de/grap…

In order for me to answer that, you must be more specific about the purpose of the representation.

For the purpose of authoring comments on Hacker News (HN), I for one am grateful= that HN doesn't make us type out HTML. I also doubt very much that HN stores our comments in a different representation (e.g. HTML) than the one they were authored in.

Re: When XML Beats JSON: UI Layouts

#78

Post by m1el »

> 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"}
          (Employee {:name "Dwight Schrute" :title "Ass. Regional Mgr"})
          (Employee {:name "Jim Halpert" :title="Head of Sales"}
            (Employee {:name "Andy Bernard" :title="Sales Rep"})
            (Employee {:name "Phyllis Lapin" :title="Sales Rep"})))
        (Employee {:name "Pam Beesly" :title "Office Administrator")))

Re: When XML Beats JSON: UI Layouts

#79

Post by OskarS »

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.

Re: When XML Beats JSON: UI Layouts

#80

Post by tenaciousDaniel »

nidificate wrote: post #58
tenaciousDaniel wrote: post #43

Earlier quoted context omitted.

As someone who has only used html (as in, no other xml-based UI), I'm really curious why it's necessary to even define the tags at all. Why not allow authors to define their own names? Like Then internal functionality can be attached to each element via attributes, like how aria roles work.

This already exists. They are called custom elements. https://html.spec.whatwg.org/multipage/custom-elements.html#... https://github.com/w3c/webcomponents/ https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

Yep, to some degree. Though what I would love in an xml-based UI description language is the ability to opt into default system behaviors, while maintaining the ability to use whatever semantic naming convention that fits my application.

I wrote this code in another comment, but imagine if you could hook functionality to an element via defined attributes. With custom elements, you have to add the functionality via a script, and they aren't system functions (from what I can remember, I may be wrong).
In the above code:

- the LabelList element hooks into the systems "list" behavior

- the LabelItem element hooks into the systems "label" behavior

- the LabelItem element hooks into the systems "listItem" behavior

Post reply on HN