So much so that you literally have platform-specific widget implementations to go along with the platform-specific themes. Which sounds worse than it is, but defining new widgets is super easy.

Not a write-once-run-everywhere but more like a write-1.2x-to-support-2-platforms type of thing. It risks being uncanny-valley at times, and implementation can drift from platform needing re-alignment, but it should let you do those really platform-specific stuff in sane enough ways.

Chris Sells [email protected]

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

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.

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

Not all platforms have the same user interfaces/paradigms. What is the Windows equivalent of the OSX dock? What is Linux's equivalent?

Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language. (By second class I mean it's not what the OS authors intended their apps to be written in.)

Isn't this throwing the baby out with the bathwater? Only a very small portion of your code should be platform-specific (10-20%?), which is still a huge win over maintaining multiple native apps. Of course, in practice, there are many other disadvantages of using cross-platform frameworks that may outweigh the benefits, such as the inevitable impedance mismatch between languages, APIs, concepts, etc.

https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh...

I think the solution is to split in 2: A UI back-end with logic, layout, etc and a UI front-end renders in each UI native toolkit.

So when write Button(title="hello") is NOT a widget, but a struct with data. It must be pushed to UI.Coccoa.render(button) to show up. But not only that, is possible to say:

  Form
    when(toolkit=UIKit) Field(UILabel="UserName", UiTextBox(PlaceHolder="Write your user")
    Field(Label="UserName", Edit(PlaceHolder="Write your user")

Also sounds like what wxWidgets already does.

You must buy the whole Package with react and others. You don't code normal UI on Swift and still be part of the react world.

Think is like build a JSON API. My idea is that. This mean that on the client, is full native (with some minimal coupling to the how transfer data).

ReactXP (https://microsoft.github.io/reactxp/) uses TypeScript and targets mobile and desktop platforms using native controls, not emulated controls. While Flutter doesn't work yet for desktop or web, ReactXP already works for these environments, and is used in the new Skype for Web.

Windows support is done and targets W10, Xbox, and Windows Mixed Reality. MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper.

How would non-tech users handle backups?

In this way you'd have the data storage decoupled from the app so the choice would be there.

Ah, but you see, the current crop of developers loves these things because you can make a lot of money when people have to pay you rent. They might talk a good game about open source and empowerment, but they're behavior says they'd rather make money.

Not trying to be harsh and I bet this project has cool plans.

But what worries me is that there are 100s of options in this space and _all_ of them are short.

Why can't the passionate community rally behind one effort, and fully solve this problem?

A solution doesn't seem to need to be programming language-specific, either, so that doesn't seem to be a good reason to keep 'forking' this problem.