[hawski]

How good is FFI in Dart? I mean how fast and easy is it? I see that it can call C and C++ libraries, but that's nowadays a basic requirement for any FFI. I'm looking maybe for an opinion and maybe some kind of numbers to back up it's performance.

As far as I understand it on Android it's compiled to a CPU native binary and has to use NDK and JNI to do anything. If that's a fact it's funny that on Google's own platform it has to go through two FFIs - Dart to C to Java. While on iOS just one - Dart to C, because what's there not to it for Obj-C?

I'm dreaming for a truly native everywhere platform. Something that would compile to DEX or JVM byte code for Android, CLR on Windows and a binary everywhere else. While using native widget toolkit for each platform - practically without any FFI. Also respecting HIG of each platform. Yeah, I'm a dreamer.

I heard about https://www.elementscompiler.com/ , but I would also like for it to be open source. :P

[mwcampbell]

I share your dream. I seriously considered Elements for a project a couple of years ago, but rejected it, because I didn't want to get into a situation where Apple introduced a new platform (e.g. tvOS) or a new technical requirement (e.g. 64-bit or bitcode) and I would be stuck because I was dependent on a third-party, closed-source compiler to produce native code.

[greenhouse_gas]

FFI is actually quite bad. You can't talk to native (C, C++, Go, Rust) code directly. You have to talk to Java, and if you need, from Java to Native.

You also communicate to Java through serialization, rather than through shared memory.

Oh, and any communication goes through a Future, which is annoying.

[geokon]

I mean, if you're gunna use C++ libraries, is there a reason not to just make the whole app in C++ (like with Qt/QML)? Seems adding a new language/toolchain to the mix is a recipe for headaches.

That's a genuine question :) I don't do any app development so maybe I'm missing something - is Qt not sufficient? It seems to run on everything as-is

[hawski]

I didn't say anything about C++ libraries, at least in case of my dream thing.

The problem with Qt is that it draws its own widgets. It is close on some platforms like with Gtk+ theme, but most people report how it does not look native on their platform. Also on Android it has to use JNI and NDK so it's not native to Android as DEX/Java is. On Windows I believe that CLR or at least COM (you can do it even C, but that requires effort) is a native platform.

Qt is from a time when C was kinda native for everyone. It's a different world now for better or worse.

Of course Qt has some advantage over one of many other widget toolkits drawing their own widgets. It hooks to native accessibility APIs for example. Other than that: dlangui, Lambda Native or even SDL2 can be seen as contenders.

[geokon]

I see the limitation.. but I must be missing some subtle distinction b/c isn't Flutter doing essentially the same thing under the hood?

"The engine’s C/C++ code is compiled with Android’s NDK, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved)."

"The engine’s C/C++ code is compiled with LLVM, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved)."

[hawski]

It does the same thing, that's why my dream is not fulfilled by Dart. Or may even have worse accessibility, but I don't know.

If it would be compiled to DEX (native for Android APIs) or JVM (compilable to DEX) byte code it would be different. It would at least enable use of it to make such a dream.

[sebe]

I posted this earlier, I think accessibility was a requirement for an internal google flutter app, have you had a chance to look at https://flutter.io/accessibility/