Live data from Hacker News

When XML Beats JSON: UI Layouts

engineering.instawork.com

211–220 of 274 posts

Re: When XML Beats JSON: UI Layouts

#211

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…

Not only that, XML actually diffs poorly -- line-by-line diffing of the sort git does makes it hard to see that a single attribute was changed in a long line.

Re: When XML Beats JSON: UI Layouts

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

Re: When XML Beats JSON: UI Layouts

#213

Earlier quoted context omitted.

You should have read the next paragraph. They do use that as an example Michael Scott Diehard Threat Level Midnight

Fair! Why the heck did the author first try to tell us XML had no "officially supported way" to do this then?

Because it was about encoding a list of things in an _attribute_. Attribute! Using nested elements is not exactly a solution for that requirement.

Re: When XML Beats JSON: UI Layouts

#214
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.
]

Re: When XML Beats JSON: UI Layouts

#215

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 lea…

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.

Re: When XML Beats JSON: UI Layouts

#216

Earlier quoted context omitted.

> 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 bei…

>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? I think that's more of an indictment of HTTP than XML or JSON. Maybe we should have a better standard for exchanging non-textual data with websites.

No it's not. It's because people like to just pipe it into same request framework, get a json object and then later do base64_decode(json["binaryobject"]) instead of a separate http request to do binary transport which it can already do.

Re: When XML Beats JSON: UI Layouts

#217

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…

- The verbosity is easily addressed by using an IDE which providing smart folding, highlighting, etc...

- Editing XML is actually a lot easier than JSON. Thanks to XML schemas, completion works really well in XML and very poorly (if at all) in JSON.

- Also, XML allows comments, which JSON doesn't.

- You don't need `findViewById()` in 2019 and haven't in a while, really: there are plenty of alternatives available (synthetic accessors, Kotlin, ButterKnife, etc...).

Re: When XML Beats JSON: UI Layouts

#218

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…

The moment we added JSON schema (not to mention JSON transforms) and started to create a JSON version of XPath, we started down the same path that hurt XML. Throw in parsers that all act differently (some parse comments, some don’t), and processing directives, and it becomes clear that yes, the pendulum has swung too far.

> The moment we added JSON schema

There is an amazing JSON schema syntax out there, 100% better than the official one. It is called TypeScript, and I am sad that the TS compiler can't be made to pop out JSON validators (their philosophy being nothing at all runtime).

There is a project (I forget its name) that will insert itself into your build steps and use TS type definitions to validate JSON.

Seriously the TS syntax is great, why is anything else being used to write a schema?

The only thing I'd add to the TS syntax is the proposals to add field validation using regexs, or some type of field name validation format. There are times when TS can't model my JS objects, e.g. I have a bunch of GUID field names that map to objects of a certain type, and I have some other field names that are 100% not GUIDs, I promise, mapping to some other stuff.

Re: When XML Beats JSON: UI Layouts

#219
post #71

Earlier quoted context omitted.

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.

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

TOML is what I'd naturally write as notes if I wanted to document how something is working.

YAML is all sorts of strange.

JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!

Re: When XML Beats JSON: UI Layouts

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

Post reply on HN