Thanks

Why not? I'm a Flutter dev, and this might actually be useful for me.

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.

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.

> 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.

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.

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.

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.

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

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.