dart_eval VS flutter_eval

...which is what xml_layout and dart_eval are there for. However, at that point I wouldn't call it "writing Flutter applications in Rust" any more (which of course is just a subjective interpretation).

I also want to note that dart_eval now has over 100 tests running in CI! If you're interested in contributing to the project, writing even more tests might be one of the easier places to start - head on over to the GitHub repo and don't be shy to ask any questions.

Check out dart_eval

I learned about this because I wrote dart_eval lol. I'm sure there is a less time-consuming way, maybe some intro to programming tutorials would teach it. But tbh I don't think it's critical to know to be a good programmer.

I've been working for a few years now on dart_eval, the pure-Dart interpreter for Dart with a focus on interop (that's also now super fast :D). While dart_eval has technically been usable in Flutter apps for a while, actually doing so was pretty painful and definitely didn't meet the ultimate goal of enabling simple, automatic code push.

Maintaining this support was of course a high priority and it's also received a full rewrite, making it both easier to use than ever and also with a significantly reduced performance cost. Of course interop performance will still be better using wrappers if you don't need to extend the class, and code push support continues to evolve with the addition of runtime overrides (see previous link).

If you want to understand how it works, I think a good place to start learning would be to learn about how programming languages work in general - like what is a 'declaration' vs 'expression' vs 'statement' and then maybe see if you can understand the contributing document?

But for Flutter users looking for code-push, v0.6 represents an even larger overhaul in usability. While previous versions allowed you to easily execute a single piece of code dynamically, there was no straightforward way to achieve partial updates, caching, native fallbacks, or to update multiple parts of your app separately. In v0.6, the new HotSwap and HotSwapLoader widgets combined with dart_eval's revamped runtime-override system resolve this entirely. It now takes just 10 minutes to set up your existing app for a full incremental, self-hosted hot-swap code push pipeline where any widget or page can be granularly updated over-the-air. HotSwap automagically falls back to your app's default implementation on a per-component level when there is no update available, so adding it to your app comes at zero performance cost, and even if you choose to update one component the rest of your app can remain running at full AOT-compiled native speed. It also caches updates locally by default, so users see changes immediately when they restart the app. The step-by-step setup process for this is available in the flutter_eval README under "Quickstart for code push".

Another suggestion is more documentation on how to support a particular widget. For example, editable_text, why TextEditingController is there, but EditableText is not.