[kbumsik]

Actually reactivity in GUI (maybe declarative GUI programming is a more accurate form?) is also "the old way" in the GUI development. I mean it is already done a decade ago, even before react. Try QML. The view is automatically updated when a signal is triggered or its state changes.

You will notice that it is surprisingly simpler than React.

React got so popular because React implemented it very nicely in the web browsers, not because it brought new concepts.

[realharo]

Last time I looked at QML (a few years ago), you couldn't just use any data in your UI directly, you had to wrap it in clunky models.

When using C++, looks like you have to use things like QAbstractListModel https://qmlbook.github.io/ch16-qtcpp/qtcpp.html#a-simple-mod...

Even without C++, there are things like ListModel and ListElement https://qmlbook.github.io/ch07-modelview/modelview.html

This is a far cry from React where you just use language-native data structures directly (you only need to do mutations in specific ways).

As far as I can tell, you also can't just use native language constructs like functions/ifs/.map, etc. to compose the UI elements. Instead you have containers like Repeater.

It seems very different to me compared to React, like built around a significantly different philosophy.

[asveikau]

Your comment seems to just be highlighting the fact that inspecting types at runtime is non-idiomatic at best in C++ or similar languages, so it would make sense to require a specific data structure or format.

Even defining what a "native" type is seems like it would be fraught. I guess the c++ way would be to accept begin and end iterators - but of what type?

[realharo]

I don't think I understand how RTTI/reflection relates to this.

When I imagine how a C++ implementation of something like React would look, my first thought is a bunch of functions which take whatever custom types they need (props), and return a tree of UI primitives (analogous to DOM element representations). Nothing that would require inspecting types.

[asveikau]

And that works in other languages because you can iterate through trees and properties without needing to specify how to iterate through them or how they are stored.

Think about it. How do you iterate the tree? What even is a tree? The typical c++ answer depends on templates and iterators within the template. Which means they wildly change at compile time. It is clumsy for a shared library to deal with this, or, say, bind properties from an XML file or similar parsed at runtime.

Hence, it would make sense for a c++ solution to impose its own format or base class for trees or models. (Perhaps a template could help to wrap it.)

[realharo]

I'm thinking of a structure similar to https://reactjs.org/blog/2015/12/18/react-components-element...

There may be some limitations and some things may need to be done differently because of C++, but from a brief look it should be basically possible. The UI library doesn't need to iterate through props, those can be a single opaque structure from its point of view.

I tried doing something similar in Kotlin a few years back and from what I remember there wasn't any reflection used for that part. https://github.com/peterholak/mogul

[ptx]

That Kotlin project looks pretty cool! What happened to it – was there some fundamental problem, or just lack of time?

[sinni800]

The .NET Framework, specifically the WinForms and the WebForms did that. Of course you could change everything manually, but DataBinding was a core concept which relied on changing data to change the contents of the GUI.

WPF still has the same kind of approach and to be terribly honest, Silverlight, as hated as it was, did it before React.

[sunebeck]

Oh, I see - I take my comment back then :-)