You mention following complex nesting chains through code declarations. I understand what you are talking about, but the (awesome) Flutter tooling now has two views that make this far easier: the Widget Inspector, which lets you see and modify the widget tree at runtime (there was a talk on this at DartConf), and the new Outline view (just released a few days ago), which helps you play with the widget declarations in your code.
See https://flutter.io/inspector/ and https://groups.google.com/forum/#!topic/flutter-dev/lKtTQ-45... (for the outline view)
You can do this in XAML since 2006, and JSP since 2004.
<Button>
<StackPanel>
<Image/>
<TextBlock/>
...
<Button>
<Canvas>
<Ellipse/>
Full disclosure: I work at Microsoft.
Nothing with keyboard-friendly lists, data-grids and trees. And what about "controls"? How come I can't disable the whole form, including tabs and other controls, with just one attribute? Or a panel which can be detached into floating window?
Thats what I would call complex (and useful) widget.
BTW: This is what customers want (checktree, columncombo, dateragepicker, moneyfield with calculator, ...) https://www.tmssoftware.com/site/products.asp?t=vcl
Maybe I don't understand what you're saying, but it can feel almost like advocating for putting everything in one function. Following the execution through all the functions and methods is a nightmare you might say, but the point is not to follow it through all those layers in the vast majority of cases. The point is to enable a higher level of abstraction that means you don't need to look at those lower levels unless you actually have to change something there.
<HorizontalLayout gravity="top">
<MyCustomSideBar id="menu" height="100%"/>
<VerticalLayout gravity="center">
<Text>Enter a starting date for search</Text>
<MyCustomCalendar id="calendar"/>
</VerticalLayout>
</HorizontalLayout>Declarative, high-level structures (like UI definitions in XML or some other data-only format) really do change the paradigm. You can argue that it's not a useful change, but saying "it's all parsed by imperative logic at some point!" is specious.
In terms of a 'change' as you point out, change is a comparison between two points, and when you compare XML to this declarative paradigm, the main difference isn't along the declarative-or-not axis (because they are similar in that regard), but things like programmability (often with 'templates' in XML) or parseability, in which case in-language DSL-likes work really well (you can write, for example, a lambda returning a UI fragment that closes over some parameters, or you can `.map(...)` a UI fragment over a `List`, ...). The change you may be pointing at is against maybe original GTK-like or Android-Java-like imperative constructs, but this discussion is about a Flutter-XML comparison.
Of course, in the Flutter case, the DSL-like is actually just function calls and doesn't involve macros or a separate code generation step.
IOS, Android and any sane application environment have a fully extensible layout and component model to define at compile time.
Say for example on Android I wanted to include a layout but change the text color of all the items in that layout - I can't just do <include text_color="purple">. But I can do pretty much exactly that with React. This is because you can't use variables within layouts like that on Android. Sure, I could build a custom view and add a custom attribute and use that - but this is one of the areas where native isn't as nice as React Native (there are plenty of pain points with RN though).