Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When XML Beats JSON: UI Layouts

engineering.instawork.com

Post reply on HN
Print view View original

191–200 of 274 posts

Re: When XML Beats JSON: UI Layouts

#191

Post by jpochtar »

sacado2 wrote: post #41

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: The JSON format was invented by Douglas Crockford . If your document consists mainly in losely structured text with some annotation, you better use XML.

Are you sure you want hierarchy though?

  [
    ["the ", {}],
    ["JSON format", {"link": "https://www.json.org/"}],
    ["was invented by ", {}],
    ["Douglas Crockford", {"bold": true}],
    [".", {}]
  ]

Re: When XML Beats JSON: UI Layouts

#192

Post by 52-6F-62 »

arethuza wrote: post #176
52-6F-62 wrote: post #111

Earlier quoted context omitted.

Maybe something more like: [ "div", [ "The ", [ "a", { "href": "https://www.json.org/" }, [ "JSON format" ] ], " was invented by ", [ "em", "Douglas Crockford" ], "." ] ] With all children being encapsulated in an array... edit: though it again gets confusing when the 0 index is sometimes the element type and sometimes the straight text... so never mind I guess the problem persists.

Why not just: [ "div", "The ", [ "a", { "href": " https://www.json.org/" }, "JSON format" ], " was invented by ", [ "em", "Douglas Crockford" ], "." ] First thing in array is element, if there is an object at the second location then that's the attributes?

Yeah that seems to make the most sense. I had to actually work it out before I saw it. I was looking for some further separation beyond indices but I just ended up over-thinking it.

Re: When XML Beats JSON: UI Layouts

#193

Post by gwbas1c »

chadlavi wrote: post #23

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

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.

Re: When XML Beats JSON: UI Layouts

#194

Post by unilynx »

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:

  
    
      Michael
      Scott
      
        Diehard
        Threat Level Midnight
      
    
    ...
but write it like this

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

Re: When XML Beats JSON: UI Layouts

#195

Post by Touche »

tenaciousDaniel wrote: post #157
Touche wrote: post #135

Earlier quoted context omitted.

You do opt into them, by using label. if you want an element with no behavior, that's what div and span are for.

Right, but this offers two benefits: (1) semantic naming, and (2) composed functionality. So for example, if you wanted an element that exposes label behavior and list-item behavior, you could do that. With html, you have to use 2 elements:

Yes, this is a major flaw of HTML, it is very specific about where certain elements can and cannot be, so you can't really even design a solution like the above.

Re: When XML Beats JSON: UI Layouts

#196

Post by nobleach »

SigmundA wrote: post #171
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…

Its funny WinForms was just code. The designer generated the code or you code do it by hand. You could read it and understand it because it was the same language you used. If there was a problem you could debug it. I never felt more productive than when my UI declaration was just code. Inevitably you need to mix some logic in the layout language and then debug it (For each render this thing, binding syntax etc.) now…

The IDE wrote code and kinda hid it from you in a partial class. And every once in awhile, one would have to get in there and muck around with the generated code. This had the potential to break things pretty badly.

Re: When XML Beats JSON: UI Layouts

#197

Post by pig-disgusting »

jpochtar wrote: post #191
sacado2 wrote: post #41

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: The JSON format was invented by Douglas Crockford . If your document consists mainly in losely structured text with some annotation, you better use XML.

Are you sure you want hierarchy though? [ ["the ", {}], ["JSON format", {"link": "https://www.json.org/"}], ["was invented by ", {}], ["Douglas Crockford", {"bold": true}], [".", {}] ]

A. You forgot to capitalize the first word in the sentence.

B. Your dangling whitespace characters are all wrong.

This tells me that the steps you took to craft the serialized version of the data were totally disconnected from the intent of the transmission.

You were more focused on syntax (decorative array brackets, and curly brace closures), than the human-readable aspects of the text.

More often than not, this is expressed as unclosed tags in XML mark up, which would express as run-on underlined link activation and bold face. Yet this is often cleaner, when formatting gets stripped out, preserving whitespace delimiters such that text us ungarbled.

In the source, this sometimes leads to excessive whitespace bloat, but luxuriously so.

Re: When XML Beats JSON: UI Layouts

#198

Post by SigmundA »

mwkaufma wrote: post #179
SigmundA wrote: post #171

Earlier quoted context omitted.

Its funny WinForms was just code. The designer generated the code or you code do it by hand. You could read it and understand it because it was the same language you used. If there was a problem you could debug it. I never felt more productive than when my UI declaration was just code. Inevitably you need to mix some logic in the layout language and then debug it (For each render this thing, binding syntax etc.) now…

"WinForms was just code" This conflates source text and product. Generated code was _output_ by the WinForms WYSIWYG editor, but the tool stored the layout source in a native project file format.

You could also write forms by hand, the WYSIWYG editor just visually represented the code and modified it using a bunch of metadata (again just .Net attributes) to help the designer.

The GUI designer actually just ran your code to display in the designer, which mostly worked, sometimes it could break if you form relied on runtime dependencies and you could code around that by specifically checking for DesignMode == true in your code.

I am not saying this was perfect but it had a lot of advantages. Now you see SwiftUI and the like going back toward that model.

Re: When XML Beats JSON: UI Layouts

#199

Post by SigmundA »

nobleach wrote: post #196
SigmundA wrote: post #171

Earlier quoted context omitted.

Its funny WinForms was just code. The designer generated the code or you code do it by hand. You could read it and understand it because it was the same language you used. If there was a problem you could debug it. I never felt more productive than when my UI declaration was just code. Inevitably you need to mix some logic in the layout language and then debug it (For each render this thing, binding syntax etc.) now…

The IDE wrote code and kinda hid it from you in a partial class. And every once in awhile, one would have to get in there and muck around with the generated code. This had the potential to break things pretty badly.

Normally didn't do much in the partial class other than reference it.

You could override what it was doing in the main class file though if needed pretty easy. Again if it did break it was just aode and threw a normal exception in the designer, usually revolved around something that didn't work right in DesignMode so you had to check for that explicitly.

Re: When XML Beats JSON: UI Layouts

#200

Post by marcosdumay »

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…

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'll get it naturally in Lisp, you may be able to hack something in Haskell, and you can create a hacky DSP in in Python or Ruby, but if your GUI is in Java, CS, or JS you are out of luck.

> silly typos that won't be caught at compile time

That's a tooling issue. At Python, Ruby or JS you it is inherently more an issue than on XML, at Lisp it will vary with the actual idiom.

> At some point you will need to access your user interface from your application code

> You essentially have to learn two different sets of APIs

Well, that's bad design. There's nothing (except well, a lot of work) stopping a library from making the entire interface manipulation by actions made over XML. Granted, that is much easier and more natural in a DSL or in declarative reflexive code, so you do have a point, but it can be fixed by a lot of polishing over the worse fundamentals.

Post reply on HN