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

171–180 of 274 posts

Re: When XML Beats JSON: UI Layouts

#171

Post by SigmundA »

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 you have a weird programming language that is hard to debug and remember syntax for, or you could just use a normal programming language, maybe one that supports some declarative constructs.

SwiftUI gives me hope, would like to see something similar show up for the .Net World.

Re: When XML Beats JSON: UI Layouts

#172

Post by kbenson »

vbezhenar wrote: post #154
TomMarius wrote: post #89

Earlier quoted context omitted.

> But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure.

This is tag with name Number and with two attributes. Are you trying to invent XML sublanguage? It's possible. But with JSON it's already invented and there are multiple libraries for every programming language. What should I use to parse your format?

> But with JSON it's already invented

It's inventory and optimized for certain language types, specifically those that are loose with their numeric types. This includes most scripting languages.

In languages that require specific intrinsic types to be defined for a number, there are usually a lot to choose from and using the wrong one can be a real problem when converting from XML or JSON to a native format.

On a very simple level, what container do we use to encode the following data structures:

  [100,4,10,156]

  
    100
    4
    10
    156
In most dynamic languages, hut number type used is just the included numeric container, which generally includes some sort of complex decision between floating point and bignums. For something like C, Java or Rust, generally we would want to choose an appropriate type. In this case, it looks like an unsigned 8-bit integer will suffice for most, and a 16 bit signed value for Java (which doesn't support unsigned values).

But what if the next number is much larger? Should we really need to parse all the values to determine the correct data type to use? That seems very inefficient, and we can't even be sure that we'll encounter values that accurately illustrate the range of values in one parsing. What if the next message or file we parse has large values?

For these languages the inherent data type definition of JSON is a poor match, since its looseness does not transfer easily to a language which does not inherently support it. If your target languages supports dynamicaly resizing untyped arrays, untyped key-value maps, and generic number types that support both very big and floating number types automatically, then JSON is an almost perfect representation format for you. If your target language works best when those items are broken into smaller more explicit components, there's a lot of extra work in parsing JSON, and I can see how that makes XML not look much worse in comparison (especially since your parsed data structure will likely be leaner because there isn't the overhead inherent in those convenient magical types, references are rarely as efficient as pointers).

Re: When XML Beats JSON: UI Layouts

#173

Post by jrochkind1 »

shawabawa3 wrote: post #107
jrochkind1 wrote: post #95

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: So, that's because you're doing it wrong. XML has NO PROBLEM with hieararchy, REALLY. Of COUR…

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?

Re: When XML Beats JSON: UI Layouts

#174

Post by bullen »

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

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

Re: When XML Beats JSON: UI Layouts

#175

Post by warp »

tenaciousDaniel wrote: post #80
nidificate wrote: post #58

Earlier quoted context omitted.

This already exists. They are called custom elements. https://html.spec.whatwg.org/multipage/custom-elements.html#... https://github.com/w3c/webcomponents/ https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

Yep, to some degree. Though what I would love in an xml-based UI description language is the ability to opt into default system behaviors, while maintaining the ability to use whatever semantic naming convention that fits my application. I wrote this code in another comment, but imagine if you could hook functionality to an element via defined attributes. With custom elements, you have to add the functionality via a…

Maybe the is="" attribute gets you partway there?

    
        foo
EDIT: google's documentation: https://developers.google.com/web/fundamentals/web-component...

Re: When XML Beats JSON: UI Layouts

#176

Post by arethuza »

52-6F-62 wrote: post #111
sacado2 wrote: post #103

Earlier quoted context omitted.

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?

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?

Re: When XML Beats JSON: UI Layouts

#177

Post by forgottenpass »

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…

I think qt widgets (not-qml, it's different and I haven't used it) uses XML without many of those problems.

Layouts are trees of widgets. Layouts are themselves widgets so repetition in the tree can be reduced.

You use XML, C++, or both to define a widget. The UI Compiler will turn that XML into C++.

That means further code reuse can leverage the C++ type system. All widgets are QWidgets, and MyProgressBar inherits from QScrollBar.

And you (or, at least I) never write .ui files by hand, they've got a GUI designer tool. And the tool supports your custom widgets by treating them the same as the known widget type it inherits from.

Accessing XML-defined widgets from code is the same as C++ defined widgets, because the compilation step means they are. Class member names come straight from the XML file.

The QObjects are constructed in a way that understands the UI hierarchy, and you can programmatically walk that hierarchy using the variable names. (You do have to tell objects their own names in the non-XML-generated code.)

Re: When XML Beats JSON: UI Layouts

#179

Post by mwkaufma »

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…

"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.
Post reply on HN