I can't edit my comments (only the main post) so I can try to clarify my intent here.
That statement was meant to say it allows you to do "ALL the three listed things" in one technology solution. So for instance there are other reactive UI frameworks which are not competitive here because they are not in JS, or they don't target deployment to native Android/iOS.
That said, I don't think "any" UI framework by implies "reactive by default". Let me explain my thinking here though.
To me, reactive is the about automatic state change propagation through the framework without the developer explicitly coding that propagation. Instead, developers focus on making local state changes in a component and handling change notifications from parents/children of that component -- with the framework effectively figuring out whether a local state change requires external propagation, and ensuring that those change notifications are triggered/pushed accordingly.
So for instance, when I think about my projects using jQuery UI and classic MVC/MVVM architectures (e.g., in modern Android), I would consider those to be frameworks with support for layout, rendering, data-binding etc. - but I wouldn't consider them reactive by default because any state changes that needed to propagate outside my current view, had to be done by me explicitly (imperative approach) and that added complexity.
But you have a valid point too. Any UI framework does "allow" developers to build reactive views. It's a question of whether the framework supports automated state change detection & propagation, or simply provides the developer with a mechanism (e.g., pub/sub) and requires them to manage the process imperatively.
I hope that helped clarify what I was trying to say though :-)
I am absolutely happy to agree with you on that one :-)
I have long since realized that my usage of terminology [framework, platform, middleware, architecture] are not necessarily the best in context, so I always try to provide the context for clarification. So thank you! I am sure others had similar feedback but didn't venture to express it - and hopefully this helps them as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I can't edit my comments (only the main post) so I can try to clarify my intent here.
That statement was meant to say it allows you to do "ALL the three listed things" in one technology solution. So for instance there are other reactive UI frameworks which are not competitive here because they are not in JS, or they don't target deployment to native Android/iOS.
That said, I don't think "any" UI framework by implies "reactive by default". Let me explain my thinking here though.
To me, reactive is the about automatic state change propagation through the framework without the developer explicitly coding that propagation. Instead, developers focus on making local state changes in a component and handling change notifications from parents/children of that component -- with the framework effectively figuring out whether a local state change requires external propagation, and ensuring that those change notifications are triggered/pushed accordingly.
So for instance, when I think about my projects using jQuery UI and classic MVC/MVVM architectures (e.g., in modern Android), I would consider those to be frameworks with support for layout, rendering, data-binding etc. - but I wouldn't consider them reactive by default because any state changes that needed to propagate outside my current view, had to be done by me explicitly (imperative approach) and that added complexity.
But you have a valid point too. Any UI framework does "allow" developers to build reactive views. It's a question of whether the framework supports automated state change detection & propagation, or simply provides the developer with a mechanism (e.g., pub/sub) and requires them to manage the process imperatively.
I hope that helped clarify what I was trying to say though :-)
I think we might disagree on what qualifies as a framework, but other than that we're on the same page :)
I am absolutely happy to agree with you on that one :-)
I have long since realized that my usage of terminology [framework, platform, middleware, architecture] are not necessarily the best in context, so I always try to provide the context for clarification. So thank you! I am sure others had similar feedback but didn't venture to express it - and hopefully this helps them as well.