19 ms·

When XML Beats JSON: UI Layouts

261 points by creolabs 7y ago

wiso 7y ago
No mention of XAML.
ryuukk_ 7y ago
Swift with SwiftUI proved that XML/JSON/WhatEver is useless if your language is built to facilitate creating DSLs Same for Compose/Kotlin
tasogare 7y ago
The ability to extend an existing element with attributes is super useful in XML. To do an equivalent in JSON is quite ugly.
onion2k 7y ago
No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep, so the file structure used to store the UI data doesn't need to be human-readable. This is true for any data - once you hit a moderate level of complexity neither JSON or XML really work - you need to build a tool to manipulate the underlying data rather than changing it directly. If you do that then it doesn't matter how readable or 'ugly' the data is because a human being shouldn't need to access it directly. This leads to other benefits you can optimize for like size or parsing speed or redundancy instead.
- ilogik 7y ago
  so we shouldn't write HTML by hand, but instead use WYSIWYG editors?
  - onion2k 7y ago
    HTML isn't a UI description. It's a document description. HTML + CSS + [browser behavior|Javascript] is the UI description, and arguably some more complex web apps are getting to the point were they've gone past the point where HTML, CSS, and JS are the best formats for describing the way they work.
    - shantly 7y ago
      They never were the best way. Other application GUI systems are less painful because they were designed for that from the beginning. HTML remains OK for documents, though.
- kreco 7y ago
  Following what you say we should only have binary format. I think you underestimate the convenience of a text format. It does not only provide a simple way to generate it, but also provide a way to modify it by hand.
  - yoz-y 7y ago
    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.
    - DagAgren 7y ago
      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 making a small change to a JSON file, it is entirely legal to reorder every single key, completely destroying the diff, and an automatic tool may very well do this. And as a counter-example, we could easily use a binary representation of JSON data, but use a diffing tool that normalises key ordering to provide diffs that are more readable and understandable than a text diff of a JSON file, even without malicious reordering of lines.
      - gpderetta 7y ago
        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.
  - onion2k 7y ago
- grepthisab 7y ago
  This reminds me of the line of thought from the React community. Make everything as complex as possible (vdoms, etc.). But there are other ways, frameworks, styles to achieve what people want without that level of complexity. A "moderate" level of complexity absolutely does not require special tooling to manipulate underlying data.
- Razengan 7y ago
  > No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep, so the file structure used to store the UI data doesn't need to be human-readable. I strongly disagree. SwiftUI is fucking amazing. https://developer.apple.com/tutorials/swiftui/ https://developer.apple.com/tutorials/swiftui/ Even with your other comment about "until you hit a moderate level of complexity." People are already creating some complex things with it. In fact, they can be more complex than what you can achieve with traditional frameworks when you consider the time it takes; what takes me a day in UIKit etc. takes me a minute in SwiftUI, so I can quickly move on to the next bit. With declarative UI code I could literally have a usable app in the same time it takes me to struggle with getting separate visual designers + logic editors to agree over a single moderately complex component. Though, it is several layers of abstraction over what really happens behind the scenes, so I guess a part of your point stands.
- iainmerrick 7y ago
  The other replies cover most of my reaction, but there’s one more thing I want to add: If you have a binary format for a tree structure, you almost always end up accruing garbage as you edit it. That always happens in rich HTML editors, for example. For something like an image editor, the bitmap is OK because it’s not a tree structure and doesn’t balloon out of control as you edit. Where your image is tree-structured, eg Photoshop layers, the editing tool will generally show you the exact layer tree in a sidebar, so you can make sure it stays clean and tidy. It’s easiest to keep it tidy when the canonical source is human-readable text. (Although it’s worth watching out for formatting differences. Something like gofmt helps there.)
- whytaka 7y ago
  > No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep Yet people do this everyday. So it's not that complex.
sparsely 7y ago
Good article, but for some reason he doesn't mention one the best XML UI systems: WPF.
- robbya 7y ago
  WPF is Windows Presentation Foundation. https://docs.microsoft.com/en-us/visualstudio/xaml-tools/designing-xaml-in-visual-studio?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/xaml-tools/des...
ChrisMarshallNY 7y ago
The main reason that I use XML (occasionally) is because of XML Schema. It's a very precise data description that can be semantically verified. Otherwise, I try to use JSON, where possible, because I am not a masochist.
- arethuza 7y ago
  JSON Schema is pretty useful and is well supported by tools like VS Code
- laggan 7y ago
  I actually found JSON Schema to be FAR FAR FAR easier to use than XML Schema. https://json-schema.org/ https://json-schema.org/
  - ChrisMarshallNY 7y ago
    You are correct. I LOATHE XML Schema. I have used it for years, and have never memorized it. I still need to look it up like a n00b, every time I use it. But the simple fact of the matter is, is that so many people and projects have inculcated it into hundreds (if not thousands) of toolsets and specs (Like -Ick- WSDL), that it really is the only viable game. People tend to like JSON precisely because it eschews the kind of overhead that is the definition of XML Schema.
  - ChrisMarshallNY 7y ago
    Huh. I just realized that JSON Schema is STILL not a published spec. It is currently in draft, and has been, for a long time.
- halfdan 7y ago
  Does https://json-schema.org/ https://json-schema.org/ not work for you?
  - sacado2 7y ago
    I don't know JSON schema really well; Can you say you want a `price` value to be a non-negative decimal value with at most two digits after the comma, and you want the `currency` value be exactly one of the following : "EUR", "USD", "GBP", the default if not specified being "EUR"?
imvetri 7y ago
This doesn't seem to solve any problem related to UI. Because tree can be converted to a list and vice versa. The added advantage is tree structure is natural. But the way article is put forward is as if using json we cannot achieve tree structure
tobr 7y ago
If XML is better at representing trees, and JSON is a tree, does that mean that XML is better at representing JSON than JSON?
- athenot 7y ago
  This is reminiscent of the (whimsical) RFC 3252: Binary Lexical Octet Ad-hoc Transport https://www.ietf.org/rfc/rfc3252.txt https://www.ietf.org/rfc/rfc3252.txt
- lucideer 7y ago
  Yes. Consider a comparison of examples using JSON schema: { "$schema": "http://json-schema.org/draft-04/schema#", "description": "Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'", "definitions": { "schemaArray": { "type": "array", "minItems": 1, "items": { "$ref": "#" } } } ... <schema schema="http://json-schema.org/draft-04/schema#"> <description>Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'</description> <definitions> <schemaArray> <type>array</type> <minItems>1</minItem> <items ref="#" /> </schemaArray> ... $schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. In the XML representation, the distinction is implicit and handled automatically for you by every parser.
  - pytester 7y ago
    >$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. This isn't just a matter of usability, it has security implications because it increases the attack surface of anything that uses it (e.g. the XML billion laughs attack).
    - lucideer 7y ago
chadlavi 7y ago
JSON is a data structure. XML is a text markup. Don't mix them up.
- thesuperbigfrog 7y ago
  XML is also a transform specification with XSLT (https://en.wikipedia.org/wiki/XSLT https://en.wikipedia.org/wiki/XSLT). XML is also a query language with XQuery (https://en.wikipedia.org/wiki/XQuery https://en.wikipedia.org/wiki/XQuery). XML is also a nested structure path specifier with XPath (https://en.wikipedia.org/wiki/XPath https://en.wikipedia.org/wiki/XPath). XML is also a file format with SVG (https://en.wikipedia.org/wiki/Scalable_Vector_Graphics https://en.wikipedia.org/wiki/Scalable_Vector_Graphics), OpenOffice XML (https://en.wikipedia.org/wiki/OpenOffice.org_XML https://en.wikipedia.org/wiki/OpenOffice.org_XML), OpenDocument (https://en.wikipedia.org/wiki/OpenDocument https://en.wikipedia.org/wiki/OpenDocument), ePUB (https://en.wikipedia.org/wiki/EPUB https://en.wikipedia.org/wiki/EPUB), DocBook (https://en.wikipedia.org/wiki/DocBook https://en.wikipedia.org/wiki/DocBook), and many others (https://en.wikipedia.org/wiki/List_of_XML_markup_languages https://en.wikipedia.org/wiki/List_of_XML_markup_languages). XML is also an data/object serialization format with libraries like Jackson (https://github.com/FasterXML/jackson https://github.com/FasterXML/jackson), YAXLib (https://github.com/sinairv/YAXLib https://github.com/sinairv/YAXLib), Boost (https://www.boost.org/doc/libs/1_38_0/libs/serialization/example/demo_xml.cpp https://www.boost.org/doc/libs/1_38_0/libs/serialization/exa...), Pyxser (https://github.com/dmw/pyxser https://github.com/dmw/pyxser), and many others. XML may not be as elegant as JSON, but it has a wide variety of uses and wide adoption across many programming languages (libraries), and disciplines.
- gwbas1c 7y ago
  I was going to make the same post, upvoted you instead! What's nice about JSON is that there's very little ambiguity in how to serialize / deserialize data structures. That's what's so powerful about it. As a result, using "magic" serializers with language-native data structures often works well and has little gotchas. In general, I think a lot of people hopped onto the XML bandwagon assuming that it would always sanely translate back and forth between XML and native data structures. This is not the case. When XML is the (cough) "best" format, the underlying data structures of different programs operating on the XML will look extremely different. Furthermore, XML terminology will end up leaking into business logic, because the semantics of the document are inseparable from handling it. In general, I think the biggest sign that XML is the wrong choice is when someone's using a "magic" serializer, or when the data structures very closely follow the document structure. In those cases, JSON was probably a better choice.
castwide 7y ago
I'd expand on his premise by saying that XML beats JSON for structured documents, which also happens to be a practical way to represent a UI layout.
adamlett 7y ago
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 https://www.schnada.de/grapt/eriknaggum-xmlrant.html
- mettamage 7y ago
  How about simple DSL layouts?
  - michaelmior 7y ago
    Do you mean a simple DSL for layouts?
- sacado2 7y ago
  Well, for instance, let's take the HTML code of your comment (which happens to be a valid XML document): <span class="commtext c00">I have yet to read anything that convinces me that XML is good for <i>anything</i>. 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.<p>See also Erik Naggum's legendary rant: <a href="https://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">https://www.schnada.de/grapt/eriknaggum-xmlrant.html</a></span> What would be the JSON/YAML/TOML equivalent?
  - ben509 7y ago
    The HTML doesn't represent the classes properly. The LaTeX would take a simpler approach: \begin{spanned} I have yet to read \textit{anything}... \end{spanned} Since there's no Javascript, probably no need for the class variables. And, of course, you can just write your own macros as you need them.
  - ChrisSD 7y ago
    Side note: You've overdone the character entities a bit more than necessary.
mettamage 7y ago
XML is so awesome for UI layouts. I had a thesis that I worked on that was basically a subset of HTML (check the SMIL specification for something similar, albeit a bit more complicated, SMIL used to be a W3C recommendation). It was so easy to understand that every person who was able to use a computer would pick it up quickly. This was not the case for HTML, my guess is because there are a ton of HTML tags and that can be overwhelming for a certain type of audience, whereas here there are at most 10 tags to learn. The framework I'm talking about still exist, it's called XIMPEL [1] (sadly SMIL kind of died). It may seem like a weird thing, but IMO it's the only open-source framework that has an intuitive way to make non-linear storytelling easy on the web easy. People can kind of hack a choose your own adventure media story with YouTube, but XIMPEL really is so much better at it because it's actually made for that purpose. And the biggest reason why XIMPEL is simpel because it uses XML as its template language. People just see the tags as lego blocks and build non-linear media essays, stories or even small (media-focused) games with it. [1] http://www.ximpel.net/ http://www.ximpel.net/
- mfer 7y ago
  > It was so easy to understand that every person who was able to use a computer would pick it up quickly. I find this hard to believe. I know many people who use computers but are not IT professionals or even hobbyists. Without an easy to use GUI they can't accomplish much. I couldn't imagine them picking up anything to do with XML. If you scope it down to UI developers you're taking less than 1% of people. Far from everyone. Even if you scope it down to IT people it's less than 1% of people.
  - swiley 7y ago
    It’s not that they can’t. They’ve just been told they can’t. I’ve been told that clerks at bell labs were using troff because they were told they weren’t programming and I think GUIs have the same opposite effect.
  - rescbr 7y ago
    There’s the always forgotten type of computer users: those who use computers for productivity. People who need to achieve some business goal and they have the energy to learn. Take for instance insane Excel spreadsheets glued with VBA powering entire businesses, built by accountants and other professionals.
michaelmior 7y ago
The XML example seemed odd to me as written. In the JSON case, yes there was a prefixed key "$reports", but it told me what the relationship was. Looking at the XML, what does it mean for an Employee to be nested inside another Employee?
- jimktrains2 7y ago
  Sounds like the list of employees should have been nested in a <reports> and not left directly inside the employee.
hyperman1 7y ago
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 discuss the possibility that the pendulum swung too far?
- weberc2 7y ago
  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.
  - ChrisSD 7y ago
    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.
    - weberc2 7y ago
      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. :)
      - yellowapple 7y ago
        What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments). That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions. ¹: https://man.openbsd.org/pf.conf https://man.openbsd.org/pf.conf ²: https://man.openbsd.org/smtpd.conf https://man.openbsd.org/smtpd.conf ³: https://man.openbsd.org/relayd.conf.5 https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5 https://man.openbsd.org/httpd.conf.5 ⁴: https://otpcl.github.io https://otpcl.github.io
dukoid 7y ago
Another reason why XML might be better for UI Layouts (in addition to typed nodes) is that it allows mixed content, making it more concise in the case where marked up text is included.
dandare 7y ago
I am not familiar with Xcode: is there an easy way to get the exploded 3D view of DOM in a browser? Maybe a browser extension?
- nkrisc 7y ago
  Firefox used to do this, but looks like they haven't for a while. Guess it's been longer than I thought since I used it. https://developer.mozilla.org/en-US/docs/Tools/3D_View https://developer.mozilla.org/en-US/docs/Tools/3D_View
ivankolev 7y ago
Android UI is xml based and it works relatively well there
whereareyouwow 7y ago
Reminds me of jasonette (https://jasonette.com/ https://jasonette.com/) ... Whether it is JSON or XML, what I particularly like about both approaches is that both are fundamentally HATEOAS (https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS)
sacado2 7y ago
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: <div>The <a href="https://www.json.org/">JSON format</a> was invented by <em>Douglas Crockford</em>.</div> If your document consists mainly in losely structured text with some annotation, you better use XML.
- arethuza 7y ago
  { "type": "div", "children": [ "The ", { "type": "a", "attributes": { "href": "https://www.json.org/" 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 ;-)
  - m1el 7y ago
    ["div", "The ", ["a", {"href": "https://www.json.org/" https://www.json.org/"}, "JSON format"], " was invented by ", ["em", "Douglas Crockford"], "."]
    - ses1984 7y ago
      Interesting.
    - ilogik 7y ago
      that looks like the JSON documents in AWS's CloudFormation
    - sacado2 7y ago
      Quite readable but it's a hell to parse. The first argument is the name of the element, but what is the second one? If it is a string or an array, it's the first child, but if it's an object, it's the attribute set?
tambourine_man 7y ago
Who would've thunk that different tools excel at different tasks? We need more articles like this, to remember us that we should consider what's best for the task at hand and not what's trendy.
- beatgammit 7y ago
  Yup, use object notation for passing around objects, use a markup language for markup. It's almost like reading the names gives a hint as to what it was designed for and probably best at. My sniff test is that if you're editing it by hand, JSON is a poor format because you'll want the benefit of a schema or at least a user-friendly format. If you're not, the syntax doesn't really matter so we should evaluate it on technical merits (verbosity, computational complexity for serialization/deserialization, memory footprint, etc). I use: - config file formats for config files (usually TOML or INI format) - data formats for data (JSON, protocol buffers, etc) - markup formats (Markdown, XML/HTML) or code for markup I really don't get why people try to force all use cases onto the same format. Use whatever is well suited for the task, preferring familiarity over unnecessary technical benefits.
wil421 7y ago
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. Exactly. I’ve seen XML with element attributes and child elements all over the pace. No rhyme or reason for any of it. It’s especially bad in older systems. I pushed hard at my last job for the SOA team to build REST/JSON web services. Oracle sold them a product to bridge the gap and they got End Of Life announcements 6 months later! Glad I’m gone.
- hagreet 7y ago
  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?
  - LastMuel 7y ago
    The author makes a case for why it would matter: > XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements). Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes. So, you lose a bit of context in the conversion. Such as: `<Document text="true" />` Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know. Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.
  - wil421 7y ago
    It depends on the API of the system. I’ve worked on middleware that would not be able to get an attribute, it lacked the capability. Other systems used JavaScript and it was much easier with JSON See this link on stack exchange[1]. [1] https://stackoverflow.com/questions/17604071/parse-xml-using-javascript https://stackoverflow.com/questions/17604071/parse-xml-using... > //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue; I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.
usrusr 7y ago
The JSON examples are not even valid, the "$reports" properties on department are written as comma separated lists without enclosing array brackets. I guess XML might be perfect for when you can't decide between singular and plural and want to leave the problem to others... Because that's the biggest problem besides charset encoding that JSON helps solving: in JSON, you can be unmistakably clear that a given property is to be interpreted as a list of values, even when the current number is less than two. In XML you can just vaguely communicate that intent with an intermediary "plural element" unless you go full schema. <A><Bs><B/><Bs/><A/> isn't half as clear as {"bs":[{}]} (attributes unrelated to this difference omitted)
underwater 7y ago
I find JSON better for random lookups, and XML good for sequential reads. UI falls into the later basket: start at the root, read the children, etc, etc.
taude 7y ago
Good thing we've had XML defining layouts for many years, despite many of the technologies that used the pattern being dead. XML as a layout definition vs XML as data were topics devs discussed heavily 15 years ago, too. So many Java frameworks used Xml to describe the user interfaces (like JavaServer Faces, early Tapestry, etc.). At one time, I worked with a lot was Adobe Flex which used MXML to define user interfaces [1], don't forget about Microsoft's XAML. It's actually amazing to me how many of Flex's great ideas live on in other frameworks not dependent on the Flash Player, and looking at some modern day React often reminds me if it. [1] http://flex.apache.org/doc-getstarted.html http://flex.apache.org/doc-getstarted.html
marcosscriven 7y ago
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.
- moron4hire 7y ago
  XML has comments. They are the same as HTML comments. 
  - marcosscriven 7y ago
    That was indeed my point - whereas one can't in JSON.
    - moron4hire 7y ago
      I must have read your post three times and still thought you said "and XML". I'm sorry.
  - theandrewbailey 7y ago
    What do JSON comments look like?
thequailman 7y ago
While not really JSON, HyperScript[1] is much easier to grok than XML to me. It allows you to define layouts really naturally using standard JS objects. Mithril[2] specifically implements it really well. 1 - https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript 2 - https://mithril.js.org/index.html#dom-elements https://mithril.js.org/index.html#dom-elements
cfv 7y ago
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.
- andrekandre 7y ago
  it isnt that important for me either, and imo shouldn’t be...BUT when you are in a formal setting, people like to code review, and in that case, in the absence of some special diff tool, people will complain they can’t review your ui changes in github and suddenly your format matters alot more than before
m1el 7y ago
> 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 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")))
- mdtusz 7y ago
  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.
  - wry_discontent 7y ago
    Working with Clojurescript and Reagent (or Hiccup) has ruined JSX for me. It's so verbose and absurdly hard to work with relatively.
    - postalrat 7y ago
      Why is JSX so much more verbose? The end tags?
      - wry_discontent 7y ago
        It's primarily the end tags, yes, but there's also the className shorthand in reagent that's nice. [div.btn.blue.p-4 {:disabled true} "Button Text"]
- gambler 7y ago
  This reminds me of an old joke about binary XML: <byte> <bit>1</bit> <bit>1</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>1</bit> <bit>1</bit> <bit>0</bit> </byte> >It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm http://m1el.github.io/jsonht.htm It is not concise. Here is an example of a single div tag overhead: ["div",{"class":"some classes"}, ... ] <div class="some classes"> ... </div> Also, it does not represent DOM trees as JSON. It represents DOM trees as S-Exressions encoded via JSON. The s-expression above can be written directly as: (div (class= "some classes") ... ) So why does it need to be wrapped in a format that's verbose, underspecified, doesn't have comments, doesn't have namespaces and doesn't have any notion of metadata?
OskarS 7y ago
You know, when XML looks like this, I don't mind it so much: <Employee name="Michael Scott" title="Regional Manager"> <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> <Employee name="Pam Beesly" title="Office Administrator" /> </Employee> The thing is, XML in the real world never looks like this. In the real world, XML has an avalanche of obscure namespaces, weird "<![CDATA" things, unreadable attributes, incomprehensible structure, and god knows what else. 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.
- tomschlick 7y ago
  > <Employee name="Dwight Schrute" title="Assistant to the Regional Mgr" /> Fixed that for you :) https://www.youtube.com/watch?v=wA9kQuWkU7I https://www.youtube.com/watch?v=wA9kQuWkU7I
  - kbenson 7y ago
    Such a missed opportunity to include Jim in the favorite movies examples with movies like Clear and Present Danger, Patriot Games, etc...
- deleted 7y ago
  [deleted]
- falcolas 7y ago
  > 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?
red_admiral 7y ago
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/ https://rachelbythebay.com/w/2019/07/21/reliability/
- Rebelgecko 7y ago
  Using GSON is great if you're encoding/decoding straightforward data structures. However if you're using it for serialization for more complicated objects (especially with polymorphism!) it gets zany really quickly.
dangerface 7y ago
> 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.
nodamage 7y ago
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. <Button title="blah"/> 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.
- gunn 7y ago
  It also has the advantage over code that it can be modified with a visual interface designer.
  - chooseaname 7y ago
    I'm pretty sure Delphi and VB were famously successful in spite of the fact that they didn't use XML for UI layout.
  - nodamage 7y ago
    There's no reason this can't be done with code as well. See: SwiftUI
    - zamalek 7y ago
      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.
jrochkind1 7y ago
I don't disagree that JSON is better than XML for their "list" example,and that XML is better than JSON for their "UI layout" example. BUT: > This means there’s no officially supported way to represent the list of movies in an element attribute. We can hack this by encoding the list into an attribute using a comma delimiter: <Users> <User first="Michael" last="Scott" favoriteMovies="Diehard, Threat Level Midnight" /> So, that's because you're doing it wrong. XML has NO PROBLEM with hieararchy, REALLY. Of COURSE there's a supported way to encode hieararchy. <Users> <User> <first>Michael</first> <last>Scott</last> <favoriteMovies> <title>Diehard</title> <title>Threat Level Midnight</title> </favoriteMovies> </User>
- shawabawa3 7y ago
  You should have read the next paragraph. They do use that as an example <Users> <User> <FirstName>Michael</FirstName> <LastName>Scott</LastName> <FavoriteMovies> <Movie>Diehard</Movie> <Movie>Threat Level Midnight</Movie> </FavoriteMovies> </User>
  - jrochkind1 7y ago
    Fair! Why the heck did the author first try to tell us XML had no "officially supported way" to do this then?
    - Slartie 7y ago
      Because it was about encoding a list of things in an _attribute_. Attribute! Using nested elements is not exactly a solution for that requirement.
- wtetzner 7y ago
  And if you want, you can still keep some of the attributes: <Users> <User first="Michael" last="Scott"> <favoriteMovies> <title>Diehard</title> <title>Threat Level Midnight</title> </favoriteMovies> </User>
superqd 7y ago
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 manage people - they have that property). But the org chart as XML was anything but obvious to my human eyes, as it was just nested employee elements and at first glance, looked like a single list of employees. Visually interpreting it to know who's a manager, and who reports to whom seems far more difficult in the XML. But, again, it's in the eyes of the beholder, and one person's clean solution is another person's confusing tangle of brackets.
- vharuck 7y ago
  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.
- kgwxd 7y ago
  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 a "manager" property.
  - superqd 7y ago
    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.
commandlinefan 7y ago
XML also supports id references, which are built into the parser - to my knowledge, there's no JSON equivalent (nor, do I think, could there be).
deleted 7y ago
[deleted]
neves 7y ago
Everybody knows that Yaml is the one true file format!
gagan2020 7y ago
Yes, XML flavor beats JSON in UI layouts. We call that flavor HTML.
bcheung 7y ago
If you are going to make the case for one being better than the other then show the same data in 2 different formats side by side. The article only shows 1 example in 1 format and then moves onto another point. The reader is left to imagine what the difference is in their head.
swsieber 7y ago
I really like the idea of a constrained language for UI declarations, like the angularJS/vue templates and XML instead of UI in code. It makes generating test code for the UIs tractable. Here's my take on what's possible for generating support code for UI tests when the UI is written in a declarative, easily-parseable language: https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-dsls-in-kotlin/ https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...
bullen 7y ago
Seems XML is having a revival on HN so I'll just repost my XML editor: I would love to know what people think of my XML node-graph/tree editor I made before JSON became mainstream (my excuse): http://rupy.se/logic.jar http://rupy.se/logic.jar - You link/unlink nodes (I called them entities! Xo) by right-click-dragging between them. - You copy stuff by right-click-dragging to an empty space. - You delete by grabbing something by left-click-holding and pressing the delete key. - Oh, and nodes are completely tree structure expandable, just drag-drop attributes on nodes and nodes inside nodes. (I know, not super intuitive; but very handy once you know about these.) The editor uses lightweight rendering so you can have a ton of elements with good performance.
crooked-v 7y ago
XML is old hat. We should obviously be defining configurations using JSX now.
mwkaufma 7y ago
XML vs JSON (vs code) devolves into bike-shedding because it positions the discussion in the wrong place. Developing layout in plaintext, rather than a WYSIWYG editor, is a priori impedance-mismatched.
adamstep 7y ago
Author here. The meta-point of my post is that different formats have their advantages and disadvantages, and it's good to understand those when deciding on what's appropriate for a given use case. So I'm glad to see a discussion weighing the pros and cons in the thread! I see some comments saying that JSON can represent trees just as well as XML, which is technically true. However, XML natively supports a distinction between node metadata (via properties) and relationships (via child elements) that has to be implied in JSON. For pure-data, this may not matter . But in cases like UI layouts, it's helpful to have the format distinguish between node properties and child components. As others have mentioned, the document use case is also a natural fit for XML by clearly separating the content from markup.
lbruder 7y ago
Where Tk beats everything else. "pack" and "grid" are still way ahead of the established layout stuff. And Tcl is the perfect language for Tk. Sadly people are put off by its seemingly strange syntax and semantics...
unilynx 7y ago
One thing that's contrary to how XML is historically used but helps a lot.. do not use child elements where an attribute suffices: eg, don't do this, from the article: <Users> <User> <FirstName>Michael</FirstName> <LastName>Scott</LastName> <FavoriteMovies> <Movie>Diehard</Movie> <Movie>Threat Level Midnight</Movie> </FavoriteMovies> </User> ... </Users> but write it like this <Users> <User FirstName="Michael" LastName="Scott"> <FavoriteMovies> <Movie Title="Diehard" /> <Movie Title="Threat Level Midnight" /> </FavoriteMovies> </User> ... </Users> Much easier to query for a specific element (eg, try to XPath or CSS Selector query for all of Michael Scott's favourite movies with the first syntax), and the schema is a lot easier to write and reason about (I don't have to wonder if multiple LastNames might be allowed, if I can set a xml:lang attribute on any of them, if the ordering of FirstName and Lastname elements is constrained, etc etc)
teyc 7y ago
Implementations of layout in source code tend to suffer hard-to-diff from a source control point of view. Everytime you move an existing component into a wrapper, the identation breaks how the diff shows up. Perhaps we need a XML formatter that instead of pretty formats, sets the indentation to 0, when we commit code changes. However, that makes the source hard to read. So instead of a diff that reads line - <panel> - <textblock>foo</textblock> - </panel> + <vpanel> + <panel> + <textblock>foo</textblock> + </panel> + </vpanel> We get + <vpanel> <panel> <textblock>foo</textblock> </panel> + </vpanel> Another problem is with the end tags, it is difficult as in the previous example to tell which opening tag an end tag is for. A pretty formatter could solve this problem too. <vpanel id="vertical-wrapper"> <panel id="heading"> <textblock>foo</textblock> </panel> </vpanel> Perhaps the level of indentation could be added visually too <vpanel id="vertical-wrapper">  <panel id="heading">  <textblock>foo</textblock>  </panel>  </vpanel>  but then we bring back the problem of the ugly diffs, gah!
- andrewflnr 7y ago
  You can pass -b to git diff to get exactly your first result. I would lean toward editor tooling for the latter case, myself.
zeptoon 7y ago
XML in most cases is a pain in the ass to deal with relative to JSON and it isn't new or the rage anymore. A lot of hot technologies initially have this in common. They're so cool and flashy and new that everyone's willing to overlook the actual mechanics of working with them -- for a while. JSON is just more convenient to work with 90-95% of the time, so everyone ends up preferring it and so it tends to win out.
mattsanders 7y ago
This is just a simple case of serialization. Having worked on 10+ game engines and other scene graph based applications I would prefer a more flexible reference based approach. Instead of hard coding your hierarchy into the structure of XML or JSON. Define some basic type information (unique id and node type). If you have situations where an object can be referenced before it is defined simply make a proxy loading type that listens for it to load. After that it is a cakewalk: [ { id: "UUID OR Rolling Number Per File OR DB Index OR ...", type: "business", name: "Dunder Mifflin Paper Company, Inc." description: "look at me I can be a root type for the graph OR one of many!" offices: [ list of ids of objects of type "office" or object that wraps this with other metadata (relation object) ] }, ... potentially other business entries, { id: see above... type: "office", name: "Scranton Branch", description: "This can describe each branch" departments: [ list of ids of objects of type "department" or object that wraps this with other metadata ] }, ... other offices, { id: see above..., type: "department", name: "sales", members: [ list of ids of objects of type "employee" or object that wraps this with other metadata ] }, ... other departments, { id: see above..., type: "employee", title: "manager", name: "Michael Scott", reports: [ list of ids of objects of type "employee" or object that wraps this with other metadata ] }, { id: see above..., type: "employee", title: "sales man", name: "Dwight Schrute", reports: [ id of self since Dwight needs someone he can trust, { id: see above..., type: "report_meta", reportee: id of Pam, visibility: "secret" } ] }, ... other employees, etc., etc. ]
nitwit005 7y ago
If it's purely a choice between XML and JSON, I'd agree that XML is a bit better. I'd prefer to use neither. Most of these UI layout formats are essentially complex domain specific languages, paired with IDE support. I don't see any particular need to base them on XML, which was intended for marking up documents.
julius_set 7y ago
All this talk about representing UI elements in either JSON, XML and / or code but what it’s state? How the hell is neatly encapsulated next to the UI in XML and JSON. Dynamic URLs? Dynamic Ids, dynamic image urls?
zmix 7y ago
From their documentation: > HXML does not use CSS. I wonder why? XML is perfectly stylable with CSS. Why not let the user reuse their knowledge? Somewhat canoncial: https://www.w3.org/Style/styling-XML.en.html https://www.w3.org/Style/styling-XML.en.html Also: https://duckduckgo.com/?q=xml+css https://duckduckgo.com/?q=xml+css

261 points by creolabs 7y ago

wiso 7y ago

No mention of XAML.

Swift with SwiftUI proved that XML/JSON/WhatEver is useless if your language is built to facilitate creating DSLs Same for Compose/Kotlin

tasogare 7y ago

The ability to extend an existing element with attributes is super useful in XML. To do an equivalent in JSON is quite ugly.

onion2k 7y ago

No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep, so the file structure used to store the UI data doesn't need to be human-readable. This is true for any data - once you hit a moderate level of complexity neither JSON or XML really work - you need to build a tool to manipulate the underlying data rather than changing it directly. If you do that then it doesn't matter how readable or 'ugly' the data is because a human being shouldn't need to access it directly. This leads to other benefits you can optimize for like size or parsing speed or redundancy instead.

ilogik 7y ago
so we shouldn't write HTML by hand, but instead use WYSIWYG editors?
- onion2k 7y ago
  HTML isn't a UI description. It's a document description. HTML + CSS + [browser behavior|Javascript] is the UI description, and arguably some more complex web apps are getting to the point were they've gone past the point where HTML, CSS, and JS are the best formats for describing the way they work.
  - shantly 7y ago
    They never were the best way. Other application GUI systems are less painful because they were designed for that from the beginning. HTML remains OK for documents, though.
kreco 7y ago
Following what you say we should only have binary format. I think you underestimate the convenience of a text format. It does not only provide a simple way to generate it, but also provide a way to modify it by hand.
- yoz-y 7y ago
  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.
  - DagAgren 7y ago
    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 making a small change to a JSON file, it is entirely legal to reorder every single key, completely destroying the diff, and an automatic tool may very well do this. And as a counter-example, we could easily use a binary representation of JSON data, but use a diffing tool that normalises key ordering to provide diffs that are more readable and understandable than a text diff of a JSON file, even without malicious reordering of lines.
    - gpderetta 7y ago
      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.
- onion2k 7y ago
grepthisab 7y ago
This reminds me of the line of thought from the React community. Make everything as complex as possible (vdoms, etc.). But there are other ways, frameworks, styles to achieve what people want without that level of complexity. A "moderate" level of complexity absolutely does not require special tooling to manipulate underlying data.
Razengan 7y ago
> No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep, so the file structure used to store the UI data doesn't need to be human-readable. I strongly disagree. SwiftUI is fucking amazing. https://developer.apple.com/tutorials/swiftui/ https://developer.apple.com/tutorials/swiftui/ Even with your other comment about "until you hit a moderate level of complexity." People are already creating some complex things with it. In fact, they can be more complex than what you can achieve with traditional frameworks when you consider the time it takes; what takes me a day in UIKit etc. takes me a minute in SwiftUI, so I can quickly move on to the next bit. With declarative UI code I could literally have a usable app in the same time it takes me to struggle with getting separate visual designers + logic editors to agree over a single moderately complex component. Though, it is several layers of abstraction over what really happens behind the scenes, so I guess a part of your point stands.
iainmerrick 7y ago
The other replies cover most of my reaction, but there’s one more thing I want to add: If you have a binary format for a tree structure, you almost always end up accruing garbage as you edit it. That always happens in rich HTML editors, for example. For something like an image editor, the bitmap is OK because it’s not a tree structure and doesn’t balloon out of control as you edit. Where your image is tree-structured, eg Photoshop layers, the editing tool will generally show you the exact layer tree in a sidebar, so you can make sure it stays clean and tidy. It’s easiest to keep it tidy when the canonical source is human-readable text. (Although it’s worth watching out for formatting differences. Something like gofmt helps there.)
whytaka 7y ago
> No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep Yet people do this everyday. So it's not that complex.

sparsely 7y ago

Good article, but for some reason he doesn't mention one the best XML UI systems: WPF.

robbya 7y ago
WPF is Windows Presentation Foundation. https://docs.microsoft.com/en-us/visualstudio/xaml-tools/designing-xaml-in-visual-studio?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/xaml-tools/des...

ChrisMarshallNY 7y ago

The main reason that I use XML (occasionally) is because of XML Schema. It's a very precise data description that can be semantically verified. Otherwise, I try to use JSON, where possible, because I am not a masochist.

arethuza 7y ago
JSON Schema is pretty useful and is well supported by tools like VS Code
laggan 7y ago
I actually found JSON Schema to be FAR FAR FAR easier to use than XML Schema. https://json-schema.org/ https://json-schema.org/
- ChrisMarshallNY 7y ago
  You are correct. I LOATHE XML Schema. I have used it for years, and have never memorized it. I still need to look it up like a n00b, every time I use it. But the simple fact of the matter is, is that so many people and projects have inculcated it into hundreds (if not thousands) of toolsets and specs (Like -Ick- WSDL), that it really is the only viable game. People tend to like JSON precisely because it eschews the kind of overhead that is the definition of XML Schema.
- ChrisMarshallNY 7y ago
  Huh. I just realized that JSON Schema is STILL not a published spec. It is currently in draft, and has been, for a long time.
halfdan 7y ago
Does https://json-schema.org/ https://json-schema.org/ not work for you?
- sacado2 7y ago
  I don't know JSON schema really well; Can you say you want a `price` value to be a non-negative decimal value with at most two digits after the comma, and you want the `currency` value be exactly one of the following : "EUR", "USD", "GBP", the default if not specified being "EUR"?

imvetri 7y ago

This doesn't seem to solve any problem related to UI. Because tree can be converted to a list and vice versa. The added advantage is tree structure is natural. But the way article is put forward is as if using json we cannot achieve tree structure

tobr 7y ago

If XML is better at representing trees, and JSON is a tree, does that mean that XML is better at representing JSON than JSON?

athenot 7y ago
This is reminiscent of the (whimsical) RFC 3252: Binary Lexical Octet Ad-hoc Transport https://www.ietf.org/rfc/rfc3252.txt https://www.ietf.org/rfc/rfc3252.txt
lucideer 7y ago
Yes. Consider a comparison of examples using JSON schema: { "$schema": "http://json-schema.org/draft-04/schema#", "description": "Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'", "definitions": { "schemaArray": { "type": "array", "minItems": 1, "items": { "$ref": "#" } } } ... <schema schema="http://json-schema.org/draft-04/schema#"> <description>Modified JSON Schema draft v4 that includes the optional '$ref' and 'format'</description> <definitions> <schemaArray> <type>array</type> <minItems>1</minItem> <items ref="#" /> </schemaArray> ... $schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. In the XML representation, the distinction is implicit and handled automatically for you by every parser.
- pytester 7y ago
  >$schema and $ref are differentiated by convention in JSON, and require repeated consideration in every parsing scenario to treat them as exceptions relative to actual values within the JSON document. This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. This isn't just a matter of usability, it has security implications because it increases the attack surface of anything that uses it (e.g. the XML billion laughs attack).
  - lucideer 7y ago

chadlavi 7y ago

JSON is a data structure. XML is a text markup. Don't mix them up.

thesuperbigfrog 7y ago
XML is also a transform specification with XSLT (https://en.wikipedia.org/wiki/XSLT https://en.wikipedia.org/wiki/XSLT). XML is also a query language with XQuery (https://en.wikipedia.org/wiki/XQuery https://en.wikipedia.org/wiki/XQuery). XML is also a nested structure path specifier with XPath (https://en.wikipedia.org/wiki/XPath https://en.wikipedia.org/wiki/XPath). XML is also a file format with SVG (https://en.wikipedia.org/wiki/Scalable_Vector_Graphics https://en.wikipedia.org/wiki/Scalable_Vector_Graphics), OpenOffice XML (https://en.wikipedia.org/wiki/OpenOffice.org_XML https://en.wikipedia.org/wiki/OpenOffice.org_XML), OpenDocument (https://en.wikipedia.org/wiki/OpenDocument https://en.wikipedia.org/wiki/OpenDocument), ePUB (https://en.wikipedia.org/wiki/EPUB https://en.wikipedia.org/wiki/EPUB), DocBook (https://en.wikipedia.org/wiki/DocBook https://en.wikipedia.org/wiki/DocBook), and many others (https://en.wikipedia.org/wiki/List_of_XML_markup_languages https://en.wikipedia.org/wiki/List_of_XML_markup_languages). XML is also an data/object serialization format with libraries like Jackson (https://github.com/FasterXML/jackson https://github.com/FasterXML/jackson), YAXLib (https://github.com/sinairv/YAXLib https://github.com/sinairv/YAXLib), Boost (https://www.boost.org/doc/libs/1_38_0/libs/serialization/example/demo_xml.cpp https://www.boost.org/doc/libs/1_38_0/libs/serialization/exa...), Pyxser (https://github.com/dmw/pyxser https://github.com/dmw/pyxser), and many others. XML may not be as elegant as JSON, but it has a wide variety of uses and wide adoption across many programming languages (libraries), and disciplines.
gwbas1c 7y ago
I was going to make the same post, upvoted you instead! What's nice about JSON is that there's very little ambiguity in how to serialize / deserialize data structures. That's what's so powerful about it. As a result, using "magic" serializers with language-native data structures often works well and has little gotchas. In general, I think a lot of people hopped onto the XML bandwagon assuming that it would always sanely translate back and forth between XML and native data structures. This is not the case. When XML is the (cough) "best" format, the underlying data structures of different programs operating on the XML will look extremely different. Furthermore, XML terminology will end up leaking into business logic, because the semantics of the document are inseparable from handling it. In general, I think the biggest sign that XML is the wrong choice is when someone's using a "magic" serializer, or when the data structures very closely follow the document structure. In those cases, JSON was probably a better choice.

castwide 7y ago

I'd expand on his premise by saying that XML beats JSON for structured documents, which also happens to be a practical way to represent a UI layout.

adamlett 7y ago

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 https://www.schnada.de/grapt/eriknaggum-xmlrant.html

mettamage 7y ago
How about simple DSL layouts?
- michaelmior 7y ago
  Do you mean a simple DSL for layouts?
sacado2 7y ago
Well, for instance, let's take the HTML code of your comment (which happens to be a valid XML document): <span class="commtext c00">I have yet to read anything that convinces me that XML is good for <i>anything</i>. 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.<p>See also Erik Naggum's legendary rant: <a href="https://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">https://www.schnada.de/grapt/eriknaggum-xmlrant.html</a></span> What would be the JSON/YAML/TOML equivalent?
- ben509 7y ago
  The HTML doesn't represent the classes properly. The LaTeX would take a simpler approach: \begin{spanned} I have yet to read \textit{anything}... \end{spanned} Since there's no Javascript, probably no need for the class variables. And, of course, you can just write your own macros as you need them.
- ChrisSD 7y ago
  Side note: You've overdone the character entities a bit more than necessary.

mettamage 7y ago

XML is so awesome for UI layouts. I had a thesis that I worked on that was basically a subset of HTML (check the SMIL specification for something similar, albeit a bit more complicated, SMIL used to be a W3C recommendation). It was so easy to understand that every person who was able to use a computer would pick it up quickly. This was not the case for HTML, my guess is because there are a ton of HTML tags and that can be overwhelming for a certain type of audience, whereas here there are at most 10 tags to learn. The framework I'm talking about still exist, it's called XIMPEL [1] (sadly SMIL kind of died). It may seem like a weird thing, but IMO it's the only open-source framework that has an intuitive way to make non-linear storytelling easy on the web easy. People can kind of hack a choose your own adventure media story with YouTube, but XIMPEL really is so much better at it because it's actually made for that purpose. And the biggest reason why XIMPEL is simpel because it uses XML as its template language. People just see the tags as lego blocks and build non-linear media essays, stories or even small (media-focused) games with it. [1] http://www.ximpel.net/ http://www.ximpel.net/

mfer 7y ago
> It was so easy to understand that every person who was able to use a computer would pick it up quickly. I find this hard to believe. I know many people who use computers but are not IT professionals or even hobbyists. Without an easy to use GUI they can't accomplish much. I couldn't imagine them picking up anything to do with XML. If you scope it down to UI developers you're taking less than 1% of people. Far from everyone. Even if you scope it down to IT people it's less than 1% of people.
- swiley 7y ago
  It’s not that they can’t. They’ve just been told they can’t. I’ve been told that clerks at bell labs were using troff because they were told they weren’t programming and I think GUIs have the same opposite effect.
- rescbr 7y ago
  There’s the always forgotten type of computer users: those who use computers for productivity. People who need to achieve some business goal and they have the energy to learn. Take for instance insane Excel spreadsheets glued with VBA powering entire businesses, built by accountants and other professionals.

michaelmior 7y ago

The XML example seemed odd to me as written. In the JSON case, yes there was a prefixed key "$reports", but it told me what the relationship was. Looking at the XML, what does it mean for an Employee to be nested inside another Employee?

jimktrains2 7y ago
Sounds like the list of employees should have been nested in a <reports> and not left directly inside the employee.

hyperman1 7y ago

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 discuss the possibility that the pendulum swung too far?

weberc2 7y ago
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.
- ChrisSD 7y ago
  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.
  - weberc2 7y ago
    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. :)
    - yellowapple 7y ago
      What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments). That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions. ¹: https://man.openbsd.org/pf.conf https://man.openbsd.org/pf.conf ²: https://man.openbsd.org/smtpd.conf https://man.openbsd.org/smtpd.conf ³: https://man.openbsd.org/relayd.conf.5 https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5 https://man.openbsd.org/httpd.conf.5 ⁴: https://otpcl.github.io https://otpcl.github.io

dukoid 7y ago

Another reason why XML might be better for UI Layouts (in addition to typed nodes) is that it allows mixed content, making it more concise in the case where marked up text is included.

dandare 7y ago

I am not familiar with Xcode: is there an easy way to get the exploded 3D view of DOM in a browser? Maybe a browser extension?

nkrisc 7y ago
Firefox used to do this, but looks like they haven't for a while. Guess it's been longer than I thought since I used it. https://developer.mozilla.org/en-US/docs/Tools/3D_View https://developer.mozilla.org/en-US/docs/Tools/3D_View

ivankolev 7y ago

Android UI is xml based and it works relatively well there

whereareyouwow 7y ago

Reminds me of jasonette (https://jasonette.com/ https://jasonette.com/) ... Whether it is JSON or XML, what I particularly like about both approaches is that both are fundamentally HATEOAS (https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS)

sacado2 7y ago

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: <div>The <a href="https://www.json.org/">JSON format</a> was invented by <em>Douglas Crockford</em>.</div> If your document consists mainly in losely structured text with some annotation, you better use XML.

arethuza 7y ago
{ "type": "div", "children": [ "The ", { "type": "a", "attributes": { "href": "https://www.json.org/" 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 ;-)
- m1el 7y ago
  ["div", "The ", ["a", {"href": "https://www.json.org/" https://www.json.org/"}, "JSON format"], " was invented by ", ["em", "Douglas Crockford"], "."]
  - ses1984 7y ago
    Interesting.
  - ilogik 7y ago
    that looks like the JSON documents in AWS's CloudFormation
  - sacado2 7y ago
    Quite readable but it's a hell to parse. The first argument is the name of the element, but what is the second one? If it is a string or an array, it's the first child, but if it's an object, it's the attribute set?

tambourine_man 7y ago

Who would've thunk that different tools excel at different tasks? We need more articles like this, to remember us that we should consider what's best for the task at hand and not what's trendy.

beatgammit 7y ago
Yup, use object notation for passing around objects, use a markup language for markup. It's almost like reading the names gives a hint as to what it was designed for and probably best at. My sniff test is that if you're editing it by hand, JSON is a poor format because you'll want the benefit of a schema or at least a user-friendly format. If you're not, the syntax doesn't really matter so we should evaluate it on technical merits (verbosity, computational complexity for serialization/deserialization, memory footprint, etc). I use: - config file formats for config files (usually TOML or INI format) - data formats for data (JSON, protocol buffers, etc) - markup formats (Markdown, XML/HTML) or code for markup I really don't get why people try to force all use cases onto the same format. Use whatever is well suited for the task, preferring familiarity over unnecessary technical benefits.

wil421 7y ago

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. Exactly. I’ve seen XML with element attributes and child elements all over the pace. No rhyme or reason for any of it. It’s especially bad in older systems. I pushed hard at my last job for the SOA team to build REST/JSON web services. Oracle sold them a product to bridge the gap and they got End Of Life announcements 6 months later! Glad I’m gone.

hagreet 7y ago
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?
- LastMuel 7y ago
  The author makes a case for why it would matter: > XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements). Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes. So, you lose a bit of context in the conversion. Such as: `<Document text="true" />` Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know. Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.
- wil421 7y ago
  It depends on the API of the system. I’ve worked on middleware that would not be able to get an attribute, it lacked the capability. Other systems used JavaScript and it was much easier with JSON See this link on stack exchange[1]. [1] https://stackoverflow.com/questions/17604071/parse-xml-using-javascript https://stackoverflow.com/questions/17604071/parse-xml-using... > //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue; I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.

usrusr 7y ago

The JSON examples are not even valid, the "$reports" properties on department are written as comma separated lists without enclosing array brackets. I guess XML might be perfect for when you can't decide between singular and plural and want to leave the problem to others... Because that's the biggest problem besides charset encoding that JSON helps solving: in JSON, you can be unmistakably clear that a given property is to be interpreted as a list of values, even when the current number is less than two. In XML you can just vaguely communicate that intent with an intermediary "plural element" unless you go full schema. <A><Bs><B/><Bs/><A/> isn't half as clear as {"bs":[{}]} (attributes unrelated to this difference omitted)

underwater 7y ago

I find JSON better for random lookups, and XML good for sequential reads. UI falls into the later basket: start at the root, read the children, etc, etc.

taude 7y ago

Good thing we've had XML defining layouts for many years, despite many of the technologies that used the pattern being dead. XML as a layout definition vs XML as data were topics devs discussed heavily 15 years ago, too. So many Java frameworks used Xml to describe the user interfaces (like JavaServer Faces, early Tapestry, etc.). At one time, I worked with a lot was Adobe Flex which used MXML to define user interfaces [1], don't forget about Microsoft's XAML. It's actually amazing to me how many of Flex's great ideas live on in other frameworks not dependent on the Flash Player, and looking at some modern day React often reminds me if it. [1] http://flex.apache.org/doc-getstarted.html http://flex.apache.org/doc-getstarted.html

marcosscriven 7y ago

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.

moron4hire 7y ago
XML has comments. They are the same as HTML comments. 
- marcosscriven 7y ago
  That was indeed my point - whereas one can't in JSON.
  - moron4hire 7y ago
    I must have read your post three times and still thought you said "and XML". I'm sorry.
- theandrewbailey 7y ago
  What do JSON comments look like?

thequailman 7y ago

While not really JSON, HyperScript[1] is much easier to grok than XML to me. It allows you to define layouts really naturally using standard JS objects. Mithril[2] specifically implements it really well. 1 - https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript 2 - https://mithril.js.org/index.html#dom-elements https://mithril.js.org/index.html#dom-elements

cfv 7y ago

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.

andrekandre 7y ago
it isnt that important for me either, and imo shouldn’t be...BUT when you are in a formal setting, people like to code review, and in that case, in the absence of some special diff tool, people will complain they can’t review your ui changes in github and suddenly your format matters alot more than before

m1el 7y ago

> 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 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")))

mdtusz 7y ago
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.
- wry_discontent 7y ago
  Working with Clojurescript and Reagent (or Hiccup) has ruined JSX for me. It's so verbose and absurdly hard to work with relatively.
  - postalrat 7y ago
    Why is JSX so much more verbose? The end tags?
    - wry_discontent 7y ago
      It's primarily the end tags, yes, but there's also the className shorthand in reagent that's nice. [div.btn.blue.p-4 {:disabled true} "Button Text"]
gambler 7y ago
This reminds me of an old joke about binary XML: <byte> <bit>1</bit> <bit>1</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>1</bit> <bit>1</bit> <bit>0</bit> </byte> >It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm http://m1el.github.io/jsonht.htm It is not concise. Here is an example of a single div tag overhead: ["div",{"class":"some classes"}, ... ] <div class="some classes"> ... </div> Also, it does not represent DOM trees as JSON. It represents DOM trees as S-Exressions encoded via JSON. The s-expression above can be written directly as: (div (class= "some classes") ... ) So why does it need to be wrapped in a format that's verbose, underspecified, doesn't have comments, doesn't have namespaces and doesn't have any notion of metadata?

OskarS 7y ago

You know, when XML looks like this, I don't mind it so much: <Employee name="Michael Scott" title="Regional Manager"> <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> <Employee name="Pam Beesly" title="Office Administrator" /> </Employee> The thing is, XML in the real world never looks like this. In the real world, XML has an avalanche of obscure namespaces, weird "<![CDATA" things, unreadable attributes, incomprehensible structure, and god knows what else. 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.

tomschlick 7y ago
> <Employee name="Dwight Schrute" title="Assistant to the Regional Mgr" /> Fixed that for you :) https://www.youtube.com/watch?v=wA9kQuWkU7I https://www.youtube.com/watch?v=wA9kQuWkU7I
- kbenson 7y ago
  Such a missed opportunity to include Jim in the favorite movies examples with movies like Clear and Present Danger, Patriot Games, etc...
deleted 7y ago
[deleted]
falcolas 7y ago
> 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?

red_admiral 7y ago

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/ https://rachelbythebay.com/w/2019/07/21/reliability/

Rebelgecko 7y ago
Using GSON is great if you're encoding/decoding straightforward data structures. However if you're using it for serialization for more complicated objects (especially with polymorphism!) it gets zany really quickly.

dangerface 7y ago

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

nodamage 7y ago

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. <Button title="blah"/> 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.

gunn 7y ago
It also has the advantage over code that it can be modified with a visual interface designer.
- chooseaname 7y ago
  I'm pretty sure Delphi and VB were famously successful in spite of the fact that they didn't use XML for UI layout.
- nodamage 7y ago
  There's no reason this can't be done with code as well. See: SwiftUI
  - zamalek 7y ago
    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.

jrochkind1 7y ago

I don't disagree that JSON is better than XML for their "list" example,and that XML is better than JSON for their "UI layout" example. BUT: > This means there’s no officially supported way to represent the list of movies in an element attribute. We can hack this by encoding the list into an attribute using a comma delimiter: <Users> <User first="Michael" last="Scott" favoriteMovies="Diehard, Threat Level Midnight" /> So, that's because you're doing it wrong. XML has NO PROBLEM with hieararchy, REALLY. Of COURSE there's a supported way to encode hieararchy. <Users> <User> <first>Michael</first> <last>Scott</last> <favoriteMovies> <title>Diehard</title> <title>Threat Level Midnight</title> </favoriteMovies> </User>

shawabawa3 7y ago
You should have read the next paragraph. They do use that as an example <Users> <User> <FirstName>Michael</FirstName> <LastName>Scott</LastName> <FavoriteMovies> <Movie>Diehard</Movie> <Movie>Threat Level Midnight</Movie> </FavoriteMovies> </User>
- jrochkind1 7y ago
  Fair! Why the heck did the author first try to tell us XML had no "officially supported way" to do this then?
  - Slartie 7y ago
    Because it was about encoding a list of things in an _attribute_. Attribute! Using nested elements is not exactly a solution for that requirement.
wtetzner 7y ago
And if you want, you can still keep some of the attributes: <Users> <User first="Michael" last="Scott"> <favoriteMovies> <title>Diehard</title> <title>Threat Level Midnight</title> </favoriteMovies> </User>

superqd 7y ago

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 manage people - they have that property). But the org chart as XML was anything but obvious to my human eyes, as it was just nested employee elements and at first glance, looked like a single list of employees. Visually interpreting it to know who's a manager, and who reports to whom seems far more difficult in the XML. But, again, it's in the eyes of the beholder, and one person's clean solution is another person's confusing tangle of brackets.

vharuck 7y ago
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.
kgwxd 7y ago
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 a "manager" property.
- superqd 7y ago
  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.

commandlinefan 7y ago

XML also supports id references, which are built into the parser - to my knowledge, there's no JSON equivalent (nor, do I think, could there be).

deleted 7y ago

[deleted]

neves 7y ago

Everybody knows that Yaml is the one true file format!

gagan2020 7y ago

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

bcheung 7y ago

If you are going to make the case for one being better than the other then show the same data in 2 different formats side by side. The article only shows 1 example in 1 format and then moves onto another point. The reader is left to imagine what the difference is in their head.

swsieber 7y ago

I really like the idea of a constrained language for UI declarations, like the angularJS/vue templates and XML instead of UI in code. It makes generating test code for the UIs tractable. Here's my take on what's possible for generating support code for UI tests when the UI is written in a declarative, easily-parseable language: https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-dsls-in-kotlin/ https://samsieber.tech/posts/2019/06/type-safe-e2e-testing-d...

bullen 7y ago

Seems XML is having a revival on HN so I'll just repost my XML editor: I would love to know what people think of my XML node-graph/tree editor I made before JSON became mainstream (my excuse): http://rupy.se/logic.jar http://rupy.se/logic.jar - You link/unlink nodes (I called them entities! Xo) by right-click-dragging between them. - You copy stuff by right-click-dragging to an empty space. - You delete by grabbing something by left-click-holding and pressing the delete key. - Oh, and nodes are completely tree structure expandable, just drag-drop attributes on nodes and nodes inside nodes. (I know, not super intuitive; but very handy once you know about these.) The editor uses lightweight rendering so you can have a ton of elements with good performance.

crooked-v 7y ago

XML is old hat. We should obviously be defining configurations using JSX now.

mwkaufma 7y ago

XML vs JSON (vs code) devolves into bike-shedding because it positions the discussion in the wrong place. Developing layout in plaintext, rather than a WYSIWYG editor, is a priori impedance-mismatched.

adamstep 7y ago

Author here. The meta-point of my post is that different formats have their advantages and disadvantages, and it's good to understand those when deciding on what's appropriate for a given use case. So I'm glad to see a discussion weighing the pros and cons in the thread! I see some comments saying that JSON can represent trees just as well as XML, which is technically true. However, XML natively supports a distinction between node metadata (via properties) and relationships (via child elements) that has to be implied in JSON. For pure-data, this may not matter . But in cases like UI layouts, it's helpful to have the format distinguish between node properties and child components. As others have mentioned, the document use case is also a natural fit for XML by clearly separating the content from markup.

lbruder 7y ago

Where Tk beats everything else. "pack" and "grid" are still way ahead of the established layout stuff. And Tcl is the perfect language for Tk. Sadly people are put off by its seemingly strange syntax and semantics...

unilynx 7y ago

One thing that's contrary to how XML is historically used but helps a lot.. do not use child elements where an attribute suffices: eg, don't do this, from the article: <Users> <User> <FirstName>Michael</FirstName> <LastName>Scott</LastName> <FavoriteMovies> <Movie>Diehard</Movie> <Movie>Threat Level Midnight</Movie> </FavoriteMovies> </User> ... </Users> but write it like this <Users> <User FirstName="Michael" LastName="Scott"> <FavoriteMovies> <Movie Title="Diehard" /> <Movie Title="Threat Level Midnight" /> </FavoriteMovies> </User> ... </Users> Much easier to query for a specific element (eg, try to XPath or CSS Selector query for all of Michael Scott's favourite movies with the first syntax), and the schema is a lot easier to write and reason about (I don't have to wonder if multiple LastNames might be allowed, if I can set a xml:lang attribute on any of them, if the ordering of FirstName and Lastname elements is constrained, etc etc)

teyc 7y ago

Implementations of layout in source code tend to suffer hard-to-diff from a source control point of view. Everytime you move an existing component into a wrapper, the identation breaks how the diff shows up. Perhaps we need a XML formatter that instead of pretty formats, sets the indentation to 0, when we commit code changes. However, that makes the source hard to read. So instead of a diff that reads line - <panel> - <textblock>foo</textblock> - </panel> + <vpanel> + <panel> + <textblock>foo</textblock> + </panel> + </vpanel> We get + <vpanel> <panel> <textblock>foo</textblock> </panel> + </vpanel> Another problem is with the end tags, it is difficult as in the previous example to tell which opening tag an end tag is for. A pretty formatter could solve this problem too. <vpanel id="vertical-wrapper"> <panel id="heading"> <textblock>foo</textblock> </panel> </vpanel> Perhaps the level of indentation could be added visually too <vpanel id="vertical-wrapper">  <panel id="heading">  <textblock>foo</textblock>  </panel>  </vpanel>  but then we bring back the problem of the ugly diffs, gah!

andrewflnr 7y ago
You can pass -b to git diff to get exactly your first result. I would lean toward editor tooling for the latter case, myself.

zeptoon 7y ago

XML in most cases is a pain in the ass to deal with relative to JSON and it isn't new or the rage anymore. A lot of hot technologies initially have this in common. They're so cool and flashy and new that everyone's willing to overlook the actual mechanics of working with them -- for a while. JSON is just more convenient to work with 90-95% of the time, so everyone ends up preferring it and so it tends to win out.

mattsanders 7y ago

This is just a simple case of serialization. Having worked on 10+ game engines and other scene graph based applications I would prefer a more flexible reference based approach. Instead of hard coding your hierarchy into the structure of XML or JSON. Define some basic type information (unique id and node type). If you have situations where an object can be referenced before it is defined simply make a proxy loading type that listens for it to load. After that it is a cakewalk: [ { id: "UUID OR Rolling Number Per File OR DB Index OR ...", type: "business", name: "Dunder Mifflin Paper Company, Inc." description: "look at me I can be a root type for the graph OR one of many!" offices: [ list of ids of objects of type "office" or object that wraps this with other metadata (relation object) ] }, ... potentially other business entries, { id: see above... type: "office", name: "Scranton Branch", description: "This can describe each branch" departments: [ list of ids of objects of type "department" or object that wraps this with other metadata ] }, ... other offices, { id: see above..., type: "department", name: "sales", members: [ list of ids of objects of type "employee" or object that wraps this with other metadata ] }, ... other departments, { id: see above..., type: "employee", title: "manager", name: "Michael Scott", reports: [ list of ids of objects of type "employee" or object that wraps this with other metadata ] }, { id: see above..., type: "employee", title: "sales man", name: "Dwight Schrute", reports: [ id of self since Dwight needs someone he can trust, { id: see above..., type: "report_meta", reportee: id of Pam, visibility: "secret" } ] }, ... other employees, etc., etc. ]

nitwit005 7y ago

If it's purely a choice between XML and JSON, I'd agree that XML is a bit better. I'd prefer to use neither. Most of these UI layout formats are essentially complex domain specific languages, paired with IDE support. I don't see any particular need to base them on XML, which was intended for marking up documents.

julius_set 7y ago

All this talk about representing UI elements in either JSON, XML and / or code but what it’s state? How the hell is neatly encapsulated next to the UI in XML and JSON. Dynamic URLs? Dynamic Ids, dynamic image urls?

zmix 7y ago

From their documentation: > HXML does not use CSS. I wonder why? XML is perfectly stylable with CSS. Why not let the user reuse their knowledge? Somewhat canoncial: https://www.w3.org/Style/styling-XML.en.html https://www.w3.org/Style/styling-XML.en.html Also: https://duckduckgo.com/?q=xml+css https://duckduckgo.com/?q=xml+css