I've got a pretty large flutter app in production, using just the flutter-provided building blocks like ValueNotifier, ListenableBuilder, InheritedWidget, etc. It has scaled quite well for me.
The main issue IMHO with many of these boilerplate-reducing packages is that they feel like one-way trips. Most of them require a change to widget inheritance, and they all have slightly different syntax and semantics for wiring things up to state changes. This means if you get a few years into a project, migrating away from the package you chose at the beginning will probably be very difficult.
So while the quick example in the readme of this package looks simple and understandable, locking in to a third-party library makes me nervous, especially if the main benefit is just fewer keystrokes. Does anyone have experience or informed opinion here that would be willing to chime in?
I believe that no matter what framework you use, you’ll encounter similar challenges. Every framework introduces its own complexity by nature — the key difference lies in whether its abstraction can reduce the complexity of building sophisticated applications to a manageable level.
To me, the strength of a framework isn’t just about reducing how much code you write — it’s about providing a way of thinking that helps developers build and maintain applications more easily.
For this project, my goal is to fully leverage the composability of Vue’s Composition API and provide automatic dependency tracking to help developers write cleaner and more reactive Flutter applications.
I always thought the usability/ergonomics of the Flutter framework was slightly poor, but the Dart language itself is pretty darn awesome!
I also rolled my own reactivity interfaces, and made many shorthand functional wrappers for standard things I use frequently to debloat the GUI boilerplate.
My stuff isn't robust enough to consistently live seamlessly alongside regular flutter code or to release for anyone elses use.
I am super stoked to see that I'm not the only one to find the stock flutter framework something that can be improved, and that others more confident than me (and more experienced with other frameworks) are putting things like this out there.
Congratulations and thank you.
I even dream that someone would reimagine the entire flutter framework, maybe just reuse some of the low level rendering and eventing but rebuild everything else on top of that.
Apologies to anyone on the flutter team if I sound too critical, you've put something very useful and difficult out there, but a lot of design choices seem to be mutually inconsistent or just have so many counterintuitive aspects to them, usually justified in the name of performance.
I often find myself thinking I am just not smart enough to figure out the right way to do something with flutter. A lot of abstractions that are hard to get them to work how I want or run into weird corner cases. Many simple things I just ask AI to solve it, and after seeing the solution I can see it is right, still don't understand why my attempt was not.... so I welcome alternative interfaces and approaches.
Thanks for the kind words! I came up with this library based on my own experiences — I had a few insights while using these patterns, and decided to turn them into a library.
Flutter chose to design its framework around an approach similar to React, which I think was a deliberate trade-off.
However, I feel that the Dart language itself lacks several important features. For example, we can’t implement JavaScript-like Proxy objects or getters/setters in the same way. This makes it impossible to achieve deeply reactive behavior like what Vue provides.
In addition to Dart being pretty neat, Flutter itself has been a pretty first class citizen then it comes to documentation and developer tooling/experience.
Mobile remains a big surface to integrate and evolve well.
> I always thought the usability/ergonomics of the Flutter framework was slightly poor, but the Dart language itself is pretty darn awesome!
I think a lot of ergonomics issues of the Flutter are because of Dart language lacking in some areas. Flutter team even demonstrated how Flutter is expected to improve when certain features land in Dart. (Not sure if/how cancelation of macros will affects this.)
I'm (im)patiently waiting for augmentations and declaring constructors to be completed. Augmentations alone will help with so many things.
That’s true — they both come from the same foundation of reactivity. As far as I know, in the frontend world, there’s even a saying that React + MobX ≈ Vue.
However, there are still some key differences:
1. MobX’s reactivity in Flutter is based on build_runner, which means it relies on a code generator. This introduces certain limitations, and build_runner itself is often criticized for being cumbersome. In contrast, this framework is built on top of the alien_signals package — a Dart port of one of the fastest reactive libraries in the JavaScript ecosystem — which works entirely at runtime.
2. This framework brings the Composition (or Hook) API into Flutter. I believe this is currently one of the most convenient and intuitive ways to organize and structure application logic.
When there is a change, the setup function is executed and the virtual dom of the component is recomputed. You have no choice because it is a return in a function (setup/build).
But in Vue3, if a ref is only used in an html tag the compiler will optimize it to not recalculate the whole virtual dom.
You’re absolutely right — I haven’t found a good way to make the DOM update at a fine-grained level yet.
However, I still believe this framework has value, mainly for the following reasons:
1. The setup function behaves just like in Vue 3 — it runs only once. This helps avoid the mental overhead found in React’s re-renders.
2. Dependency tracking is fully automatic, eliminating the pain of manually managing dependencies as in React or flutter_hooks.
3. By providing a Composition or Hook-style API, it introduces a new way to organize and structure code in Flutter.
4. While fine-grained DOM updates aren’t possible, a ComputedBuilder is provided, allowing developers to easily control the scope of updates when needed.
Wow this looks absolutely great, I love how concise the finished solutions look and the concept is easy to understand. Keep it up, I'll be following the project's development and would like to see performance benchmarks in the future. Great job!
Regarding performance benchmarks — the framework essentially stands on the shoulders of giants, with its reactivity layer powered by alien_signals. This library originates from one of the fastest reactive implementations in the JavaScript ecosystem, and in Dart’s reactivity benchmarks, it currently ranks as the fastest as well.
I think you've misunderstood. The title did not originally include the text "Show HN". I was suggesting that to the submitter, since they were submitting one of their own projects.
I've got a pretty large flutter app in production, using just the flutter-provided building blocks like ValueNotifier, ListenableBuilder, InheritedWidget, etc. It has scaled quite well for me.
The main issue IMHO with many of these boilerplate-reducing packages is that they feel like one-way trips. Most of them require a change to widget inheritance, and they all have slightly different syntax and semantics for wiring things up to state changes. This means if you get a few years into a project, migrating away from the package you chose at the beginning will probably be very difficult.
So while the quick example in the readme of this package looks simple and understandable, locking in to a third-party library makes me nervous, especially if the main benefit is just fewer keystrokes. Does anyone have experience or informed opinion here that would be willing to chime in?
I believe that no matter what framework you use, you’ll encounter similar challenges. Every framework introduces its own complexity by nature — the key difference lies in whether its abstraction can reduce the complexity of building sophisticated applications to a manageable level.
To me, the strength of a framework isn’t just about reducing how much code you write — it’s about providing a way of thinking that helps developers build and maintain applications more easily.
For this project, my goal is to fully leverage the composability of Vue’s Composition API and provide automatic dependency tracking to help developers write cleaner and more reactive Flutter applications.
I always thought the usability/ergonomics of the Flutter framework was slightly poor, but the Dart language itself is pretty darn awesome!
I also rolled my own reactivity interfaces, and made many shorthand functional wrappers for standard things I use frequently to debloat the GUI boilerplate.
My stuff isn't robust enough to consistently live seamlessly alongside regular flutter code or to release for anyone elses use.
I am super stoked to see that I'm not the only one to find the stock flutter framework something that can be improved, and that others more confident than me (and more experienced with other frameworks) are putting things like this out there.
Congratulations and thank you.
I even dream that someone would reimagine the entire flutter framework, maybe just reuse some of the low level rendering and eventing but rebuild everything else on top of that.
Apologies to anyone on the flutter team if I sound too critical, you've put something very useful and difficult out there, but a lot of design choices seem to be mutually inconsistent or just have so many counterintuitive aspects to them, usually justified in the name of performance.
I often find myself thinking I am just not smart enough to figure out the right way to do something with flutter. A lot of abstractions that are hard to get them to work how I want or run into weird corner cases. Many simple things I just ask AI to solve it, and after seeing the solution I can see it is right, still don't understand why my attempt was not.... so I welcome alternative interfaces and approaches.
Thanks for the kind words! I came up with this library based on my own experiences — I had a few insights while using these patterns, and decided to turn them into a library.
Flutter chose to design its framework around an approach similar to React, which I think was a deliberate trade-off.
However, I feel that the Dart language itself lacks several important features. For example, we can’t implement JavaScript-like Proxy objects or getters/setters in the same way. This makes it impossible to achieve deeply reactive behavior like what Vue provides.
In addition to Dart being pretty neat, Flutter itself has been a pretty first class citizen then it comes to documentation and developer tooling/experience.
Mobile remains a big surface to integrate and evolve well.
I couldn’t agree more.
> I always thought the usability/ergonomics of the Flutter framework was slightly poor, but the Dart language itself is pretty darn awesome!
I think a lot of ergonomics issues of the Flutter are because of Dart language lacking in some areas. Flutter team even demonstrated how Flutter is expected to improve when certain features land in Dart. (Not sure if/how cancelation of macros will affects this.)
I'm (im)patiently waiting for augmentations and declaring constructors to be completed. Augmentations alone will help with so many things.
I agreed.
Sounds like MobX (for Dart) https://mobx.netlify.app/ (and GetIt, for the DI)
That’s true — they both come from the same foundation of reactivity. As far as I know, in the frontend world, there’s even a saying that React + MobX ≈ Vue.
However, there are still some key differences:
1. MobX’s reactivity in Flutter is based on build_runner, which means it relies on a code generator. This introduces certain limitations, and build_runner itself is often criticized for being cumbersome. In contrast, this framework is built on top of the alien_signals package — a Dart port of one of the fastest reactive libraries in the JavaScript ecosystem — which works entirely at runtime.
2. This framework brings the Composition (or Hook) API into Flutter. I believe this is currently one of the most convenient and intuitive ways to organize and structure application logic.
How is that better than a ValueListenable/ValueListenableBuilder?
I believe there are several improvements in this approach:
1. Interdependent reactive states – multiple dependencies can now be related and work together seamlessly.
2. Automatic dependency tracking – updates are triggered only when minimal changes occur, ensuring efficient reactivity.
3. Composition or Hook APIs – provide a new and cleaner way to structure and organize code logic.
This reminds me of react more than vue.
When there is a change, the setup function is executed and the virtual dom of the component is recomputed. You have no choice because it is a return in a function (setup/build).
But in Vue3, if a ref is only used in an html tag the compiler will optimize it to not recalculate the whole virtual dom.
Or shall I say, vue with jsx
You’re absolutely right — I haven’t found a good way to make the DOM update at a fine-grained level yet.
However, I still believe this framework has value, mainly for the following reasons:
1. The setup function behaves just like in Vue 3 — it runs only once. This helps avoid the mental overhead found in React’s re-renders.
2. Dependency tracking is fully automatic, eliminating the pain of manually managing dependencies as in React or flutter_hooks.
3. By providing a Composition or Hook-style API, it introduces a new way to organize and structure code in Flutter.
4. While fine-grained DOM updates aren’t possible, a ComputedBuilder is provided, allowing developers to easily control the scope of updates when needed.
Wow this looks absolutely great, I love how concise the finished solutions look and the concept is easy to understand. Keep it up, I'll be following the project's development and would like to see performance benchmarks in the future. Great job!
Thank you for the support!
Regarding performance benchmarks — the framework essentially stands on the shoulders of giants, with its reactivity layer powered by alien_signals. This library originates from one of the fastest reactive implementations in the JavaScript ecosystem, and in Dart’s reactivity benchmarks, it currently ranks as the fastest as well.
You can check out the benchmark results here: https://github.com/medz/dart-reactivity-benchmark
Should this be a Show HN?
Why not? I'm a Flutter dev, and this might actually be useful for me.
I think you've misunderstood. The title did not originally include the text "Show HN". I was suggesting that to the submitter, since they were submitting one of their own projects.
Sorry about that — I changed the title after reading the comment.
-
Is it not the poster's own creation?
Username checks out.
Thanks