So the concept is:
Have a server that is the flutter app (native linux or something) and it serves flutter UIs over the network to “clients”:
a client here would mean:
- something that processes screen updates, they either come as pixel change deltas or render-engine instructions from the server
- forwards inputs (click/touch, and all the usual stuff that websites can also request to access like location and camera etc)
i got inspired from Hannes Winkler from Industrial Flutter who demo’d something similar at a fair with a watch where the actual flutter engine ran somewhere else
It’s basically this idea just primarily thought of as for the web because with Flutter Web you can’t really serve a normal page right now because time to interactive is >5-8s
But i imagine this could make possible:
- flutter becoming a viable choice for websites that are more than a static document (basically all websites)
- extreme client security because the actual client isn’t ever loaded
- have it work on even the most incapable of devices
- UX consistency accross devices because the work they’d have to do is so light
I think with just being able to build Flutter in “server-mode” for linux and the thin-client for web only you could gain almost all the upside this idea brings.
So my questions are:
-
if this is in general something that makes sense
-
if anyone has already worked on something similar
-
if the vision of the official flutter team is to have development in this field happen
-
to anyone who is deeper into the flutter technicalities:
- how much effort has to go to making this work?
- does it have to be flutter-specific or does the thin-renderer part already exist and it would just have to be adapted?
-
and in general does the flutter community like seeing progress here or is there even people who’d sponsor development of this?
tell me your thoughts!
Your best choice:
A XML language that defines your UI (XML IS the best option for UI, as it is extensible and strongly typed).
Your server would send the UI as text and a local flutter engine would convert it to widgets.
Any event would then be triggered in the server (either by MQTT or request/response).
You would, basically, reinvent ASP/PHP (request/response) or AJAX (MQTT/socket).
You could basically write a dart processor (the same as php.exe or asp.exe) that basically do that for any text and hook it on some local socket (so nginx could access it, the same way php-fpm does). I bet would be far superior than PHP or ASP, especially memory-wise (and you could have true AOT compiled server-side apps).
And that’s where old people say: it’s always a cycle… we go’round in circles. =P
(btw, Flutter is a UI framework, so it doesn’t make sense in the server side - deltaing pixels and transporting it would be far too slow (that is basically what VNC is). Also, It would transmit the source image (imagine the source is 1920x1080 and the client is 800x600, if you ever used VNC on a mismatch monitor configuration, you know it is bad (at least, black letterboxes everywhere and hard to read/click elements))
Okay, thanks. This discussion is theoretical, i don’t need help or anything.
So you don’t want to reinvent the wheel, livestreaming a screen isn’t the way obviously.
What about sending WebGPU/WebGL instructions?
I’m thinking of a server that doesn’t draw any UI to any output it has locally (so there is also nothing to livestream).
Instead, a proper custom-made protocol where resolution and everything is passed from the thin-client so the server can then serve it a proper UI. (It makes it for the each client, it doesn’t have any UI by default)
This requires change and development deep within Flutter itsself.
I’m not that deep into the technicals and that’s why i also create this post to get some insight from people who are more familiar with the low-level stuff who could give a proper verdict on this idea.
The huge problem elefant that makes all this worth talking about is that you can not use Flutter for websites right now, with this i imagine you could get Time to Interactive of <1s at the expense of some input delay
Probably never will.
WebSites are built with HTML. There is no need to reinvent that.
Rather than use Flutter for your thin-client front end, use Jaspr in the mode that provides components for the view that are backed by proxying to components running server-side.
