DEV Community

Discussion on: Flutter in 30 Seconds

Collapse
 
nitya profile image
Nitya Narasimhan, Ph.D • Edited

I think React Native stands alone in the category in which it plays - which is that it allows you to

  • build REACTIVE views for mobile apps
  • using JavaScript (familiar to web devs)
  • to deploy to native markets (Android, iOS)

It still is my go-to for many projects and I think it always will be the most competitive amongst current options in that space.

What I have gotten interested in with Flutter is how they are approaching the issue with a different angle. You can build reactive apps, but they are doing things like looking at how you can apply those UI "diffs" (view changes between prev. and curr. page states) not in terms of patches to Physical DOM or Platform widgets, but to the graphics layer directly.

In some sense, their "application space widgets" are completely new components that paint directly to canvas and totally bypass/ignore OEM widgets or any web-view ideas or semantics.

Is that a good thing? I don't know.
Is that different? Yes, absolutely.
Is that going to gain mainstream adoption? Too early to tell.
Is it interesting enough to dive into? Oh yeah! :-)

PS. When I compared it to React Native, I wasn't saying that the main differentiation was performance, but that they were using performance as a reason to throw away all existing patterns for doing things and rethinking UI arch for mobiles from that singular viewpoint. I think for many existing devs, React Native would provide sufficient pattern familiarity + performance gains to still be popular -- but my approach is to always be pragmatic and explore new ideas/thinking

Collapse
 
slmyers profile image
Steven Myers
  • build REACTIVE views for mobile apps

Any UI framework allows for the developer to build reactive views.

Thread Thread
 
nitya profile image
Nitya Narasimhan, Ph.D

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 :-)

Thread Thread
 
slmyers profile image
Steven Myers

I think we might disagree on what qualifies as a framework, but other than that we're on the same page :)

Thread Thread
 
nitya profile image
Nitya Narasimhan, Ph.D

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.