Would like to use it for a Linux app. Looking forward to when that has first class support.
The widget layer is written in C++ (Skia). There's no reason the Flutter toolkit couldn't be quickly adapted to Linux. Or FreeBSD. Or Windows, macOS, OS/2 or even Windows Mobile.
Google's cross-platform Flutter UI toolkit goes 1.0
141–150 of 343 posts
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#142Looks nice. I find it similar to Adobe AIR but with DART as programming language.
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#143Like I said yesterday "The road block for adoption will be Dart. Why they didn't just choose Typescript or go with native javascript is beyond me. No one uses Dart. It was probably the poorest design decision they could make." The comment from pzo points out an even worst of an adoption showstopper.
> There’s a lot of nice properties of Dart, we talk some about this on our website at our frequently asked questions. One of the nice properties of Dart is that it has a really fast garbage collector, one of the choices that we made in Flutter was to have this reactive style system where it’s very common to allocate thousands of objects in a – if not, tens of thousands of objects in a single frame.
> In a span of a few milliseconds and then immediately let go of those objects again. There’s a variety of ways to do that but Dart, having a generational garbage collector, can handle large volumes of short lived objects very quickly. Dart also has some really nice performance characteristics, it has an ahead of time compiled back end which allows us to compile straight to native arm code, allow us to achieve really fast startup on really consistent performance and Dart also has a nice focus on developer experience which really got along well with my team.
From https://softwareengineeringdaily.com/2018/07/09/flutter-with...
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#144Writing plugins/bindings for native code in flutter doesn't look fun. Almost 100 lines of code to write binding for function that doesn't take any parameters and returns simple 'int' (int getBatteryLevel()). This just looks even worse than JNI to me. Don't want to even thing how long time it would take me to write bindings for function that do image processing. https://github.com/flutter/flutter/blob/master/examples/…
> We are on the verge of VR and AR and I don't see how flutter can help e.g. processing >100fps Video Feed using OpenCV library. The demo they presented on stage with ML and smile detection had quite big latency. I wouldn't call it real time. I can't find any claim from Flutter team that 100fps video processing is even their goal. So that's a strange metric to measure it by - especially since it's competing against J…
C++ is probably not the most productive language to write business logic but on the bright side Qt Company recently started supporting Qt for python (Pyside2) - sadly not on mobile devices for now. However it seems you can use PyQT5 on mobiles nowadays. This would be the best of all worlds IMO: 3 highly popular languages with rich libraries, tools and ecosystem -> C++ for speed critical code, Javascript/QML for UI and layout, Python for business logic and as a glue.
Qt also gives me more confidence that is not going away anytime soon. It survived many years and acquisitions (Trolltech, Nokia, Digia) and have some big clients/users in automobile and open source (KDE).
I will closely follow Flutter thought as well as React Native. The latter one also it seems noticed what a pain is writing all those bridges and looks like they are working on it to fix it with new architecture.
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#145Earlier quoted context omitted.
> Flutter doesn’t actually run the Dart VM, it uses AOT and compile to native code. That's the whole point - you can't compile JS to fast native code. It also does use the DartVM for hot-reloading development cycles.
There are plenty of languages that compile to fast native code, some of yore (Common Lisp/Eiffel) even offer that amazing live code experience that they sell as unique Dart feature.
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#146Earlier quoted context omitted.
Comparison: React Native (and Xamarin, for that matter) use platform-native widgets with JavaScript composing the UI dynamically in the case of React Native (and UI's either dynamically composed or statically compiled with Xamarin -- depends how you build the app). Flutter brings it's own widget layer to iOS and Android (and Fuchsia?) so it's more like starting with a blank 2D graphics canvas and creating your own co…
The widgets are written in Dart, not C++. If you need a new widget, you would write it in Dart, which is the same as the application language. This contrasts with React Native, where new widgets/views would be written natively and wrapped in React Native.
If you need to go deeper (for some specific perf issue, usually for animation stuff) then you go native. But it’s a second class approach — well, it has first class support and is not as “second class” as it is for example in Titanium or “completely out of scope” in Cordova.
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#147Writing plugins/bindings for native code in flutter doesn't look fun. Almost 100 lines of code to write binding for function that doesn't take any parameters and returns simple 'int' (int getBatteryLevel()). This just looks even worse than JNI to me. Don't want to even thing how long time it would take me to write bindings for function that do image processing. https://github.com/flutter/flutter/blob/master/examples/…
The rest is UI and application boilerplate
Re: Google's cross-platform Flutter UI toolkit goes 1.0
#148Re: Google's cross-platform Flutter UI toolkit goes 1.0
#149Re: Google's cross-platform Flutter UI toolkit goes 1.0
#150Earlier quoted context omitted.
Dart is being used internally at Google for AdWords and other core products: https://www.dartlang.org/community/who-uses-dart Even if it's not popular elsewhere, with its use inside Google, it won't be going away anytime soon.
AdWords previously used GWT, which is no longer maintained by Google. I get the feeling the AdWords team just really doesn't like JavaScript, which is understandable, but it doesn't say anything about whether AdWords will stick with the current non-JavaScript language du jour or move to another.
This is not entirely true, although the goal shifted over the years and progress (outside Google) is very slow. See J2CL, jsinterop, and elemental2.