Iced: 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?