Writing 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/plat...
Which is sad because I would really want to have some fast and easy access to useful c++ libraries without wasting lots of time writing and maintaining tons of bindings for Java, ObjC, C.
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.
So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
> 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 Javascript interpreted code which is far from fast by any metric.
> So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.
On mobile? Qt really isn't pleasant or usable on mobile.
I have recently gave a look at Qt after 5 years and it seems lots of things have changed for the better. You get the same hot reload like flutter when modifying GUI using QML (with V-Play you can even hot reload not just on simulator/emulator but on real device). Qt material theme has good look and feel. Sadly iOS theme is a little bit lacking.
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.
Try to download it from qt.io. You will have to go through several screens saying "Are you sure you are able to comply with the LGPL? Wouldn't you rather get the commercial version for peace of mind?". If that isn't an implied threat, i don't know what is.
I don't like this but I also kinda understand why they do so. Many devs around me (I live in Korea) don't care about GPL/LGPL and it is important for Qt to let them know. Qt is commercial software anyway.
I don't approve of that tactic (in fact it drives me nuts), but I will say, Qt's license fees are quite reasonable, and then you get to link statically with no risk of violating the GPL.
Reasonable? It's about $500 / month / developer with additional royalties if you are shipping devices with Qt firmware. Sure I think Qt/QML is the best UI toolkit available but this crazy pricing is driving me towards any possible alternative. So I'm really hoping Flutter will take off (for desktop/embedded as well, not only mobile).
Note that Qt is GPL3 nowadays so you can't really ship embedded devices with Qt without paying.
Actually Trolltech was doing pretty well while selling Qt (which was full GPL at that time) for a fixed price per major version.
Then Nokia bought it and made it LGPL because they were planning on using it as the foundation for (some of) their mobile phones. Unfortunately, they couldn't decide which phones and went on a downwards slide.
Then Microsoft bought most of Nokia, and Qt got spun off into an enterprise thingy that takes their sales tactics from Oracle. Yes, I know the LGPL allows me to link dynamically for free, no, I don't trust Digia not to sue me for that.
Their pricing is also out of reach of anyone who's not in an industry that charges an arm and a leg due to regulation or niche.
Actually what I predict is the return to shareware/public domain models, where the free software is only the tip of the iceberg of the stack one actually needs for production code.
The trend is already visible with SaaS, Cloud, IoT,...
Ok I'll admit I'm not familiar with medical certification. I know that the so called Qt Safe Renderer for ISO26262 compliance is a bit of a joke at least.
I have seen two very big Qt projects being cancelled due to Android. Not the Android Auto app but native Android for IVI.
I don't see any indication of your vision for shareware. The trend is towards more and more software being licensed under licenses such as MIT.
> On mobile? Qt really isn't pleasant or usable on mobile.
Can't confirm. We've been using QML (part of Qt) and C++ to write cross-platforms applications (Android, Windows, Mac) for many years now without any major hiccups.
Since flutter runs as native ARM they can directly call C++ instead of having an expensive JNI bridge on android. If you're wanting something fast with native processing - flutter will be the best option out there IMO if that issue is resolved.
I came to the same conclusion (and I'm not a big company that can afford Qt), so I built my own. Before Flutter got a new team @ Google ~3 years back, it was a set of tools for building cross-platform apps with C++ shared libs. A few years ago, this is what many of the FAANG companies were doing with their apps. Then, React Native was released and (I guess) the management at Google decided to take a different tack.
I did some research and found that Dropbox open sourced their internal tool for building cross-platform mobile apps in C++. Djinni (https://github.com/dropbox/djinni) uses an interface definition language to generate bindings between C++ & ObjC & Java (via JNI). From this, I added some tooling to help get the build setup and define some basic UI elements while trying to keep it simple. If you happen to give it a try, I'd love to hear your thoughts: https://github.com/adamtait/ctheworld
Cross-platform frameworks that don’t use native controls have suffered from problems...
- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
- they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
- Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
- there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
- dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
- devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
- many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Building and maintaining an app twice is a very serious expense. But the expense of dealing with the issues with crosss-platform frameworks can be pretty big as well. Of course it depends on what you’re doing (shorter term and longer term) whether or not it makes sense. But go in with your eyes open. Consider other options (like examining your app architecture and see if you can’t find a way to factor some of your naturally cross-platform stuff into a shared library usable by the native apps of each platform you support).
>- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users.
We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
To be fair, just because bigs use their own frameworks doesn't mean they produce great UX. There's an added learning curve to any non-native app that users incur when this happens - things are out of place, don't work as expected, features don't exist, etc. For example:
- Facebook doesn't use standard share sheets or web views. So if you're viewing an article, you can't use reader mode and you lose the (considerable) power of share sheets to do things like sending an article to another app or take an action on it.
- Gsuite doesn't register left swipe as back even though 99% of apps on iOS do. Icons for common actions are subtly different and make you double-take while you understand what they do. Accessibility options like larger text do not work, so if you're vision impaired good luck trying to figure out what you're looking at. And there's a ton of other quirks that have existed over the years including scaling to new resolutions/ipads, problematic text selection, performance, etc. It's not as bad as it used to be, but it's still not a pleasure to use Gsuite or any material design on iOS.
While many apps may use cross-platform frameworks solely for saving developer/designer time, the bigs use them for an additional strategic purpose that is detrimental to users.
- Google wants you to be familiar with their apps regardless of platform, so that its easier to get you to switch to Android or Chromebooks.
- Facebook wants to keep you in the app as long as possible, limit social sharing outside of their app, and spy on your browsing activity, so they add friction and don't use modern iOS web views that prevent that.
I wouldn't take cues from the bigs and just assume because they do it, it's the best course of action.
For us, we want to use the web stack so our stuff works across all platforms. So we use Cordova. We realize that over 90% of users just want to use the main interface and not some fancy OS feature. All our effort goes into making the product rock solid stable, engaging and easy to use. We aren’t actually interested in making it feel exactly like a native iOS or Android app.
Well, such things are causing subtle annoyance for users. This works as long as the value you provide is good, but the more and app is just a bad we view the more likely it becomes that people uninstall it or look for alternatives. Unsurprising consistent behavior is a value.
They do care. Try writing a DOS or Blackberry-style app today and see what happens. Software today has internalized the idioms so much that its developers don't even realize it.
"My app is a snowflake and needs a custom design language and UI." You're vim or Photoshop or AutoCAD or Excel: you're targeting dedicated users who are prepared to invest in learning a specialized UI. Fair enough.
But if you're not one of these highly professional apps, then custom control just makes the app less predictable, harder to use, and often inaccessible for users with disabilities. Not good.
>They do care. Try writing a DOS or Blackberry-style app today and see what happens.
Nothing much. Some of the most downloaded and bought apps (desktop and mobile) have horrible custom UIs. As long as the app has the crucial functionality, few care. And I'm talking for average users.
As for pros? Well, vim and Emacs are DOS style apps (well, in that they use curses and totally un-native GUI paradigms), and they're still strong.
UI concerns of that level only matter when apps otherwise have marginal utility and small other differences with competitors.
Sure but lets not forget the single most successful consumer product in history (iPhone) owes much of its success to it's clean, consistent UX across a suite of built-in apps. More people probably use those than downloaded apps.
1. People regularly complain about inconsistent web UI.
2. Even web apps often have similar idioms and patterns to their UI that they've settled on. It's their own patterns that are different from desktop OS, it's basically another category.
3. Most web apps are used on desktop, not mobile. On mobile, it's mostly native apps that are used. So they're not substitutes.
Honestly, I expect from a web page to be shitty. I'm surprised when some web page aren't slow, unresponsive, or doesn't distract me with million designer quirks.
My expectations are different with mobile apps. If I'm spending some time to find the app on the app store (and maybe pay for it) and giving the app a place and a storage on my phone, I'm expecting from the app to be polished and give me pleasant experience.
Agreed - I never could quite understand that argument and what is so intuitive and familiar with native UI controls when looking from perspective of a new app to the user. Depending on the app functionality, achieving good UX could be very hard and sub-optimal using only native controls, and impact of a well-thougth-out flow through the app, specialized controls where helpful and polished design should not be underestimated...I'd say that, if someone puts enough attention into it, custom design / controls are probably mostly superior to the native UI, in terms of UX. Not to mention how often people want something different and fancy over "boring" bland look of native controls...Granted, there are a lot of small usability aspects and behaviors to consider, as pointed out by others.
> I never could quite understand that argument and what is so intuitive and familiar with native UI controls when looking from perspective of a new app to the user
Consider the humble popup button. A user may open the menu via touch, or with a mouse click, or tab to it and open it with spacebar, or via accessibility support, or via scripting support. Once the menu is open, the user may choose to select an item via touch, or trackpad, or key equivalent, or arrow keys and return, or accessibility, or scripting...
When the control is obviously normal, all of these interaction modes are available. If it's something custom, then probably only a few work and I don't want to subject myself to the frustrations of figuring out which one.
Native UI controls allow the user to exercise their built-up vocabulary.
> I'd say that, if someone puts enough attention into it, custom design / controls are probably mostly superior to the native UI, in terms of UX.
Broadly false, but true in highly specialized apps where the investment in custom flows is worth it. (vim, Photoshop, etc). If you're building one of these apps, by all means, think deeply about a specialized interaction vocabulary. But if your app isn't designed to be absolutely central to a specialized workflow, PLEASE leverage the ecosystem and use the native stuff.
> Not to mention how often people want something different and fancy over "boring" bland look of native controls
Same in the desktop world - Qt emulates the widgets, but can theme them, then QML is another story. Also WPF (from what I've heard) uses (skia?) to paint own widgets. IMGUI is another example.
Then using the native wrappers, like wxWidgets is often cumbersome to create customized control, and if you do you end up with some platform specific version (not end of the world, but pretty much why not use the OS toolkit directly). Also any wrapper soon or later suffers from "leaky abstraction" - where you hide things behind interfaces, but can't hide different performance characteristics, and getting the current line in a log dialog might just kill you, because underneath it might be scanning all '\n', '\r' until your cursor position.
Given the usage of e.g. and offering the most charitable interpretation of coldtea’s comment, I guess it wasn’t supposed to be an exhaustive list, just the first (or most pervasive?) thing that came to mind.
There's one place where none of this matters: Games engines.
Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market.
It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's".
Which means that in this scenario:
> devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
.. It becomes moot whether you're using an engine or an OS's own specific platform. You have either an 'engine developer' or a 'user-facing developer', where the former does everything needed on the target OS to support the latter.
My personal preference: treat onboard native UI frameworks as a plug-out interface to the engine, port the engine everywhere, have my apps look and feel and function the same, no matter where they are running. Screw the OS vendors and their UI's - they change their frameworks so frequently and for no good reason other than to lock in the poor developer who thinks he has to learn their framework, or else not be competitive.
That may be true, but the real competition is in building an app that functions - and functions well - wherever you port it. To accomplish that, you've gotta be willing to be both an expert at the native framework, while also abandoning it ...
Game engines are a place where it makes sense to roll your own UI framework many times, so on that point I agree with you. The purpose of a game is generally immersion and escape, so makes sense to remove users from their device's UI in many instances. Game UIs tend to have their own conventions so frequent players don't have much of a learning curve. But in general players accept some learning curve because games are about taking on a challenge.
However, apps are not games. They're tools. And tools are not about giving your users challenges. They're about fulfilling a purpose as easily as possible. UI frameworks and conventions matter here because they lower the learning curve and cognitive switching cost, and they respect a user's preferences for how they wish to engage with their device (including valuable OS-wide capabilities like accessibility).
Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience.
- Some do it accidentally, because they don't know the UX guidelines or subtleties of the platform
- Some do it for expedience, because they need to put out a product quickly with few resources
- Some do it strategically, because they want the user experience worse since it serves other purposes for them
Yes, UI frameworks change as OSes change, but it's rarely for 'no reason'. Stepping back, devices have gotten way more capable and their UX way more sophisticated... which does necessitate change. Though that's some extra work for developers, it's not about you. It's about your users.
There are so many aspects of modern UI that are not functional, and serve only to distinguish one platform from another in the wider market-place - so I feel that your statement that the OS-provided UI is a 'tool' is misguided. There is nothing tool-like about making me wait for a swipe scroll to complete - this is a game mechanic designed to entertain.
And in that sense, its quite possible to make a non-native UI that is more productive than the OS-provided UI - you merely have to take responsibility for the user experience, obviously.. So yes, its about the user. One reason for going non-native and rolling-your-own, is to ensure that your user has a positive experience, no matter what platform they are using - and this directly competes with the platform-vendors ability to woo new users with fancy, game-like, UI elements.
So I don't think this point is quite correct:
>Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience.
Developers that choose to use their own UI framework win or lose on the basis of how responsible they are for making sure the user has a good time with their UI. This has nothing to do with whether the app is a game or a tool or whatever. Its a matter of competence.
Let me restate what you're saying to see if I understand it:
A product that looks the same across platforms is better than a product that adapts itself to the platform it is on, in part because platforms have a lot of UX that isn't good.
My argument for why its better to adapt a product to the platform is threefold:
1. Users have made the choice to use a particular platform and either like or at least tolerate that platform's approach to UX.
When in Rome.
2. Users are using many apps not just the one you made.
This is about scope. You can't just optimize your app in isolation, you have to take into consideration the entire scope of usage on a platform. It's certainly possible to create the perfect UX for a given set of tasks a user has to perform in an app, but drop that into a platform and its likely you've just added a huge learning curve and ongoing cognitive load.
3. Users mostly do not use your app on different platforms.
Users probably own either iOS or Android. If they own one, they aren't even aware of how the other one works. And on desktop, who cares because screen size and pointing device differences necessitate different UX anyway.
----
I think there are some instances where having the exact same UX on very different platforms is more ideal UX for the user, but only after it's acknowledged that a) its not just a proxy argument for being easier on the developer/designer, b) its not just the result of developer/company tunnel vision which leads to the assumption that users care about the app as much as the developer/company does, c) users actively want a different experience (e.g. immersive game), and/or d) users are moving more frequently between platforms than different apps on platforms (e.g. a business use case).
From a business perspective it's certainly fine to choose to use a cross-platform kit as there's many reasons to do so, I'm just arguing that it's not ideal for the user the majority of the time.
As far as whether platforms have not-good UX, I mostly disagree. I'd need to see examples of what you're talking about. If by swipe scroll you mean momentum scrolling I disagree. That has great utility on small screens to traverse large lists and it grounds the device in physical metaphors. It's a fantastic UX innovation.
I share your concern regarding text fields. That's the one area where I never want to mess with native behavior. The search results for "flutter ios text field copy paste" aren't encouraging.
These are all excellent points. I'm curious how Flutter stands to address these risks/issues in the early days.
I'd imagine it will take much more than 1.0 to get close to parity with the OS. Even if we assume it will always be 90% of the full OS experience (which is fine for the vast majority of use cases).
It helps that the Flutter and Android teams can talk to each other (they're both part of Google). So atleast for Android, you might be able to expect Android platform features appearing on Flutter in sync'd release cycles.
And in cases where you're using platform-specific feature that Flutter doesn't support yet, then your experience will be no different -- the burden remains on you to write platform-specific code.
Only one team needs to sync with another in this scenario.
It's also assuming that the Flutter team wouldn't consider do that considering they have that kind of information available to them -- it's in their best interest, after all.
If only one team needs to sync, how is it any advantage for Flutter and Android to be within the same company? How is the situation any different from Flutter and iOS?
I agree with the other commenter -- don’t expect any close cooperation between Flutter and Android because that’s just not how Google (and other huge companies) tends to work.
> "devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems."
Good product is a team effort. The question is: Can you find the right people - not just any people but the right people - to come on-board, use / learn the tools you've chosen, and make magic happen?
Sheer technical prowess of tools and/or people is not enough.
That aside, to your points, there are __always__ tradeoffs. Some more detrimental than others. But again, preserving is a function of team. Someone somewhere is doing what your team is doing, and doing it better. They have the same technologies. So then the question is: why.
These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory).
>> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.)
as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not.
>> they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework.
If people are writing cross-platform apps and want to use new platform-specific features, wouldn't they have to write platform-specific code anyway if they were native? I'm not sure this is a newly introduced problem in any sense.
>> - Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself.
I guess that's valid; but I'm curious about cases where code-heavy app sizes have actually hindered app downloads. I don't really know, but I haven't heard that this has been a big problem? For reference, a hello world flutter apk clocks in at 5 MB.
>> - there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc.
Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
>> - dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well).
>> - many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without.
Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?
>> - devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems.
This feels like an emotional assessment of having to learn something new. If this technology is meant to simplify/remove problems that people have today, then isn't it worth learning?
I guess you might feel this way if you felt that flutter isn't adding anything of value to other popular solutions today.
> as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not.
On iOS, the extent of "branding themes" end up is often limited.
> Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
There is no Chrome on iOS. So Flutter is different from everything else out there.
> Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here?
Flutter, and almost every other cross-platform framework, have this problem.
>... but I feel these are not really issues in practice (only in theory).
Ha, I wish! I've been down this road a few times and this list came from contemplating some of my old battle scars.
> ...as `coldtea` points out below, this is not really an issue in today's ecosystem.
That's not quite the same thing as it not being a problem. I know it can be done, but it's harder than when using native controls. This is something the "big dogs" can handle (they can bring massive resources to high-profile projects if need be) -- especially if they control the framework.
> ...cases where code-heavy app sizes have actually hindered app downloads...
Well, look around for people complaining about bloat. It's not usually the download itself, by the way. Memory is filled and runtimes have to initialize, buffers allocated, etc. It all takes time and uses runtime resources. This is fine to a point, but once you use too many resources or take too much time, it has a negative impact on the app (and as the developer, you have to deal with it in some way... e.g., perhaps spend time to alleviate the issues or perhaps walk away from lower-end devices). Any app, no matter the tech used to develop it can face these issues as it grows. But with an engine you start off closer to the limits and have less control over resource usage, so you generally reach them more quickly.
> Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem?
Hey, if flutter solves cross-platform text in 1.0 as you suggest, then good for them. Believe me, that's a massive accomplishment. (Though I'll note: if they aren't using native facilities, they'll have to duplicate them, which goes back to the point on bloat.)
> Is this a remark on an incomplete cross platform framework...?
No, I'm saying apps -- at some point -- generally eventually need to incorporate third-party libraries/tools to best accomplish their purpose. A PDF generator, a .csv parser, an image processor, an AI library, whatever. (A framework can't include an API for everything and shouldn't try, so it's not a matter of an incomplete framework). However whatever third-partly library you're interested in probably won't provide direct support for your framework, so you'll have to figure it out and do it yourself. It really depends on the library and the framework and how/whether they overlap how much harder this is.
E.g., suppose you want to incorporate an image rendering library of some sort into your app. The library supports iOS and Android and can output to UIImage on iOS and Bitmap on Android and their site provides samples showing how each of these work. But you're using a framework that has "XImage" and "XImageView". So now you need to delve into the platform's "XImage" to figure out how to load a UIImage into it on iOS and a Bitmap on Android. Maybe you find it works in terms of OpenGL textures and you realize going through a UIImage/Bitmap is an extra, inefficient step, so now you're learning about how to load directly from the library output into an OpenGL texture and you learn OpenGL textures can have different color formats so you start using the complicated low-level API of the image library to get output in the color format of the OpenGL texture. Whew! What would have been a few lines of code in each native app turned into a couple days of work, but you're done and release it.... and shortly thereafter, you start getting reports that the images are flipped on certain devices. Uh Oh... Now, maybe flutter doesn't have this particular problem, but this is just an example. This kind of thing will pop up as you integrate the third-party libraries you use with the UI platform. The more "opinionated" the UI platform is, the more quickly you'll run into these kinds of problems.
> This feels like an emotional assessment of having to learn something new.
Oh, come on. I'm pointing out an additional cost to adopting this kind of platform. That's a real concern to anyone developing apps, not something you can dismiss as an "emotional assessment" (Not sure even what that means -- laziness?). Note, this is an additional cost since you'll need native expertise in any case.
I have made an (unofficial/private clone of) Azul boardgame in Flutter (intended as a christmas present to my wife).
Whithout having any Dart or frontend or UI experience (I have always progammed backend and CLI apps), I could make a simple working game in maybe 10 hours - and it is mainly due to the instant feedback cycle.
The whole thing is less than 600 lines of Dart code. (and about 100 lines is to deep copy game state objects (for the undo functionality) as Dart can't do that automatically.
The design is simple, just circles, shadows and small animations (the player in turn gets magnified)[1], but with zero experience in the UI domain I actually barely beleive that I have made it ;)
Of course games are absolutely not affected by the native or not native widget issues, and also I did not use any advanced services from the platform, so can't say much about those weaknesses.
I was really happy with it, I would definitely recommend it to similar hobby/beginner projects.
I was looking for some new dev challenges and wanted to mess with some mobile app development that is outside of the React Native / Ionic / js world.
Gave Flutter a serious look, loved it, but ultimately decided to just skip and mess with Swift and Apple's tools - so no Android stuff for me for now. I just don't trust it to be around long enough to be an investment for me.
I know I'm just 1 developer working on a crappy hobby app for fun, but Google's quick lifecycle of products has real impact. But then on the other hand I love Firebase. Just wanted to share.
"I just don't trust it to be around long enough to be an investment for me."
Normally I would be inclined to agree with you given that this is Google, but the good news is that Flutter is open source. So even if Google discontinues internal development on it, it's likely that the community will continue it anyway.
I would be willing to bet my retirement that none of the now-popular presentation technologies will be mainstream 30 years from now. They just don't have that kind of shelf life.
If Flutter lasts a decade, it will have lived gloriously. React should be so lucky.
I wasn't talking about Tcl/Tk's current state, but about the similar situation it "enjoyed". It, too, had a pretty large community, which quickly went on too greener shores. User base is much more fickle than one might think.
Flutter could be even worse off, as mobile/web development is often corp development, i.e. not something people do because it's enjoyable. Even more people used MFC and Motif, but I don't see a lot of fansites dedicated to those.
As the darling of the tech community? I very much doubt it will make another 5. Everyone I know seems to be starting greenfield projects with Vue. And I would be shocked if there wasn't some revolutionary new thing I've not yet heard of waiting in the wings.
I have nothing against React (I use it) but I see no reason to believe it will not follow the lifecycle of every presentation technology that came before. Ten years is a long time. Of course people will be still be using React, but then people are still using GWT today.
I wouldn’t start a greenfield project with Vue and have no draw toward it. I’d go React. I think React/Vue are the end of the road in terms of JS, Vue for people who think tooling is hard, and React for people who don’t mind the tooling.
People attribute the JS presentation library churn to fadism, but I’ve seen it as a response to everything being pretty bad before React. Can’t blame people for desperately trying everything when everything is bad. React was really the first one for JS that really empowered people and every year it gets better.
Anyway in the sense that Reactive rendering is apparently a core element of flutter, all I care about is that the future is React-like, and in that sense React will be around for a long time....
> Dart (the lang used in Flutter) already failed to gain traction in the web dev community and nobody seems to be maintaining it there.
Dart for web underlies Hummingbird, Google's Flutter-for-web effort that was also announced as a sneak peak alongside the Flutter 1.0 announcement, so Dart for web is very much alive and maintained at Google.
You're missing the point. OP asked what would happen if Google abandoned the project, and it's pretty obvious Dart would die as it being maintained by Google, not the community.
Flutter is Dart's killer app, and don't think it's unmaintained. Dart 2.0 came out pretty recently with some much needed improvements, probably driven by Flutter.
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.
7+ years from early 2016, which means 4+ years today. Take it as you will.
The point being that just because Google uses something for AdWords doesn't mean Google will maintain it for the long run. I might find other arguments more convincing.
All technologies will get replaced by something else eventually. Presentation technologies have a short shelf life. GWT is 12 years old now, that's quite a good run.
History here is a bit important. GWT existed before jQuery was a thing. GWT was created for 2 reasons (from what I can tell): remove cross-browser differences and simplify development for a team that was already using Java.
That's factually incorrect. Development of Dart for the Web has never stopped. AngularDart is still officially supported, and under active development.
I have been a freelance Android Dev for past 4 or 5 years. I have recently built out a flutter app for a client. And honestly I am now looking for more Flutter work.
UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I enjoy it more than Javascript but like Kotlin much more.
The app I built with Flutter was pretty straightforward, so I haven't stretched the platforms capabilities, but hoping I get the chance to.
I haven't touched Android development since 2012. I remember the experience being a terrible hodge-podge of XML and Java which effectively required an absolutely attrocious IDE and an impossibly slow emulator. I assume things have changed since then, but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Those are still the not fun parts to work with in Android, although its better now kotlin extensions so you no longer have to refer to the XML directly to manipulate views.
Flutter doesn't use any of that, you just code and thats pretty much it. No XML or anything, and you can use VSCode which is a lot lighter than android studio.
Yes, tremendously so. It's still XML for basic UI, but Kotlin is the primary language of choice these days, Android Studio is a solidly world-class IDE, and the emulator is very fast.
> but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Flutter uses the regular Android emulator, and although you have more editor choice the recommended was to just use a plugin for Android Studio.
Your layouts & styles are typically all in XML. But honestly I don't find it bad - it's not "proper" XML, so there's not a ton of cruft. It's really more like XHTML.
Dart is "Fine" is the perfect description. It is pretty basic, but pleasant enough to use that it doesn't get in the way.
Kotlin, swift, rust, etc are more fun languages for me but Flutter is productive enough with Dart I am not about to ditch if becasue the language is decent at best.
Have you implemented any layouts using the Constraint Layout? Normally, I'd agree with you, but I find the Constraint Layout pretty great for designing UI's. The "glued together" approach makes responsiveness a breeze, imo.
I am a C++/mobile dev and I couldn't get myself amped about React Native because you have to do all the layouts through style-sheets. I am not a web dev, so style-sheets are pretty foreign to me beyond the basics. With flutter I can do all the same stuff but with auto-complete and in a hierarchy I understand.
I do wish the controls were native, but the customization you get instead is pretty powerful.
Haven't tried Flutter yet, but I feel the same way ever since React/Vue hot reload. It's a game changer. I really really miss it whenever I'm working on a site or game that doesn't support it. Once you get used to it, it feels painfully slow developing without.
Look at how many comments on this, or any other Flutter thread, mention hot reload.
What I take from that is this: if your toolchain makes rapid iteration easy people will figure out how to work around almost anything else.
Language/framework/tool creators rarely put enough time into the developer experience. And by that I mean the experience of a developer working with your tool for 8 hours a day. I can get more done with a crappy tool with 500ms compile time versus a perfect tool with 10s compile time.
I believe rapid iteration (and learning curve) is what made php and javascript (and delphi, anyone?) that popular.
I'm happy there's another platform but they really should use some existing language with mature tools and libs. Why reinvent everything again? Unless their real intent is to lock you to their own ecosystem and then mildly steer you to using or preferring to integrate with their own products.
BTW: Is dart really open? Publishing sources does not mean a thing, is Google making choices?
I've been using Flutter for a little over a year and I absolutely love it. Hot reloading, Dart tree shaking, Static type checking, etc. What's not to love? Dart widgets are consistent, making UI design easy peasy. UI widgets are definitely skewed to Android (for now), but iOS work is moving quite fast.
I've been following and using Flutter since release 0.2. I think Flutter is an amazing project. It makes writing concise and beautiful apps very easy. I've come to love Dart and the whole Flutter framework. I really think it is the best framework to write Android applications. It also works great for iOS were you can either choose to use Material or Cupertino components. It is a huge improvement over the old Android SDK; which is quite outdated in my opinion. It's too hard to create a beautiful app with the current Android SDK. To many hurdless. Flutter feels like what developing an Android app should be like today.
Another thing about Flutter is that it's also ready to work with Google's (upcoming; maybe) Fuchsia OS.
One loose end is still the plugins for native features on either iOS and Android. There are many community driven plugins which aren't really maintained. Fortunately there is also a large set of plugins maintained by the Flutter team itself.
I've tried Xamarin, React Native and Cordova (god forbids) and native development on iOS and Android. My preference is Flutter.
I've done one big(ish) project with Flutter and it's called "My Leaf" and it is a third party alternative to the NissanConnect EV app. It's used for controlling the Nissan Leaf and Nissan e-NV200 (both EV's). It's open source and available on Android and iOS;
I've seen some of the comments in this post talk about developing plugins for Flutter. I actually think it is easy and does not require much boilerplate contrary to what people say. My guess is that they really haven't tried writing a plugin but only peeked at the documentation.
Flutter renders the whole UI, like a game engine. In the past, this has meant that if there isn't a Flutter implemention of a component (like a video player or map), you couldn't add it to your app. I don't know if that's still true.
That's modern development for you. Shipping a copy of Skia so you can render exact facsimiles of Android widgets to a Vulkan context and avoid having Android render Android widgets with Skia to a Vulkan context.
A full Chrome copy for your desktop app is whatever, we have the resources, but on smartphones this is actively harmful. It bypasses the hardware compositors. Displaying a video, they have to render that to a graphics texture; on many smartphones, the IP that is doing hardware video decoding has nothing to do with the GPU and they might very well not use the same formats, requiring CPU conversion (if it's at all possible).
For bonus points you've probably broken accessibility on many platforms as the way that a11y works is intrinsic to the native widgets used by a platform.
I wouldn't assume that. It's literally the number one thing people bring up with custom UI components, I'd be very surprised if Flutter ignored the issue.
Oh I'm sure they didn't ignore is, just that you're constrained to platforms that allow a side-channel mechanism to expose a11y and handle focus+navigation.
I haven't looked deeply at the HTML5 APIs but if you wanted to say port Flutter to HTML5 Canvas you may run into problems where you can't expose rich enough a11y primitives on something that was just meant to be a bitmap.
As for new Flutter features, Google today announced ‘Add to App,’ a new feature that makes it easier for developers to slowly add Flutter code to existing apps. In its early days, Flutter’s focus was squarely on building new apps from scratch, but as it has grown in popularity, developers now want to use it for parts of their existing applications as they modernize them.
I hated this about CoronaSDK (how the framework would render everything like a game engine to one canvas). It was so much harder to debug things if the only way you can debug components is only within the scope of the framework, and you don't have any of the benefits of using the native views/containers. This means you can't effectively use Appium or UIAutomator or anything nice like that. If Flutter does render everything like a canvas, then that will pretty negatively affect my impression of it.
Correct. The XBMC/Kodi UI was developed with game engine tools for the xbox, and the way the UI worked the screen redrew at 60fps, or whatever, whether the content on the screen changed or not.
Like 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.
Here's some of the explanation about why they chose Dart:
> 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.
This actually makes it sound like native OCaml (maybe with the ReasonML syntax) would have been a good fit for Flutter. OCaml has a super-fast compiler, super-fast GC, and has (pardon the pun) reasonably good native interop.
No one uses Dart. No one is going to switch from React or Vue to Flutter when they can't bring over their TypeScript skills and tooling. It was a stupid, arrogant decision on Google's par, end of story.
I will. I am grateful that something like flutter exists and learning dart is very easy and would never be a showstopper for me. It is not like that we are not required to learn large amount of platforms and languages anyway.
> Why they didn't just choose Typescript or go with native javascript is beyond me.
They needed to be AOT compiled. Can't ship a JIT on iOS, after all. And JS is very unfriendly to static compilation. Dart is considerably better suited for AOT due to static typing.
There are other languages that are GC'd & AOT friendly, though, so I can't help you with why they didn't use any of those, though. But why they wouldn't use JS is pretty straightforward.
I'm curious to know your thoughts on what makes Dart a mediocre language. At first glance, it seems to be merging the best of both worlds (can be AOT compiled for prod and JIT for dev)
I would kinda even prefer Go. Learning Dart is really specific to Flutter, I wouldn't end up using it for anything else. Go is kinda useful.
I have played with Flutter before and liked it, but was annoyed about the lack of what are now called PlatformViews. I might give it another shot now.
I just wish I could consume it from a different language, Go, TypeScript.... C# even Kotlin. I don't love learning a language for a single purpose if I can help it.
> One of the challenges that React Native developers face, or have reported in the past — one challenge is that native React Native code is written in JavaScript, which means that it’s run using the browser’s JavaScript engine, which immediately kind of move this a little bit away from the native model of the platform.
Calling React Native “not native” while eschewing platform UI widgets is a bit thick. I’d actually of the opinion that React Native is “more native” than Flutter is; it might be a bit slower but it is much easier to build apps that could pass as actual “native” apps because the React Native team doesn’t need to try to emulate system controls.
> React Native team doesn’t need to try to emulate system controls.
The solutions for push navigation across Android and iOS using React Native were pretty poor and didn't emulate system controls the last time I used them. Has that changed?
One of the main issue with Flutter is that you can't embed a native view inside a flutter widget tree. This makes it limited as we can't have inline maps or custom video views.
There are people working on it. The progrss has been slow. I checked a couple of weeks ago and the issue was still open.
But as far as I know you can have a native view in its own activity.
Though not a blocker for simple apps which previously used Cordova or ionic, I don't think Flutter is ready to replace native development for immersive apps.
Embedding a native view in cross platform UI is possible with Xamarin and React Native, so they are more practical choice for certain types of apps that need this.
Google has a history of introducing products and then killing them. For developing mobile apps they currently support "vendor native" via Android Studio using Java or Kotlin, Progressive Web Apps, and now Flutter.
Will Google really support all three over the long term?
If you consider APIs that power its businesses, Google's support history is a lot better. Dart and Closure were never popular outside Google, but they're still invested in because they are used internally.
Android and Chrome are both heavily invested in by Google, with massive external ecosystems too. Speaking in a personal capacity with no insider knowledge, I'd be shocked if Google stopped supporting either.
I want to note that Dart and Flutter are being used for Fuchsia it seems like[0]. I'm pretty sure that Fuchsia is a big project Google is not going to abandon so Dart and Flutter are probably safe.
There is the chance of them throwing it away maybe noting it as an experiment on the way to whatever they land on inside Fuchsia but the amount of developer ire they would draw is hard to imagine.
Fuchsia is to Google as Tizen is to Samsung... something keep in the back pocket for a worst-case legal total war, but unlikely to see any real world use.
Really? but Fuchsia isn't just a mobile operating system -- I think they want to own all the software at almost every level. I wouldn't be surprised if they started running their own hardware and laptops with Fuchsia as well if it was good enough.
It's a bit cynical but I think they might even want to just bin linux as a base for Android and migrate off of it completely, get their notebooks/chromebooks on Fuchsia, and make a play for OSes to run on. Think of how much data they could get for the industrial advertising complex at the OS level.
> If they try to pull that off, all their partners will drop them like a hot potato.
At that point, will they have a choice? I mean most partners already bow to Google's control over AOSP -- if they said tomorrow that android was actually switching to run on top of fuchsia (let's say they did all the work to make it happen, so it was "seamless"), everyone would just be like... "ok".
While I'm not sure I necessarily want Fuchsia to fail, I'm 100% with you on it being likely better for the world if google didn't own everything...
Lets put it this way, Google already made most of the work with Treble and yet it isn't being adopted as they thought it would, making them finally take a stance regarding updates.
A Java fork failing to keep up with standard Java, winning on where Microsoft failed (aka Google J++), thus forcing Java library authors to either write two versions or constrain themselves to the common subset.
Meanwhile, there are plenty of other Java vendors that are able to create their own Java implementations and play ball with the rest of the eco-system.
Maybe that's not that bad, considering the fraction of Java libraries that used simultaneously in Android and Java ecosystems isn't very large. OTOH if Fuchsia wins, we loose the open source mobile OS, the major one, the only one, with tons of apps and ways to ungoogle.
The widget layer of flutter is Skia which is written in C++ and Flutter apps compile to ARM binary (native) code. Someone else asked about whether a Flutter app can be ported to Linux; why not compile both the logic and the UI directly to WebAssembly?
WebAssembly compilation is a little orthogonal to getting the framework and rendering system up and running. We do not have to wait for WebAssembly to make progress on the UI side of things. Having said that, when WebAssembly is available for us to try, we certainly will.
Looks cool but not too much of cross-platform - iOS and Android only. It seems the only really cross-platform GUI technologies still are browser-powered and Qt.
I did a small app in flutter last week out of curiosity (fetching rss/atom feeds, rendering html content) and was surprised how easy it was to work with tooling that flutter provides. Also was pleasant surprised on how well Dart fits in to this use case. Go flutter!
Congrats on their 1.0 launch! I haven't looked too closely at Flutter yet, to be honest. How does it compare to React Native (besides what a basic Google search will yield)? Has anyone jumped ship for either or after trying one of them?
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 controls. Advantages: since this rendering layer and widgets are compiled from C++ the performance is excellent. Disadvantage: if you want a widget that isn't in the current set of controls and your C++ skills aren't up to the task, you'll be left wanting to do things you cannot. Not sure what scenarios are affected by this but it's something to keep in mind.
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.
I’m going to be a little bit pedantic, but that’s untrue. On React (DOM, Native…) you create your widgets with React, and compose them as components.
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.
I'm guessing most answers will be about Dart being the hard pill to swallow for most, and the fact that it render by drawing UI instead of orchestrating like React Native.
I still prefer RN, and I don't my opinion changing in the future. I prefer controlling a native view for the apps I make. Maybe a game would be easier with Flutter?
Dart compiles to native ARM binary; a colleague of mine who uses C++ for cross-platform mobile development made a demo app in Flutter, decompiled it, and said it looked like what his C++ apps produced. The JavaScript in your React Native apps won't perform as fast.
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.
I'm currently using it as an hobby for creating simple UIs.
It's actually pretty easy, and it feels more like a newer QML kind-of language.
And I like Dart's syntax, coming from a C/Java world.
Seemed like a lot of the app highlights in the highlight real video had jank, either when scrolling through a list of images or animating card swiping. Anyone have insight as to why?
Does anyone have a feel for how good flutter's documentation for canonical approaches to common use cases are now? The last time I tried it, even a simple task like changing the UI when returning from a login screen was unknown territory for many developers. The examples in the documentation were all for single screen simple apps. Has this changed? Or is the community still trying to figure out best practices?
flutter's community feels like Xamarin's community - people who are already well versed in both android and ios development looking for a common codebase solution. very much lacking in the documentation section in terms of how you get from A to Z. everything is "Z can be implemented this way" w/o any discussion of how to use it in alternate ways(like how the android and ios dev documentation is structured)
i'm gonna jump in coz it seems interesting but i'm super afraid of the iOS painpoints i'm going to hit(I have no knowledge of iOS development just android)
I don't understand why Apple is the only one left that uses a strongly typed pre-compiled native programming language. It really isn't hard to use Swift compared to other programming languages. And it's a really nice to use, safe and if you want it to be also a language that allows you to write really fast algorithms.
Dart is strongly typed and pre-compiled, at least when packaged. It can run in interpreted mode in development for live/hot reload: a major advantage over Swift. Flutter also provides a first class Reactive UI story: something sorely lacking in native iOS (or Mac) development.
PS Java (or Kotlin) are AOT compiled in all recent versions of Android.
> Dart is strongly typed and pre-compiled, at least when packaged. It can run in interpreted mode in development for live/hot reload: a major advantage over Swift.
Ah, that's how they do it. That's neat! But the language still has to deal with JavaScript compatibility.
> PS Java (or Kotlin) are AOT compiled in all recent versions of Android.
But it's still a mess to call native code. And still has Java garbage collection.
Microsoft supports C++ and pre-compiled C# for Windows UI development too.
As a UI dev, I'd much prefer the hot-reloading that you get from Flutter, React Native, and web UI development though. But I still care about battery life and global warming so it can be hard to justify the flashy new stuff for most the UI development I do, which is mostly just list views.
I'm also weary of the post-mortem debugging experience for these higher level frameworks. C++ is nice for this given that usually the OS and UI frameworks are implemented in it too, at least on Windows.
Having using Flutter since the alpha releases, it's great to see how the framework has evolved to a production-ready release. Honestly, learning Dart isn't that difficult nor foreign if you're coming from a low-level language such as C#/C++/C or Java. Been enjoying using it since.
I'm not sure why you'd be referring to me in the third person while replying to me, but if that's the case then yes, it's quite possible they've improved.
> SWF content on all platforms other than iOS is JIT compiled
To be able to publish on iOS, there Adobe AIR compile to native binary.
On Android, Windows, and macOS (also Linux) it does not to do that (eg. it is fast enough), so instead you have the choice to publish an app that need the AIR runtime, OR to publish a captive runtime (it bundle inside the app).
In general, most dev use captive runtime and so you don't need the AIR runtime installed first.
Now, keeping a runtime bundled vs compiling to native have numerous advantages, for ex you can make part of your app dynamically updatable without re-installing the whole app.
Technically Adobe have the tech in the AIR SDK to compile to any native target, they just use it for iOS.
Flutter looks cool. Dart needs more of an ecosystem though. I was trying to play with flutter last week, gave up when I discovered there is no standard lib FFT implementation in Dart.
I disagree. Something rarely needed like FFT should not be included in any stdlib. Keeping it out too allows better control and more frequent releases.
They shown the integration today. Its so cool you would be blown away if you saw that history of everything app demo. I am not able to find the demo app. Its in the live stream.
How does flutter handle BLE/WiFi communication to hardware, rendering graphs, NFC, device sensors? Any comments on the experience? Do you recommend it?
Don't think there are builtins for that, Flutter is more focused on drawing UI. For functions like these it usually just makes sense to call the native APIs over a bridge (there's a bridging mechanism included in Flutter - you pass messages over channels to and from the native code).
I haven't used either, but Kotlin is a programming language you can use on Android -- it's essentially another JVM language as an alternative to Java -- whereas Flutter is a UI toolkit you can use on multiple platforms (mobile and desktop), think of it as analogous to Qt.
If you're looking for a wasm-enabled toolchain that runs native apps in a similar way you should check out nativescript[0], I don't think they support it yet (?) but that's definitely where it would land first.
Another example of where they follow standards/stick to browser specs is their use of web workers for background tasks [1]. In comparison Flutter uses dart isolates[2] which makes sense of course, since they use Dart -- similar performance models (do hard stuff in another thread).
in today's keynote, google announced that you'll eventually be able to use one dart/flutter codebase for ios, android, mac, windows, linux, and the web. you can't get much more cross-platform than that.
I am aware that you can build one codebase for all those platforms, the question is whether all those platforms are supported. In particular https://github.com/google/flutter-desktop-embedding still says that desktop use of flutter is unsupported.
DISCLAIMER: Opinions expressed are my own and do not reflect my employers views.
I don't understand why we have to keep reinventing GUI toolkits and layout engines over and over again.
Why can't this domain be smarter like Compiler world and build pluggable components?
So something like, a react-engine that renders the recently changed display node.
The react-engine is offered as an API/library layer, it could be run in browser where it works with DOM, it could be run in a desktop where it works with GUI nodes of native GUI toolkit.
So now going from each OS to another, you don't have to learn gazillion different ways to specify the layout. The type of nodes displayed on your GUI app changes from each environment to another. So you get to have the same programming techniques and you can get a web-app or a desktop app.
It's one thing to draw some widgets. That's the "easy" problem (to borrow some AI jargon).
It's totally another thing to specify how these widgets read and write the model in which the business logic is encoded. If you want to animate transitions between valid model states, it all gets ten times as complicated. And then when you try to make it performant by eliminating redundant redraws, it becomes an even bigger mess.
There is no simple and obvious solution that tackles all of the above. The reactive UI model (not just Flutter, but all React-like frameworks) is an ongoing attempt to do a better job of all of it, with varying success. Existing UI toolkits, before the introduction of this model, were not designed for it. They were built on the assumption that the future would be a giant object graph caught in a tangle of callback methods. If you want to make a reactive UI populated by native widget objects, you have to figure out how to plumb all their mutable state back into the reactive model. That's an enormous investment of labor. Writing a new toolkit from the ground up is a huge amount of work in absolute terms, but in relative terms it's the easy way out.
Thanks for your reply - it was a pretty insightful rebuttal.
Do you think in the future it might be possible for say Flutter to:
1. Refactor flutter into a layout engine and gui widgets
2. Provide the layout engine as an interface on all desktop OSes. Something like a standardized syscall like interface.
3. Anyone can implement a new GUI toolkit to this layout engine interface.
4. For desktop OSes, the number of styling options is less
than full blown CSS capabilities(in HTML dom) and these options get compiled out, making execution of native apps GUI slightly faster than DOM apps. Basically, desktop GUI styling is a subset of DOM CSS styling.
5. We use a JSX like templating language to specify UI that either gets compiled to HTML or generates native GUI widgets.
Not sure all of my thoughts are 100% fleshed out but does this sound feasible in future?
It's hard to get a single OS vendor to implement a universal UI toolkit on their own OS. Thankfully, Apple standardized around Cocoa/ObjC. Microsoft keeps proliferating new, incompatible ways to approach application development. Linux has multiple incompatible toolkits pretty much by design.
It's strange to me that after all this time, every time a thread about Flutter reaches Hn or proggit, there are multiple comments about the choice of the Dart language.
I think they've made it pretty clear by now that they don't have intentions of switching from Dart. Heck, they've published an entire "Why Flutter uses Dart" article explaining their reasoning.
It's like beating a dead horse.
Besides, you could always just not use Flutter if you dislike it that much.
Their whole reasoning just feels like justification after fact. specially when one has experience with older development environments which offered similar developer workflows.
I guarantee to you that if they had choosen a proper modern language, Flutter's uptake would be much higher.
As it is, you will see many of us complain about Dart until Flutter ends up being replaced by something else, unless they force Android developers to actually use it.
You said you can't be bothered to learn dart because you want to build your skills in c# etc. As a result the only criticisms you can make are devoid of content: It's not a proper, modern language (what?). It's struggling for survival...
Sure, you do what you want, no one is stopping you.
But I guarantee you'd be amazed of just how quickly you could go from installing the Flutter plugin into VS Code to actually developing a fully hot-reloaded app inside an iOS emulator. The DX of Flutter is by far the best I've seen anywhere.
Given the number of times I've seen pjmlp complain about Flutter choosing Dart. I think he/she could have learned the language in less time than writing all of those comments.
I'm not a fan of Dart either, but common JavaScript/TypeScript isn't exactly the holy grail either. JS is basically unusable due to, well lack of types, and TypeScript hacks them into it by hugely increasing complexity of everything.
Should have gone with Kotlin. Would just sweep over huge amounts of existing Andoid devs too.
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.
Which is sad because I would really want to have some fast and easy access to useful c++ libraries without wasting lots of time writing and maintaining tons of bindings for Java, ObjC, C.
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.
So far it seems the easiest way to call c++ functions is using ObjC++ or Qt framework.