Declarative DSL for creating views

[olanod]

I was checking out vgtk to prototype a quick Gtk UI which follows the same elm architecture story and thought declaring widgets with the gtk! macro is kinda nice, a declarative way for defining pieces of UI is much nicer. Any thoughts? I don't know what the implications of a macro like that would be on iced, if following a similar approach as vgtk's I suspect that a macro that returns a new tree of widgets would require the virtual dom approach for diffing changes and render accordingly?

[hecrj]

Personally, I am not fond of using DSLs to solve this particular problem. I think they:

• Introduce a learning barrier. You no longer need to know only Rust, but the DSL too and all its quirks.
• Reinvent the wheel. View code is rarely a simple declarative tree. Most of the time, there is complex logic involved. You may need to conditionally show something, build a list out of some values in your state, etc. This either forces these DSLs to implement their own programming language, or allow embedding parts of native code.
• Feel like magic. You no longer see the actual code, which makes it harder to reason about.
• Solve a non-existent problem. Boring code and low-maintenance boilerplate are not worthy of a complex abstraction.
• Hide actual issues. Instead of focusing on building simple APIs in the programming language of the library, the focus shifts towards building an abstraction to actually avoid writing in that language. Rust is great! Why avoid writing it? Is something verbose? Create helper functions! Is there duplication of concerns? Use traits or build your own widgets!

a declarative way for defining pieces of UI is much nicer

Could you maybe elaborate a bit on this? Why do you think it's nicer? What do you think we can improve when we compare our current approach with the vgtk approach?