Server-side Flutter idea discussion

For some time now I’ve been thinking in a solution to build apps on a higher level (meaning: not using Flutter, React, WinUI, XAML, whatever).

How? Using the same principle Xamarin Forms uses: it abstracts UI components in a XAML and the underlaying platform decides what to render, so a <Button Text="Hello World"/> will be rendered as a true native button on iOS and Android (kinda like what RN is).

Now, imagine you can create a XML that covers all basic components, like Page, AppBar, Lists, etc. all that is common amongst all apps.

This XML then would be interpreted at runtime by the underlaying platform and render the output. You could, for instance, use the same XML to render a Material App for Android and Cupertino for iOS. Or you could even build an interpreter in HTML and render a true HTML application, using HTML only. Not seeking for pixel perfect solution at all.

Using CQRS/Events, the programmatic part could be dealt with something like GitHub - ethanblake4/dart_eval: Extensible Dart interpreter for Dart with full interop (maybe some high-level stuff could do declarative REST, SQLite, GraphQL and dart_eval used only by not covered cases (some validation, etc.).

The app would be downloaded to this engine as a whole lot of XML and .dart files that would run just fine offline (or, maybe with a flag, it could ask those data from some server). Basically, what HTML is already.

For example:

<Page>
  <Page.header>
    <AppBar>
      <AppBar.title>
        <Text>This is a title</Text>
      </AppBar.title>
   </AppBar>
  </Page.header>

  <Page.body>
    <ColumnLayout spacing="16">
      <Text>Hello world!</Text>
      <!-- Dispatch a Command for some Mediator handler -->
      <Button onClick="myCommandName">
        <Text>Click me</Text>
      </Button>
    </ColumnLayout>
  </Page.body>
</Page>

This example can be rendered in whatever technology (native, Flutter, web, etc.). It can do things on client side (maybe some declarative REST call, local database, etc.) or it can be generated server-side and render content coming from a server (Brazilian bank NuBank does that: Backend Driven Content: why we developed a Server Driven UI framework at Nubank - Building Nubank)

That would give some possibilities, for example, if we declare a <Model> with some properties, we can configure the app to run, for example, PowerSync + Hasura and make the whole offline-first work with no coding at all. The same could be generated as an online GraphQL call, for example, or even some REST call (basically, the I/O would be declarative and the implementation itself would be made by the framework, so no coding required to accomplish basic stuff like local database, rest, gql, etc.)

It could also leverage partial updates, like HTMX/Alpine does.

I would love to hear some opinions about this.

I think you’re describing “rfw”, which thankfully doesn’t descend into XML-hell, but stays with a dart-like description language for client-side widgets.

1 Like

Quite the opposite of rfw. rfw keeps the separation of core widgets, cupertino and material. What I want is a complete, independent abstract UI language.

And XML is a matter of taste. I’ve developed hundreds of apps in XAML and I feel very comfortable with that kind of UI. In the Windows 8/Windows Phone era I was responsible to basically rewrite a lot of applications that exists for Android/iOS porting them to Windows 8/Windows Phone (Microsoft paid the conversion, our company did the conversions). This is the last one that survived: Cinemark Brasil - Download e instalação gratuitos no Windows | Microsoft Store The separation of UI markup and the actual code is much more accentuated in those apps (even MVVM was born out of this).