dart_eval VS hydro-sdk

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

There is already a project trying to bring Typescript into Flutter, but its on early development: https://github.com/hydro-sdk/hydro-sdk This will also probably create many extra pains for developers since existing Dart packages would have to be wrapped.

It's probably vastly more trouble than it's worth, but you could technically write the package in Typescript and use Hydro SDK to compile it to Lua bytecode that can run on the Dart VM with Flutter bindings, then distribute that bytecode with a package that wraps the Hydro API.

As an open source author, I've been thinking about some general and domain specific optimizations https://github.com/hydro-sdk/hydro-sdk/issues/797 I'd love to chat if OP has time.

In terms of interoperability, the short answer is mostly-yes. Any Dart code can be made to interoperate with code written using Hydro. Taking an existing Dart package and making it useable from Hydro is automated. The tooling isn't quite ready for prime time (nor is the entire SDK) https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid

Hydro-SDK has a small Dart-like language built into it to support binding generation (https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid/frontend/swidi).

The analyzer API is enormous. I've had a lot of success using the analyzer API, but abstracting over it with my own ASTs that can be manipulated and transformed (https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid) and using code builder (https://github.com/dart-lang/code_builder) to emit Dart code.

I've been having a lot of fun writing a compiler in Dart (in a pure functional style, with pattern matching and sum types!) over here https://github.com/hydro-sdk/hydro-sdk/tree/master/lib/swid