>
- User interfaces are very prone to have big files, because there tend to be a lot of different components. I don't get how XML will add more bloat, other than having the tags for defining elements.I disagree that this is an inherent property of user interfaces. In fact I think it's a bit weird that we focus so much on abstractions and when it comes to the code we write (DRY principle, etc), but then when it comes to XML we wave our hands in the air and declare "well that's just the way it has to be".
> - XAML lets you define custom controls. I'm not familiar with Android XML, but in any case it's not an issue of the language but of the framework.
Custom controls allow you to reuse entire widgets, but what about code reuse?
> - Again, a fault of the framework. Visual Studio, for example, checks your XAML for errors, both when writing and when compiling.
No, ultimately it's the fault of the fact that you're trying to shoehorn a bunch of stuff into XML attributes (as strings) that weren't strings to begin with. As I said below, ever make a typo in a binding?
> - I don't think namespaces are confusing (most programming languages have some concept of namespaces), but I agree that one could have more facilities to avoid specifying namespaces everywhere.
This is admittedly worse on Android where almost everything needs to be prefixed with android:, except stuff that comes from the support library, plus these other handfuls of exceptions (which is definitely a framework problem), but even stuff like x:Name vs Name is unnecessarily confusing in WPF.
> - Yes, but most of the time you shouldn't access the user interface from the application code, as coupling them tends to create ugly code that is prone to mistakes and failures. For me, this is an actual advantage of XML for UI, it makes it more difficult to create an interface out of spaghetti code.
That sounds good in theory. In practice, you end up with a lot of code-like constructs in your user interface. Every XAML file I've ever seen is full of bindings, converters and converter parameters, triggers, etc. You might insist this is not code because it lives in an XML file but it sure looks a lot like code to me, just shoehorned into a document language format.
In other words, while we strive hard to avoid spaghetti code, it seem like we don't apply the same principles to avoid spaghetti XML.
> - Well, one is declarative and the other one imperative. As long as you want to have both types, it doesn't matter what language you use.
False dichotomy, IMO. You can build a declarative UI in your code without resorting to XML.
> For me, there's not that much of a difference between SwiftUI/Jetpack Compose and equivalent XML code. UI definitions are going to be messy no matter what.
Have you actually worked with either of these frameworks?