Would have been be nice if they provided a way to use Kotlin Native as a language for Flutter instead. Not a JVM Kotlin of course, because it's too slow for the native mobile apps. Or, even better, Rust. That would be very impressive.
This reminds me, I'm getting the impression that with every new UI framework that gets released, we're just recycling ideas learnt on the web and re-living its paradigm shifts:
1. First, in the early days of the web, we defined UIs declaratively but mixed structure and looks (`<h1><font face="Comic Sans MS">Hello, world!</font></h1>`).
2. Then we separated content structure (HTML) and styles (CSS) (or even XML and XSLT)
3. Later on we added dynamics and discovered event handlers (JS)
4. Then we realized we could use JS for everything (content, styles, dynamics) and imperatively create & manipulate UIs by manipulating the DOM (document.createElement, jQuery, d3).
5. Finally it dawned on us: That's not a good idea, either, because 1) we're mixing business logic and styling and 2) the DOM is global state. So we switched back to the now classic separation of using HTML for content, CSS for styles and JS for dynamics. But this time we try to keep individual components (their state, their DOM and their business logic) neatly encapsulated (React, Angular, Web Components).
Small nit but Jetpack is the name of the entire suite of libraries that Google offers for Android. The thing formally known as "support lib", a name that stopped making sense when it had random useful stuff not just compat stuff.
You're talking about Compose here (or Jetpack Compose).
Unfortunately because of harmful politics from mozilla pushing the NIH webassembly, it's not going to happen before a proponent come (maybe Microsoft someday)
But im sure that with enough work a Rust Sdk could be created as most of the core functionality is exposed as a C interface.
The product i'm finishing is more of a answer to the question of if there's something between the browsers and mobile application platforms that could also work in a more distributed fashion.
The access to DOM apis are going over the C, so its just a matter of wrapping all up in the target language.
Im using the Chrome multi-process architecture, but instead of a renderer process what gets called is a application executable that binds to Webkit and acts as the renderer process do to Chrome now.
So this gives the application much more control over the client rendering, hooking over every event WebKit triggers, something that is not even possible with Javascript now. So its much more powerful.
You also have a "service" process which runs as a service, that is actually the one that receive every request and can launch the application process or do something else.
The requests are over GRPC, so the service process serve not only the UI requests for routes but also the RPC method calls to the API it defined according to what the app does. The API for both are in Swift, but the core runtime and system is on C++ and in a multi-process architecture, so any native app that can compile into a standalone binary and interface with a C api can also use the facilities.
The applications and resource distributions are over torrent so anyone can serve the application without any intermediaries or shipping on servers.
If a app want to talk to the cloud, its just a matter of doing so when processing the routes or the RPC method calls, but it can work offline or eventually online/offline given its design.
I've heard Kotlin can produce standalone binaries, so that means its possible (and no WebASM shenanigans with direct access to Webkit and with the real native boost)
Unfortunately i cannot ship with another SDK right now because i'm doing too much already, but i intend to create interfaces for other languages once things are more stable, and people understand better what is it's place in the game.
But is more a application and window manager as Chrome is more-less and less as Electron or Flutter, where it wraps a standalone app.
With this design together with the RPC api's exposed by each application, you end forming a local network of apps, where they can work with each-other. And with the Api's working as a social contract, you can replace the application to serve the same things without losing everything (effectively real data ownership)
But my goal is that you can just call "./pacman" and the thing pops, even being managed by a core process as in chrome. The user dont need to deal or know anything about it.