Hacker News Reader

Comment by onion2k | Hacker News Reader

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't need to be human-readable.

This is true for any data - once you hit a moderate level of complexity neither 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't matter how readable or 'ugly' the data is because a human being shouldn't need to access it directly. This leads to other benefits you can optimize for like size or parsing speed or redundancy instead.

View on HN

> 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't need to be human-readable.

I strongly disagree. SwiftUI is fucking amazing.

https://developer.apple.com/tutorials/swiftui/

Even with your other comment about "until you hit a moderate level of complexity." People are already creating some complex things with it. In fact, they can be more complex than what you can achieve with traditional frameworks when you consider the time it takes; what takes me a day in UIKit etc. takes me a minute in SwiftUI, so I can quickly move on to the next bit.

With declarative UI code I could literally have a usable app in the same time it takes me to struggle with getting separate visual designers + logic editors to agree over a single moderately complex component.

Though, it is several layers of abstraction over what really happens behind the scenes, so I guess a part of your point stands.

The other replies cover most of my reaction, but there’s one more thing I want to add:

If you have a binary format for a tree structure, you almost always end up accruing garbage as you edit it. That always happens in rich HTML editors, for example.

For something like an image editor, the bitmap is OK because it’s not a tree structure and doesn’t balloon out of control as you edit.

Where your image is tree-structured, eg Photoshop layers, the editing tool will generally show you the exact layer tree in a sidebar, so you can make sure it stays clean and tidy.

It’s easiest to keep it tidy when the canonical source is human-readable text. (Although it’s worth watching out for formatting differences. Something like gofmt helps there.)

Following what you say we should only have binary format.

I think you underestimate the convenience of a text format.

It does not only provide a simple way to generate it, but also provide a way to modify it by hand.

And have readable and understandable diffs!

One of the biggest issues with the most popular 'tool-only language' (Excel) is that there is no reasonable way to audit changes. Same goes for UIs that are backed by inscrutable file formats.

Readable and understandable diffs is not a property of text files. It is very easy to design tools and formats that use text files, yet do not give you diffs that are readable or understandable.

Readability and understandability depend on more strict requirements that a text file format may or may not have. Many do, but far from all do.

For instance, JSON files do not have requirements on the ordering of keys. When making a small change to a JSON file, it is entirely legal to reorder every single key, completely destroying the diff, and an automatic tool may very well do this.

And as a counter-example, we could easily use a binary representation of JSON data, but use a diffing tool that normalises key ordering to provide diffs that are more readable and understandable than a text diff of a JSON file, even without malicious reordering of lines.

But this means you need diff tools, version control systems and editors (edit: and merge tools) for every single format, which while nice in theory (hey plugins!), in practice doesn't work well. Text is nice because it sort of a minimum common denominator.

Of course semantic diffs would be nice; even, or especially, for code for example but while they do exist they haven't seen much uptake because they do not integrate well with existing tooling.

Following what you say we should only have binary format.

Only if you ignore the bit where I said "once you hit a moderate level of complexity". Text file formats work really well for simple things.

And it's also easier to debug human readable text then it is to debug raw binary. Text is such a good abstraction layer that we almost never have to deal with character encodings, etc. Only problem is that it has to be parsed twice, first from binary to text, then from text to whatever. But computers are good at such tasks, while humans are not.

Yeah I had to hand edit some IOS ui stuff when a version diff caused problems. human readibility even if difficult is beneficial. Useful for generating diffs as well

so we shouldn't write HTML by hand, but instead use WYSIWYG editors?

HTML isn't a UI description. It's a document description. HTML + CSS + [browser behavior|Javascript] is the UI description, and arguably some more complex web apps are getting to the point were they've gone past the point where HTML, CSS, and JS are the best formats for describing the way they work.

They never were the best way. Other application GUI systems are less painful because they were designed for that from the beginning. HTML remains OK for documents, though.

> No one should really be writing UI code by modifying a file by hand because UIs are often complex and deep

Yet people do this everyday. So it's not that complex.

This reminds me of the line of thought from the React community. Make everything as complex as possible (vdoms, etc.). But there are other ways, frameworks, styles to achieve what people want without that level of complexity. A "moderate" level of complexity absolutely does not require special tooling to manipulate underlying data.

Reply on news.ycombinator.com