hydro-sdk VS Avalonia

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

You might also want to look at AvaloniaUI[0] for a cross platform .NET GUI library. It is similar to WPF but much nicer to work with.

[0] https://github.com/AvaloniaUI/Avalonia

Production user here. There's no money gotchas. They're above reproach. In fact, I've received considerable free support from their devs on GitHub Issues [1].

The Avalonia business model is based on selling XPF, which runs WPF (Windows-only) apps on other platforms. That's very interesting to big corps with existing codebases.

See my comment [2]

[1] https://github.com/AvaloniaUI/Avalonia/issues

[2] https://news.ycombinator.com/item?id=39246988#39249128

Yes, but the portable GUI frameworks by Microsoft themselves are generally not very good, and they tend to be abandoned after a couple of years.

Avalonia is developed outside of the Microsoft corporate madness and seems to be slowly becoming the defacto cross-platform framework because it is expected to last a bit longer than a manager's attention span: https://avaloniaui.net/

Not my comment, but relevant here "The problem with compiling Skia to WASM is you'll lose any benefits of hardware graphics acceleration on the device."

(From https://github.com/AvaloniaUI/Avalonia/discussions/6831#disc... )

It's a bit of a hit and miss as of today. CLI, back-end and natively compiled libraries (think dll/so/dylib or even .lib/.a - you can statically link NAOT binaries into other "unmanaged" code) work best, GUI - requires more work.

Avalonia[0] and MAUI[1] have known working templates with it, but YMMV.

[0] https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/ / honorable mention https://github.com/VincentH-Net/CSharpForMarkup

[1] https://github.com/dotnet/maui (try out with just true in csproj - it is known to work e.g. on iOS)

For desktop, Avalonia, hands down.

https://avaloniaui.net/

Open source, powered by Skia, backed by JetBrains, and quite battle-tested at this point for small to medium-sized apps. In theory perfectly capable for enterprise as well, since it's basically a spiritual successor to WPF, which has been an industry standard for about 15 years.

They're diving into mobile and WASM well, but that's more of a recent effort and I haven't tested that yet.