[csells]

I'm the PM for the Flutter developer experience. I'm currently digging into the next steps for our desktop experiment with Flutter and I'm very interested to hear how your xplat desktop app dev options fall short. What do you need from an xplay desktop app dev framework and toolchain?

Chris Sells [e-mail]

[wellpast]

Hi Chris, that's awesome!

My (perhaps idiosyncratic?) priorities in order:

- a ui programming model that is thoroughly thought-through. to be honest i think javafx fits this bill, it took long- hard-learned lessons from Swing but rebuilt things up from that learning. the scene graph api model imo is so ideal and then the way they build the widget/controls on top of that...creates a lot of flexibility yet remains simple

- actually works reliably (ie, is production-quality) on all platforms * this is probably where 100s of these xplat desktop frameworks fall down. many are just so far from reliability

- full support for building binaries (+ installers would make you really stand out! +, heck, streamlined app store deployment would be wow) for all major systems (mac, win, linux) ... ideally producing these all from one same build machine/os

- solid set of optimized core widgets (all the stuff you'd expect in any widget toolkit...and performant...eg, the table widget should be optimized for unlimited records etc.. again javafx seemed to get it right w/ their tableview)

- polyglot (again java/fx ... you can build in clojure, jruby, kotlin, etc etc)

Where I depart from perhaps the majority is that I don't care about native LaF... and I suspect striving for native LaF is sort of at odds anyway with the xplat goal. So in my mind, I'm okay w/ non-native.. of course I do want ability to pixel push and have things look nice and I want things generally fast. (javafx again is doing something cool w/ its ability to style things in its 'css' support...)

I can think of a lot of apps that don't use the native OS LaF and yet look great.. Spotify, for one, and there are many productivity-oriented apps in this list... Another.. I use Jetbrains IDE for developing in Java, Clojure, Ruby, Elm, Javascript, etc... and that app - afaik - is Swing-based and yet they have made a killer user-experience across the board imo..

I guess I just talked myself in to using JavaFX

[norswap]

Really interesting comment! I tried to use JavaFX a while back and was really put off by it (whereas I've had good experiences in Swing).

Some issues (it's been some time so memory is a bit hazy):

- Lack of good documentation, both official and alternative (ultimately found a good reference book).

- Lack of customization on some widget, even compared to Swing (remember being really disappointed at how hard it was to modify the built-in tab-view).

- I really don't like the built not-quite CSS. Remember having trouble finding documentation for it. Also why a different language and not just code — like for the rest.

- Was really put off by some parts of the API design, even compared to Swing. Something that I remember is that there was a half-baked support for "theming" that isn't really usable nor used.

- This is much more debatable, and I won't wish ill on people who dismiss it, but it feels like it's completely out of the zeitgeist. I don't know if people doing unsexy jobs use JavaFX, but very people talk/write about it over the internet. Compared to Swing, the dearth of resources is staggering. It also created a lot of FUD that you can easily find if you google a bit. Don't use Swing cause it might be deprecated in favor of JavaFX (unlikely?). JavaFX hasn't really been updated nor hyped since Oracle took over, it's just rotting. IIRC it's not even bundled with the VM anymore, which is more headaches for distribution.

Only exception: https://tornadofx.io/ has some love in the Kotlin community.

- You have to link to different JavaFX jars for different platform, which makes any kind of Maven (etc) based dependency management a nightmare.

[csells]

Thanks for the input!

[tuarua]

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.

References

https://github.com/tuarua/WebViewANE

https://github.com/tuarua/FreSharp

https://github.com/tuarua/Swift-IOS-ANE

[alasano]

Unrelated question, when did you decide not to pursue a career in sales?

[csells]

I have heard variations of that most of my life. I always wanted to get into the Unix shell business on the coast so that the following would be true: "Chris Sells sells C-shells by the sea shore." Alas, another dream unrealized...

[lone_haxx0r]

He must have heard the same "joke" his entire life.