First, i just wanted to say that my last post was quite negative. I don’t intend to devalue projects that follow a paradigm i don’t like, so i’ll answer this post and try to expand a little bit.
I haven’t worked with react native specifically yet (but have worked with toolkits that are comparable in this regard), so take this with a grain of salt:
The problem is that this prohibits a lot of the stuff some applications need. Many applications tweak native components (often that happens through subclassing, and that does not fit into this model). Native components on different platforms may be not equivalent for all the usecases of a specific application.
If an application fits into the common denominator of all standard UI-components and no further control is needed, this can work out great. But i cannot imagine writing a complex, UI-heavy program like a digital audio workstation or an image manipulation program that way.
Side note: maybe this is in indicator that the problem space of this discussion is underspecified. What are the programs that our hypothetical GUI-framework should enable?
I’ve worked with QT for a few years for a job, and i’ve a ton of appreciation for the project. But it just never looks quite right… a little bit like the uncanny valley. That can be jarring or even confusing, when a component that mimics a native one behaves differently in subtle ways. Also, like you said, it’s an unholy amount of work.
If a project like QT, with all their resources and all their expertise cannot pull it off properly, i’d wouldn’t want to try it…
On a general note: Maybe i should backtrack a little bit. One of the assumptions i made, but didn’t specify, is that rust niche in the desktop space is more in the “complex” territory. I don’t see the “wrapper around common native components” approach work for that, but there is certainly some areas where thats the right solution.
On an even more general note: “We” hackers and computer scientist love abstraction and slicing up the problem space into neatly separated sections where elegant solutions can be found. But (in my experience) UIs, information design, layout in general and similar problems don’t let you do that. Content cannot be separated from the form it’s presented in, form easily (mis-)communicates as much as the content itself and delightful UI-solutions may require unreasonable amounts of customisation. Imo applications should be able to do that.