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.
The IDE wrote code and kinda hid it from you in a partial class. And every once in awhile, one would have to get in there and muck around with the generated code. This had the potential to break things pretty badly.
Normally didn't do much in the partial class other than reference it.
You could override what it was doing in the main class file though if needed pretty easy. Again if it did break it was just aode and threw a normal exception in the designer, usually revolved around something that didn't work right in DesignMode so you had to check for that explicitly.
If you use F#, Fabulous[1] for mobile apps and Fable+Elmish[2][3] for web exist. I use Giraffe's[4] view engine for server-side HTML templating. And it looks like AvaloniaUI is going to have a similar style UI in FuncUI[5], but I'm not sure how active that is.
"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.
You could also write forms by hand, the WYSIWYG editor just visually represented the code and modified it using a bunch of metadata (again just .Net attributes) to help the designer.
The GUI designer actually just ran your code to display in the designer, which mostly worked, sometimes it could break if you form relied on runtime dependencies and you could code around that by specifically checking for DesignMode == true in your code.
I am not saying this was perfect but it had a lot of advantages. Now you see SwiftUI and the like going back toward that model.
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.