When XML Beats JSON: UI Layouts • Hacker News Board

Re: When XML Beats JSON: UI Layouts

#261

Post by pytester » Thu, Oct 31, 2019, 10:42 AM UTC

lucideer wrote: post #188

pytester wrote: post #34

Earlier quoted context omitted.

>$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 su…

> This is a good thing. The main issue with XML is how ridiculously overcomplicated and overengineered its design was. Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space, instead of the parser (so your app is more complex to handle it). > e.g. the XML billion laughs attack Also not a g…

>Citing element attributes as an example of such complexity is hardly reasonable. The JSON example above contains the same complexity, just moved to the application/implementation space

Where it belongs...

>so your app is more complex to handle it

There is a trade off between more simple markup and more complex code and vice versa. I would argue it is almost always better that way around because it helps enforce clear separation of concerns. I'm similarly allergic to putting complex logic in template code because that also violates a clear separation of concerns.

>Also not a great example. This is a simple DOS attack, of which there are many other examples: zip bombs, yaml bombs, etc.

This is precisely why it's a great example. YAML has the same problem with overcomplexity XML does. JSON has no such issues.

>There are also far worse attacks on XML than the billion laughs attack (XXE attacks are an entire category in the OWASP top 10).

Right, billion laughs is part of a class of security vulnerabilities that are enabled by XML's bloated design.

>The difference is, since references aren't built into the JSON spec, you have to do it yourself

Except you don't. I'm not sure if I've ever implemented references in any JSON schema I've ever used. It's an entirely pointless feature as far as I'm concerned. I've seen them used in YAML (where it's equally yucky) and every time it's been used it's been as a band aid over deficient schema design that also inadvertently made the markup harder to understand.

>By your own metric, JSON is actually "more complex" (in a good way) than XML in one area: value types. XML values are strings. Having value types is one massive advantage of JSON imo.

I hardly think having 4/5 scalar types counts as spec overcomplication. If you want a measure of how complex each markup language is simply look at the length of the respective specifications. XML is ridiculous.

Re: When XML Beats JSON: UI Layouts

#262

Post by Too » Thu, Oct 31, 2019, 12:04 PM UTC

nodamage wrote: post #90

At this point I am convinced that the decision to define UI layouts in XML instead of code has been a terrible mistake. - For starters, it's overly verbose. If you've worked with stuff like XAML in WPF or XML layouts on Android, you know how quickly those files tend to get bloated. - It does not lend itself well to reuse compared to, well, actual code. Which means there tends to be a lot of repetition. Which leads to…

UI frameworks that expose a findViewById function could be considered anti patterns in the first place. For a declarative view the dependency should go the other way around with the view reactivelly accessing the viewmodel, instead of (accidentally) embedding UI boilerplate in your business logic. To react on UI changes in your logic you can add listeners to changes made on the viewmodel. See jQuery vs react/angular/vue for best example of the difference.

Android Jetpack also tries to bridge the gap of this in android, even though here you manually have to write some glue code yourself to create this reactive layer.

Re: When XML Beats JSON: UI Layouts

#263

Post by m1el » Thu, Oct 31, 2019, 1:24 PM UTC

gambler wrote: post #220

m1el wrote: post #78

> JSON for lists, XML for trees No. JSON is a recursive data structure that can represent trees as well. It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm I find it really sad that people don't know or consider s-expressions to represent trees. (Department {:name "Scranton Branch"} (Employee {:name "Michael Scott" :title "Regional Manager"} (Department {:name "Sales"} (…

This reminds me of an old joke about binary XML: 1 1 0 1 0 1 1 0 >It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm It is not concise. Here is an example of a single div tag overhead: ["div",{"class":"some classes"}, ... ] ... 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 d…

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

Because the OP article doesn't even consider s-expressions, so I'm working with the tools I was given.

Personally, I find it frustrating that EDN (or some other form of s-exprs) aren't widely adopted.

Re: When XML Beats JSON: UI Layouts

#264

Post by ChrisMarshallNY » Thu, Oct 31, 2019, 2:00 PM UTC

laggan wrote: post #18

ChrisMarshallNY wrote: post #10

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.

I actually found JSON Schema to be FAR FAR FAR easier to use than XML Schema. https://json-schema.org/

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.

Re: When XML Beats JSON: UI Layouts

#265

Post by adamlett » Thu, Oct 31, 2019, 2:08 PM UTC

sacado2 wrote: post #118

adamlett wrote: post #77

Earlier quoted context omitted.

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

That's a very good point. Thing is, markdown (or a subset of it, as on HN) is very limited. Great for short comments, bad when you want to do something a little more complex, like a blog post (I always end up addding some HTML here and there in my markdown blog posts, when I want to include a video for instance). The other problem is that HN comments and all those markdown-like formats are very ad hoc . If I copy/pas…

So, the context would be: an export format for complex, multi-paragraphs textual documents with meta-information.

If you add the condition that it be human-readable, I admit I am not able to point to an existing format that is obviously better suited for this than XML.

Re: When XML Beats JSON: UI Layouts

#266

Post by ChrisMarshallNY » Thu, Oct 31, 2019, 2:25 PM UTC

laggan wrote: post #18

ChrisMarshallNY wrote: post #10

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.

I actually found JSON Schema to be FAR FAR FAR easier to use than XML Schema. https://json-schema.org/

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.

Re: When XML Beats JSON: UI Layouts

#267

Post by otabdeveloper4 » Thu, Oct 31, 2019, 2:48 PM UTC

gambler wrote: post #220

m1el wrote: post #78

> JSON for lists, XML for trees No. JSON is a recursive data structure that can represent trees as well. It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm I find it really sad that people don't know or consider s-expressions to represent trees. (Department {:name "Scranton Branch"} (Employee {:name "Michael Scott" :title "Regional Manager"} (Department {:name "Sales"} (…

This reminds me of an old joke about binary XML: 1 1 0 1 0 1 1 0 >It's easy to make a concise representation of DOM trees as JSON: http://m1el.github.io/jsonht.htm It is not concise. Here is an example of a single div tag overhead: ["div",{"class":"some classes"}, ... ] ... 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 d…

Not specified enough, I think you mean:

Re: When XML Beats JSON: UI Layouts

#268

Post by bryanrasmussen » Thu, Oct 31, 2019, 3:44 PM UTC

nwallin wrote: post #239

bryanrasmussen wrote: post #182

Earlier quoted context omitted.

What UI framework using XML is there where you can end up making silly typos that won't be caught at compile time? Or basically any sort of typo? I would expect any decent XML UI framework is going to have some sort of validation schema defined which will be quite stringent as to what is allowed at a particular level. Not that I like XML Schema.

I'm only familiar with XAML+WPF+C#+VS. One particular pet peeve of mine is the fact that it won't catch typos in data binding. If I have IsEnabled={Path IsEnabeld} in my XAML, the designer won't catch it. At runtime, the error is silently ignored. It just doesn't work, and no tooling, nothing other than triple checking every line of code will catch it. Also it's really bad about picking up dependencies cross package,…

ok thanks, I was just thinking of elements and attribute names as being important.

Re: When XML Beats JSON: UI Layouts

#269

Post by marcosdumay » Thu, Oct 31, 2019, 3:51 PM UTC

nodamage wrote: post #236

marcosdumay wrote: post #200

Earlier quoted context omitted.

There are languages and languages here, and your mileage will actually vary by orders of magnitude. As people already pointed, code isn't inherently declarative or non-verbose. Some of the most popular languages for creating GUIs (Java, JS, C#) aren't either. > It does not lend itself well to reuse There isn't any inherent feature for code that will enable the kind of reuse you need when declaring a GUI either. You'l…

Yes I agree that building declarative UIs in code does require language support and some languages are not well suited to it. But I think this is an area where we could see real improvement and we should want our tooling to evolve to better handle these problems.

Oh, I completely agree that UI declared by code has much more potential than a frozen approach like UI declared in XML. It's only that presently, it's not a clear win.

Re: When XML Beats JSON: UI Layouts

#270

Post by zamalek » Thu, Oct 31, 2019, 6:00 PM UTC

nodamage wrote: post #243

zamalek wrote: post #142

Earlier quoted context omitted.

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

> Designers would most likely be familiar with XML given their HTML background, but they wouldn't necessarily know C#. I am really curious how often XAML has been used by a designer who didn't know C#. Most of the XAML I've seen (in non-trivial apps) has a lot of code-like constructs in it. If you don't know what's going on under the hood, how are going to correctly declare your data bindings (for example)?

> Most of the XAML I've seen (in non-trivial apps) has a lot of code-like constructs in it.

Those code-like constructs are UI behavior (e.g. how to transition from checked to unchecked for a checkbox). While they do take learning, they are not strictly code.

Also, Expression Blend can interact with every part of XAML in full-fidelity. Designers need not worry about the code-like parts of XAML at all.

> If you don't know what's going on under the hood

I suppose the workflow is that the design team would log a ticket for the development team, who would expose said binding and add it to the UI as a placeholder. I'm not sure exactly how this is supposed to work, but Microsoft did have a project which combined Unity and WPF to solve this exact workflow (I forget the name), and they were using it internally.

---

Personally, I can see the benefit as I do work at a product company. Developers get bugs pretty often to do with "element X is 1 pixel off," usually from the design team (one designer was known to open screenshots in paint to measure distances). If you can empower the designers to just create real UIs instead of mockups, it would get done correctly in the first place. Vue SFCs come close to achieving this, but fall short in terms of state (you still need JS to add/remove CSS classes).

Either way, it isn't fair to compare Swift UI to XAML as Swift UI doesn't seem to attempt to solve this at all (even if XAML doesn't solve it perfectly). Swift UI is closer to System.Windows.Forms.