TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

When XML Beats JSON: UI Layouts

261 pointsby marcobambiniover 5 years ago

50 comments

nodamageover 5 years ago
At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake.<p>- For starters, it&#x27;s overly verbose. If you&#x27;ve worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated.<p>- 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.<p>- Editing XML kind of sucks. You&#x27;re more at risk of making silly typos that won&#x27;t be caught at compile time.<p>- XML namespaces make an already verbose language even more verbose, not to mention just generally confusing.<p>- 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.<p>- You essentially have to learn two different sets of APIs which do the same thing. <i>&lt;Button title=&quot;blah&quot;&#x2F;&gt; vs button.setTitle(&quot;blah&quot;)</i>. Why?<p>The only real strengths of XML are that 1) it&#x27;s declarative, 2) it&#x27;s hierarchical, and 3) it&#x27;s diffable. But code can be too, without all of these other drawbacks.<p>Fortunately it seems like the industry is starting to figure this out with things like SwiftUI and Jetpack Compose. I really think we&#x27;re going to look back in a few years and think it was ridiculous that we used to do this stuff in XML.
评论 #21398159 未加载
评论 #21398010 未加载
评论 #21400650 未加载
评论 #21399693 未加载
评论 #21399870 未加载
评论 #21397902 未加载
评论 #21398901 未加载
评论 #21403671 未加载
评论 #21399074 未加载
评论 #21400963 未加载
评论 #21403600 未加载
评论 #21403359 未加载
评论 #21406125 未加载
评论 #21404585 未加载
评论 #21407787 未加载
评论 #21398539 未加载
评论 #21401736 未加载
评论 #21404519 未加载
评论 #21404162 未加载
评论 #21402867 未加载
评论 #21400565 未加载
评论 #21397605 未加载
评论 #21397971 未加载
OskarSover 5 years ago
You know, when XML looks like this, I don&#x27;t mind it so much:<p><pre><code> &lt;Employee name=&quot;Michael Scott&quot; title=&quot;Regional Manager&quot;&gt; &lt;Employee name=&quot;Dwight Schrute&quot; title=&quot;Ass. Regional Mgr&quot; &#x2F;&gt; &lt;Employee name=&quot;Jim Halpert&quot; title=&quot;Head of Sales&quot;&gt; &lt;Employee name=&quot;Andy Bernard&quot; title=&quot;Sales Rep&quot; &#x2F;&gt; &lt;Employee name=&quot;Phyllis Lapin&quot; title=&quot;Sales Rep&quot; &#x2F;&gt; &lt;&#x2F;Employee&gt; &lt;Employee name=&quot;Pam Beesly&quot; title=&quot;Office Administrator&quot; &#x2F;&gt; &lt;&#x2F;Employee&gt; </code></pre> The thing is, XML in the real world <i>never looks like this</i>. In the real world, XML has an avalanche of obscure namespaces, weird &quot;&lt;![CDATA&quot; things, unreadable attributes, incomprehensible structure, and god knows what else.<p>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.
评论 #21398394 未加载
评论 #21397546 未加载
评论 #21397549 未加载
评论 #21404784 未加载
评论 #21398815 未加载
m1elover 5 years ago
&gt; JSON for lists, XML for trees No. JSON is a recursive data structure that can represent trees as well.<p>It&#x27;s easy to make a concise representation of DOM trees as JSON: <a href="http:&#x2F;&#x2F;m1el.github.io&#x2F;jsonht.htm" rel="nofollow">http:&#x2F;&#x2F;m1el.github.io&#x2F;jsonht.htm</a><p>I find it really sad that people don&#x27;t know or consider s-expressions to represent trees.<p><pre><code> (Department {:name &quot;Scranton Branch&quot;} (Employee {:name &quot;Michael Scott&quot; :title &quot;Regional Manager&quot;} (Department {:name &quot;Sales&quot;} (Employee {:name &quot;Dwight Schrute&quot; :title &quot;Ass. Regional Mgr&quot;}) (Employee {:name &quot;Jim Halpert&quot; :title=&quot;Head of Sales&quot;} (Employee {:name &quot;Andy Bernard&quot; :title=&quot;Sales Rep&quot;}) (Employee {:name &quot;Phyllis Lapin&quot; :title=&quot;Sales Rep&quot;}))) (Employee {:name &quot;Pam Beesly&quot; :title &quot;Office Administrator&quot;)))</code></pre>
评论 #21403464 未加载
评论 #21398100 未加载
评论 #21404843 未加载
sacado2over 5 years ago
What XML is also very good at is: representing tagged text, what is called &quot;mixed content&quot; in XML terminology.<p>Just try to write the JSON equivalent of:<p><pre><code> &lt;div&gt;The &lt;a href=&quot;https:&#x2F;&#x2F;www.json.org&#x2F;&quot;&gt;JSON format&lt;&#x2F;a&gt; was invented by &lt;em&gt;Douglas Crockford&lt;&#x2F;em&gt;.&lt;&#x2F;div&gt; </code></pre> If your document consists mainly in losely structured text with some annotation, you better use XML.
评论 #21397301 未加载
评论 #21397361 未加载
评论 #21401142 未加载
评论 #21406207 未加载
评论 #21398703 未加载
评论 #21397510 未加载
评论 #21397344 未加载
评论 #21397368 未加载
hyperman1over 5 years 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.<p>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.<p>This is only 1 article, but maybe the world is ready to discuss the possibility that the pendulum swung too far?
评论 #21397497 未加载
评论 #21397207 未加载
评论 #21402782 未加载
mettamageover 5 years 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).<p>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.<p>The framework I&#x27;m talking about still exist, it&#x27;s called XIMPEL [1] (sadly SMIL kind of died). It may seem like a weird thing, but IMO it&#x27;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&#x27;s actually made for that purpose. And the biggest reason why XIMPEL is simpel because it uses XML as its template language.<p>People just see the tags as lego blocks and build non-linear media essays, stories or even small (media-focused) games with it.<p>[1] <a href="http:&#x2F;&#x2F;www.ximpel.net&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.ximpel.net&#x2F;</a>
评论 #21397125 未加载
评论 #21397089 未加载
jrochkind1over 5 years ago
I don&#x27;t disagree that JSON is better than XML for their &quot;list&quot; example,and that XML is better than JSON for their &quot;UI layout&quot; example. BUT:<p>&gt; 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:<p><pre><code> &lt;Users&gt; &lt;User first=&quot;Michael&quot; last=&quot;Scott&quot; favoriteMovies=&quot;Diehard, Threat Level Midnight&quot; &#x2F;&gt; </code></pre> So, that&#x27;s because you&#x27;re doing it wrong. XML has NO PROBLEM with hieararchy, REALLY. Of COURSE there&#x27;s a supported way to encode hieararchy.<p><pre><code> &lt;Users&gt; &lt;User&gt; &lt;first&gt;Michael&lt;&#x2F;first&gt; &lt;last&gt;Scott&lt;&#x2F;last&gt; &lt;favoriteMovies&gt; &lt;title&gt;Diehard&lt;&#x2F;title&gt; &lt;title&gt;Threat Level Midnight&lt;&#x2F;title&gt; &lt;&#x2F;favoriteMovies&gt; &lt;&#x2F;User&gt;</code></pre>
评论 #21397767 未加载
评论 #21397869 未加载
tobrover 5 years 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?
评论 #21396981 未加载
评论 #21396860 未加载
评论 #21400875 未加载
评论 #21397132 未加载
superqdover 5 years 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 &quot;clean&quot; code or &quot;clean&quot; structure even more subjective than ever.<p>The JSON version of the employee org chart is much more semantic and human understandable (to me) as it &quot;cleanly&quot; describes the relationship for reports as a property called &quot;reports&quot; (for those who manage people - they have that property).<p>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&#x27;s a manager, and who reports to whom seems far more difficult in the XML.<p>But, again, it&#x27;s in the eyes of the beholder, and one person&#x27;s clean solution is another person&#x27;s confusing tangle of brackets.
评论 #21398653 未加载
评论 #21398013 未加载
tambourine_manover 5 years ago
Who would&#x27;ve thunk that different tools excel at different tasks?<p>We need more articles like this, to remember us that we should consider what&#x27;s best for the task at hand and not what&#x27;s trendy.
评论 #21403594 未加载
cfvover 5 years ago
XML also has a LONG history of being used for UI in stuff like QT, which is great.<p>The one problem I see is that as developers, we shouldn&#x27;t give a rat&#x27;s ass about the otuput format&#x27;s readability when compared to the API ergonomics. If the API for describing the UI is good enough (Can I do stuff like &quot;App.Transition(App.findOne(Sidebar), 500, {width:&quot;1%&quot;}, {width:&quot;30%&quot;}, Ease.EASE_IN_OUT)&quot; 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.
评论 #21402374 未加载
taudeover 5 years ago
Good thing we&#x27;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&#x27;t forget about Microsoft&#x27;s XAML.<p>It&#x27;s actually amazing to me how many of Flex&#x27;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.<p>[1] <a href="http:&#x2F;&#x2F;flex.apache.org&#x2F;doc-getstarted.html" rel="nofollow">http:&#x2F;&#x2F;flex.apache.org&#x2F;doc-getstarted.html</a>
sparselyover 5 years ago
Good article, but for some reason he doesn&#x27;t mention one the best XML UI systems: WPF.
评论 #21397563 未加载
wil421over 5 years ago
Having worked with SOAP&#x2F;XML extensively at my past job I can say for web services I much prefer REST&#x2F;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.<p>&gt; However, we’ve created another problem in the form of inconsistency: some user properties are represented as element attributes, others as child elements.<p>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.<p>I pushed hard at my last job for the SOA team to build REST&#x2F;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.
评论 #21397423 未加载
评论 #21398239 未加载
评论 #21398105 未加载
marcosscrivenover 5 years 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.
评论 #21397793 未加载
ChrisMarshallNYover 5 years ago
The main reason that I use XML (occasionally) is because of XML Schema. It&#x27;s a very precise data description that can be semantically verified.<p>Otherwise, I try to use JSON, where possible, because I am not a masochist.
评论 #21396836 未加载
评论 #21396839 未加载
评论 #21397066 未加载
red_admiralover 5 years ago
I&#x27;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].<p>JSON is so easy to get started with. Some of this is precisely because of the lack of schema.<p>In Java with the GSON library, encoding&#x2F;decoding is one function call and for the things I&#x27;ve been doing this just works at least 90% of the time. I&#x27;ve managed to add a JSON option to several endpoints in an application in something like 1-2 hours, including writing tests.<p>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&#x27;s not so much a fault of XML as a format, as of the whole &quot;enterprise&quot; tooling that we were asked to use around it. I really hope that this has got easier now.<p>It&#x27;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.<p>[1] <a href="https:&#x2F;&#x2F;rachelbythebay.com&#x2F;w&#x2F;2019&#x2F;07&#x2F;21&#x2F;reliability&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rachelbythebay.com&#x2F;w&#x2F;2019&#x2F;07&#x2F;21&#x2F;reliability&#x2F;</a>
评论 #21403018 未加载
adamstepover 5 years ago
Author here. The meta-point of my post is that different formats have their advantages and disadvantages, and it&#x27;s good to understand those when deciding on what&#x27;s appropriate for a given use case. So I&#x27;m glad to see a discussion weighing the pros and cons in the thread!<p>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&#x27;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.
castwideover 5 years ago
I&#x27;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.
bullenover 5 years ago
Seems XML is having a revival on HN so I&#x27;ll just repost my XML editor:<p>I would love to know what people think of my XML node-graph&#x2F;tree editor I made before JSON became mainstream (my excuse): <a href="http:&#x2F;&#x2F;rupy.se&#x2F;logic.jar" rel="nofollow">http:&#x2F;&#x2F;rupy.se&#x2F;logic.jar</a><p>- You link&#x2F;unlink nodes (I called them entities! Xo) by right-click-dragging between them.<p>- You copy stuff by right-click-dragging to an empty space.<p>- You delete by grabbing something by left-click-holding and pressing the delete key.<p>- Oh, and nodes are completely tree structure expandable, just drag-drop attributes on nodes and nodes inside nodes.<p>(I know, not super intuitive; but very handy once you know about these.)<p>The editor uses lightweight rendering so you can have a ton of elements with good performance.
onion2kover 5 years 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&#x27;t need to be human-readable.<p>This is true for any data - once you hit a moderate level of complexity <i>neither</i> 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&#x27;t matter how readable or &#x27;ugly&#x27; the data is because a human being shouldn&#x27;t need to access it directly. This leads to other benefits you can optimize for like size or parsing speed or redundancy instead.
评论 #21396748 未加载
评论 #21396897 未加载
评论 #21396654 未加载
评论 #21396633 未加载
评论 #21396912 未加载
评论 #21396666 未加载
dukoidover 5 years 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.
thequailmanover 5 years 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.<p>1 - <a href="https:&#x2F;&#x2F;github.com&#x2F;hyperhype&#x2F;hyperscript" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hyperhype&#x2F;hyperscript</a><p>2 - <a href="https:&#x2F;&#x2F;mithril.js.org&#x2F;index.html#dom-elements" rel="nofollow">https:&#x2F;&#x2F;mithril.js.org&#x2F;index.html#dom-elements</a>
dangerfaceover 5 years ago
&gt; XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.<p>Who says this? XML is a great general markup language that every one all ready knows, it&#x27;s a perfectly valid choice for most things, please use it.<p>Just don&#x27;t make yet another bloated outdated markup language like YAML, any &quot;optimisations&quot; turn out to be opinion that doesn&#x27;t justify the time spent learning a new language.<p>Do you really want to be known as the guy that made YAML? No you don&#x27;t.
whereareyouwowover 5 years ago
Reminds me of jasonette (<a href="https:&#x2F;&#x2F;jasonette.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jasonette.com&#x2F;</a>) ...<p>Whether it is JSON or XML, what I particularly like about both approaches is that both are fundamentally HATEOAS (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;HATEOAS" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;HATEOAS</a>)
teycover 5 years ago
Implementations of layout in source code tend to suffer hard-to-diff from a source control point of view.<p>Everytime you move an existing component into a wrapper, the identation breaks how the diff shows up.<p>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.<p>So instead of a diff that reads line<p><pre><code> - &lt;panel&gt; - &lt;textblock&gt;foo&lt;&#x2F;textblock&gt; - &lt;&#x2F;panel&gt; + &lt;vpanel&gt; + &lt;panel&gt; + &lt;textblock&gt;foo&lt;&#x2F;textblock&gt; + &lt;&#x2F;panel&gt; + &lt;&#x2F;vpanel&gt; </code></pre> We get<p><pre><code> + &lt;vpanel&gt; &lt;panel&gt; &lt;textblock&gt;foo&lt;&#x2F;textblock&gt; &lt;&#x2F;panel&gt; + &lt;&#x2F;vpanel&gt; </code></pre> 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.<p>A pretty formatter could solve this problem too.<p><pre><code> &lt;vpanel id=&quot;vertical-wrapper&quot;&gt; &lt;panel id=&quot;heading&quot;&gt; &lt;textblock&gt;foo&lt;&#x2F;textblock&gt; &lt;&#x2F;panel&gt;&lt;!-- heading --&gt; &lt;&#x2F;vpanel&gt;&lt;!-- vertical-wrapper --&gt; </code></pre> Perhaps the level of indentation could be added visually too<p><pre><code> &lt;vpanel id=&quot;vertical-wrapper&quot;&gt; &lt;!-- vertical-wrapper --&gt; &lt;panel id=&quot;heading&quot;&gt; &lt;!-- heading --&gt; &lt;textblock&gt;foo&lt;&#x2F;textblock&gt; &lt;!-- textblock --&gt; &lt;&#x2F;panel&gt; &lt;!-- --&gt; &lt;&#x2F;vpanel&gt; &lt;!-- --&gt; </code></pre> but then we bring back the problem of the ugly diffs, gah!
评论 #21402317 未加载
mattsandersover 5 years 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.<p>Instead of hard coding your hierarchy into the structure of XML or JSON. Define some basic type information (unique id and node type).<p>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.<p>After that it is a cakewalk:<p>[<p>{<p><pre><code> id: &quot;UUID OR Rolling Number Per File OR DB Index OR ...&quot;, type: &quot;business&quot;, name: &quot;Dunder Mifflin Paper Company, Inc.&quot; description: &quot;look at me I can be a root type for the graph OR one of many!&quot; offices: [ list of ids of objects of type &quot;office&quot; or object that wraps this with other metadata (relation object) ] }, ... potentially other business entries, { id: see above... type: &quot;office&quot;, name: &quot;Scranton Branch&quot;, description: &quot;This can describe each branch&quot; departments: [ list of ids of objects of type &quot;department&quot; or object that wraps this with other metadata ] }, ... other offices, { id: see above..., type: &quot;department&quot;, name: &quot;sales&quot;, members: [ list of ids of objects of type &quot;employee&quot; or object that wraps this with other metadata ] }, ... other departments, { id: see above..., type: &quot;employee&quot;, title: &quot;manager&quot;, name: &quot;Michael Scott&quot;, reports: [ list of ids of objects of type &quot;employee&quot; or object that wraps this with other metadata ] }, { id: see above..., type: &quot;employee&quot;, title: &quot;sales man&quot;, name: &quot;Dwight Schrute&quot;, reports: [ id of self since Dwight needs someone he can trust, { id: see above..., type: &quot;report_meta&quot;, reportee: id of Pam, visibility: &quot;secret&quot; } ] }, ... other employees, etc., etc. ]</code></pre>
usrusrover 5 years ago
The JSON examples are not even valid, the &quot;$reports&quot; properties on department are written as comma separated lists without enclosing array brackets.<p>I guess XML might be perfect for when you can&#x27;t decide between singular and plural and want to leave the problem to others...<p>Because that&#x27;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 &quot;plural element&quot; unless you go full schema.<p><pre><code> &lt;A&gt;&lt;Bs&gt;&lt;B&#x2F;&gt;&lt;Bs&#x2F;&gt;&lt;A&#x2F;&gt; </code></pre> isn&#x27;t half as clear as<p><pre><code> {&quot;bs&quot;:[{}]} </code></pre> (attributes unrelated to this difference omitted)
bcheungover 5 years 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.<p>The article only shows 1 example in 1 format and then moves onto another point.<p>The reader is left to imagine what the difference is in their head.
swsieberover 5 years ago
I really like the idea of a constrained language for UI declarations, like the angularJS&#x2F;vue templates and XML instead of UI in code. It makes generating test code for the UIs tractable.<p>Here&#x27;s my take on what&#x27;s possible for generating support code for UI tests when the UI is written in a declarative, easily-parseable language: <a href="https:&#x2F;&#x2F;samsieber.tech&#x2F;posts&#x2F;2019&#x2F;06&#x2F;type-safe-e2e-testing-dsls-in-kotlin&#x2F;" rel="nofollow">https:&#x2F;&#x2F;samsieber.tech&#x2F;posts&#x2F;2019&#x2F;06&#x2F;type-safe-e2e-testing-d...</a>
chadlaviover 5 years ago
JSON is a data structure. XML is a text markup. Don&#x27;t mix them up.
评论 #21397257 未加载
评论 #21401242 未加载
adamlettover 5 years ago
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&#x27;t mean that there aren&#x27;t other better options.<p>See also Erik Naggum&#x27;s legendary rant: <a href="https:&#x2F;&#x2F;www.schnada.de&#x2F;grapt&#x2F;eriknaggum-xmlrant.html" rel="nofollow">https:&#x2F;&#x2F;www.schnada.de&#x2F;grapt&#x2F;eriknaggum-xmlrant.html</a>
评论 #21397165 未加载
评论 #21397597 未加载
评论 #21397021 未加载
ivankolevover 5 years ago
Android UI is xml based and it works relatively well there
zmixover 5 years ago
From their documentation:<p>&gt; HXML does not use CSS.<p>I wonder why? XML is perfectly stylable with CSS. Why not let the user reuse their knowledge?<p>Somewhat canoncial: <a href="https:&#x2F;&#x2F;www.w3.org&#x2F;Style&#x2F;styling-XML.en.html" rel="nofollow">https:&#x2F;&#x2F;www.w3.org&#x2F;Style&#x2F;styling-XML.en.html</a><p>Also: <a href="https:&#x2F;&#x2F;duckduckgo.com&#x2F;?q=xml+css" rel="nofollow">https:&#x2F;&#x2F;duckduckgo.com&#x2F;?q=xml+css</a>
nitwit005over 5 years ago
If it&#x27;s purely a choice between XML and JSON, I&#x27;d agree that XML is a bit better. I&#x27;d prefer to use neither.<p>Most of these UI layout formats are essentially complex domain specific languages, paired with IDE support. I don&#x27;t see any particular need to base them on XML, which was intended for marking up documents.
michaelmiorover 5 years ago
The XML example seemed odd to me as written. In the JSON case, yes there was a prefixed key &quot;$reports&quot;, 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?
评论 #21397122 未加载
lbruderover 5 years ago
Where Tk beats everything else. &quot;pack&quot; and &quot;grid&quot; 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...
imvetriover 5 years ago
This doesn&#x27;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.<p>But the way article is put forward is as if using json we cannot achieve tree structure
julius_setover 5 years ago
All this talk about representing UI elements in either JSON, XML and &#x2F; 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?
crooked-vover 5 years ago
XML is old hat. We should obviously be defining configurations using JSX now.
mwkaufmaover 5 years 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.
underwaterover 5 years 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.
commandlinefanover 5 years ago
XML also supports id references, which are built into the parser - to my knowledge, there&#x27;s no JSON equivalent (nor, do I think, could there be).
wisoover 5 years ago
No mention of XAML.
dandareover 5 years 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?
评论 #21397341 未加载
gagan2020over 5 years ago
Yes, XML flavor beats JSON in UI layouts. We call that flavor HTML.
nevesover 5 years ago
Everybody knows that Yaml is the one true file format!
tasogareover 5 years ago
The ability to extend an existing element with attributes is super useful in XML. To do an equivalent in JSON is quite ugly.
zeptoonover 5 years ago
XML in most cases is a pain in the ass to deal with relative to JSON and it isn&#x27;t new or the rage anymore. A lot of hot technologies initially have this in common. They&#x27;re so cool and flashy and new that everyone&#x27;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.
unilynxover 5 years ago
One thing that&#x27;s contrary to how XML is historically used but helps a lot.. do not use child elements where an attribute suffices:<p>eg, don&#x27;t do this, from the article:<p><pre><code> &lt;Users&gt; &lt;User&gt; &lt;FirstName&gt;Michael&lt;&#x2F;FirstName&gt; &lt;LastName&gt;Scott&lt;&#x2F;LastName&gt; &lt;FavoriteMovies&gt; &lt;Movie&gt;Diehard&lt;&#x2F;Movie&gt; &lt;Movie&gt;Threat Level Midnight&lt;&#x2F;Movie&gt; &lt;&#x2F;FavoriteMovies&gt; &lt;&#x2F;User&gt; ... &lt;&#x2F;Users&gt; </code></pre> but write it like this<p><pre><code> &lt;Users&gt; &lt;User FirstName=&quot;Michael&quot; LastName=&quot;Scott&quot;&gt; &lt;FavoriteMovies&gt; &lt;Movie Title=&quot;Diehard&quot; &#x2F;&gt; &lt;Movie Title=&quot;Threat Level Midnight&quot; &#x2F;&gt; &lt;&#x2F;FavoriteMovies&gt; &lt;&#x2F;User&gt; ... &lt;&#x2F;Users&gt; </code></pre> Much easier to query for a specific element (eg, try to XPath or CSS Selector query for all of Michael Scott&#x27;s favourite movies with the first syntax), and the schema is a lot easier to write and reason about<p>(I don&#x27;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)