hydro-sdk VS Uno Platform

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

And Uno Platform (https://platform.uno/) is akin to React Native in terms of native controls usage.

also UNO Platform (C#) which is suitable for simple or complex cross platform business applications : https://platform.uno/

Why is this a problem? At face value, it isn't a problem. Taking a step back at a more global level, what does "uComponents" mean to the rest of the world? Many of the .NET developers who heavily use NuGet may have not even heard of Umbraco CMS, let alone a 3rd party plugin for it. What if people from the Uno Platform community are browsing NuGet for some kind of components extension library? You can see, this could get confusing outside the scope of the Umbraco community/ecosystem. On top of this, uComponents was developed against Umbraco v4, with its last release in 2016, now it's there to be lingering on the NuGet repository until the end of time, set in stone.

Not a fan of XAML after trying to get into it, but there is Uno Platform. It wraps native widgets on mobile, just like React Native (which is good for accessibility), and uses C#. https://platform.uno/

My guess is that it's mainly focused on mobile. On Windows, it has no overhead (behaving like a normal WinUI 3 app), on macOS I think it uses Catalyst by default (which was developed by Apple to make more iOS apps available for Mac desktops) and on Linux it draws its own widgets that the devs try imitating the GTK style with.

On Android and iOS, it just uses the native widgets which I think is a better experience so you can see my reasons for guessing it's mobile-first. That may or may not be what you want.

5- Uno

> ...building UIs with the document/element api

When the whole premise is flawed, JSX or not, does it really matter if there is a better or worse way of misusing a technology not meant for UIs?

Leave HTML and JavaScript to Wikipedia and other hypertext document libraries.

Unfortunately, WASM is not there yet, but people are trying: https://platform.uno.

Uno Platform is fully open source, under Apache 2.0 license. You can see the license here https://github.com/unoplatform/uno/blob/master/License.md