The closest comparison I have to Flutter is Adobe AIR which I use extensively (scoff all you want).
The premise is very similar (non-native UI on OpenGL/DirectX surface, AOT compiled language, C++ based runtime, near native performance) I would go so far to say Flutter is heavily based on AIR.
When I ran the current Flutter-desktop demo it appeared to have the stability and feature-set of AIR 1.0 beta which was released in 2008 (It is now v32.0 as of 2019).
It's a great jumping off point but I don't necessarily understand the hype when I am seeing something I saw 11 years ago.
Features I would expect Flutter Desktop to provide to match AIR.
- Hardware accelerated Video
For multimedia apps
- WebView
This may seem counter-intuitive but a chromium/webkit based webview component is a must.
- read/write/delete access to files in the app's sandbox.
- saveAs, filePicker dialogues
- Multi window support
- Toast/Notification Support
- Extensibility
AIR has a C lib and header for passing vars between the AIR context and the native plugin. This means the conversion has limited overhead. We can pass bytearrays, bitmapdata and even call methods directly on the AIR vars from within native code.
Being limited to using JSON across the bridge is not ideal, as there is conversion overhead and also you lose type safety.
I have added bindings for Swift, C#, Kotlin in recent years for building plugins with these more modern languages. It also allows building extensions in .NET and not being restricted to C.
The premise is very similar (non-native UI on OpenGL/DirectX surface, AOT compiled language, C++ based runtime, near native performance) I would go so far to say Flutter is heavily based on AIR.
When I ran the current Flutter-desktop demo it appeared to have the stability and feature-set of AIR 1.0 beta which was released in 2008 (It is now v32.0 as of 2019). It's a great jumping off point but I don't necessarily understand the hype when I am seeing something I saw 11 years ago.
Features I would expect Flutter Desktop to provide to match AIR.
- Hardware accelerated Video
For multimedia apps
- WebView
This may seem counter-intuitive but a chromium/webkit based webview component is a must.
- read/write/delete access to files in the app's sandbox.
- saveAs, filePicker dialogues
- Multi window support
- Toast/Notification Support
- Extensibility
AIR has a C lib and header for passing vars between the AIR context and the native plugin. This means the conversion has limited overhead. We can pass bytearrays, bitmapdata and even call methods directly on the AIR vars from within native code.
Being limited to using JSON across the bridge is not ideal, as there is conversion overhead and also you lose type safety.
I have added bindings for Swift, C#, Kotlin in recent years for building plugins with these more modern languages. It also allows building extensions in .NET and not being restricted to C.
References
https://github.com/tuarua/WebViewANE
https://github.com/tuarua/FreSharp
https://github.com/tuarua/Swift-IOS-ANE