Hacker News Reader

Comment by codedokode | Hacker News Reader

Honestly this looks like programming style from 90s. Why not design UIs in an editor that saves layout to XML?

Machine generated XML doesn’t play nice with version control for views that are even moderately complex. Merge conflicts become more of a nightmare to untangle as your app matures, plus it can make pull requests unintelligible.

This is part of why for apple platform dev, several years ago I abandoned XML-based XIB and storyboard UI design for any collaborative project. Writing it all out in code (even with just UIKit, no SwiftUI) is a lot more pain-free.

I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework… Jetpack Compose improves the situation some but I’ve not used it much yet.

> but Google is hellbent on the XML usage if you’re building with Android Framework

That said, folks rarely use the GUI editor for Android XML and managing merges isn't as painful, or really painful at all, when compared to XIBs/storyboards.

Also, as you mentioned, Jetpack Compose obviates that and every new Android view should use it IMO.

Absolutely. XML is rarely a good solution for any problem, and usually the worst.

> I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework…

For sure the Android API is oriented towards building GUIs in XML, but it's actually quite possible to build your Android GUI in Java code.

When I started developing for Android, I took a look at a few tutorials and said "no way", searched the web for how to build Android GUIs programmatically, and never looked back.

This example shows off the builder style, but since gtk-rs is built on top of GTK, .ui XML files are also supported. You can edit .ui files using the legacy Glade editor (with a conversion script), the newer (but incomplete) Cambalache project, or by hand (it's not that hard and this seems to be the preferred way nowadays)

https://gtk-rs.org/gtk4-rs/stable/latest/book/composite_temp...

I guess we have come the full circle.

Speaking from a mobile dev's perspective, the native UI design in 2010s was done by XML based files (storybooks in iOS/macOS, XML layout files in Android) and native code would "connect" with the XML files in various ways. Now the development is moving towards declarative approach using frameworks such as SwiftUI and Compose.

This builder pattern resembles quite a bit of how you would declare UI in SwiftUI and Compose.

> Why not design UIs in an editor that saves layout to XML?

It's funny because that's my personal nightmare. I'm a JS to Rust developer so I'm biased but the likes of React and Svelte have spoiled me with the ease with which you can integrate reactive components into a UI in a way that you simply can't when you're using a separate XML file.

I agree that the example given looks old-school but Rust has a wonderful macro system, I can imagine building a really slick compose method with macros that generates this kind of code underneath.

> Why not design UIs in an editor that saves layout to XML?

Not sure if you are being sarcastic or not, but nothing is more 90s than XML based layout descriptions. Mozilla XUL (recently retired) comes to mind.

XUL needs to be resurrected (reimplemented)

I've never seen the appeal of those "write your UI in a different language than the logic and deal with the interference layer" style of GUI development. But I also think that UI builders tend to produce bad code and ugly layouts when you go beyond CRUD apps that would have been easy to write in the declarative style anyway.

One argument I've heard for this model is that, by having the UI in a declarative language, the design team can update/experiment with the layout without having to understand the backing logic. I've only been on one team that actually subscribed to this model though.

I've heard this, but in practice it is hard to fully decouple the interface from the logic so experimentation with the front end usually involves work on the back end. Even simple changes like "we want to change this drop down to a set of radio buttons" ends up requiring changes on the back end most of the time.

I think good tooling support is a requirement for this to work; the one project I used this in (a Silverlight app) had first-class support for this. You could specify separate ViewModels for run time and design time, and the latter would just return static values that the designer could work against. I guess this would require some cursory understanding of C# syntax, but I think the ramp-up for adding/modifying a property would be minimal.

In a project with many developers, it's hard to resolve conflicts with generated XML. For example, iOS and Android have been moving towards a declarative approach with Swift UI / Compose.

XML? That's so ... turn of the century.

Thankfully the industry has mostly woken up from the collective nightmare that was XML.

But apparently a few poor souls are still painfully asleep.

xml is dated and gross

I really like XML a lot; I've gotten large numbers of people to use XML & XSLT, where I work. XML is dated, and it is gross. Here's the two things the XML ecosystem nailed, which tie me to it:

1. A dedicated tree-based transformation language (XSL); and,

2. Axis-queries (Xpath).

If I could Xpath all-the-things, I'd be a happier human. Although, I also feel like I should be able to SQL all-the-things, too. Maybe I'm just a sucker for structured-data query-languages?

XSLT is garbage tho.

XSLT the syntax leaves a bit to be desired. There's also a number of highly questionable default behaviors that are really unfortunate. OTOH, the concept of a term-rewriting tree-matching language is pretty great.

Also namespaces. When you need them, you really need them.

Replace xml with anything else. You're not writing XML. It's just a format used by a layout editor. The issue with this strategy is merge conflicts and diffs that make little sense to a human reviewer.

Reply on news.ycombinator.com