Hacker News new | comments | show | ask | jobs | submit login
Google's cross-platform Flutter UI toolkit goes 1.0 (techcrunch.com)
544 points by mikece 10 days ago | hide | past | web | favorite | 327 comments





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.


I think you mixed UI code with platform channel code. The only code that use platform channel is this line.

https://github.com/flutter/flutter/blob/master/examples/plat...

I really hope flutter can provide a guide for FFI though.


> 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.


You can also use .NET Core (instead of python) with QML/Qt.

https://github.com/qmlnet/qmlnet

note: I'm the author.


Sadly, Qt has so many threats on their download pages that I feel it's only suited to companies that can keep full time lawyers on payroll...

What? Qt is mostly LGPL. You don't need a lawyer.

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.

Yum install epel-release

Yum install qt5-


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.


A great toolkit like Qt, including Qt Creator and UI designers, doesn't get written during late nights and weekends.

They are pretty cheap considering the typical prices on their target markets, embedded tooling, medical devices, enterprise solutions.

Naturally they decided to pivot to those markets, as Trolltech has hardly seen any significant monetary profit from FOSS.

So it is only fair that those that don't want to pay, also ship code free to the others.


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.


Most embedded tooling is free nowadays. Free software has eaten the world and will continue to do so.

I will use a free UI toolkit when I can. Qt will kill itself with their current pricing model.

Automotive is moving towards Android. Qt is not good for medical either because it is not really certifiable.


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,...

Qt is certainly certified for medical use, https://www.qt.io/qt-in-medical/.

I have hardly seen any big Android Auto adoption.

The biggest foe of Qt in Automotive is Web stack.


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.


> The trend is towards more and more software being licensed under licenses such as MIT.

Which is exactly my point.

Give the tip of the iceberg for free, charge for everything else and give as little back to upstream, if anything.


only if there was a startup doing embedded chips with gpl firmware...

All you have to do is link dynamically.

> However it seems you can use PyQT5 on mobiles nowadays.

You can use it, but is it easy to use and build and deploy?


> 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.


> On mobile? Qt really isn't pleasant or usable on mobile.

What's wrong with it?


QtWidgets aren't really geared for mobile. QML however is fine

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


Some boilerplate to write a custom native plugin is better to me than the dependancy hell you get on ReactNative.

That being said - my personal usecase would like a direct C++ interop, and flutter is working on it. See https://github.com/flutter/flutter/issues/7053

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.


It seems the like the newer Dart FFI effort will benefit current users of the Dart C API, which is great news...

Dart C/C++ interop hasn't been a super-bright spot so far, and I am _beyond_ glad to see it's about to change.


No, the relevant code for the function is ~10 lines

The rest is UI and application boilerplate



How is the UI/UX differences between android/iOS apps handled with flutter?

e.g. iOS HID requires navigation buttons for obvious reasons & not so for android.


> 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.

Use the right tool for the job. Always.

If Flutter can't handle it, it's not the right tool for the job.


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.


It depends on what you mean by best.

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.

> Unsurprising consistent behavior is a value.

Looking at the last 30 years of software development, it's pretty clear that users don't care very much.


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.

Yet the most popular OS is Android...

Website (+responsive mobile sites) have been using custom UIs for years and no one bats an eye

A framework for mobile uses custom UIs and everyone loses their minds?


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.


> Most web apps are used on desktop, not mobile. On mobile, it's mostly native apps that are used. So they're not substitutes.

This needs some citation


Many "native apps" are just "hidden" web apps, users just don't know it.

Such as?

Every Cordova (https://cordova.apache.org/ -> search for showcase) or PhoneGap (https://phonegap.com/app/) app.

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

This doesn't actually happen.


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.


WPF uses DirectX.

Thanks! Makes sense if it uses DirectX, not sure why I got skia into this :)

There is a x-plat open-source UI framework heavily inspired by WPF called Avalonia that has a Skia renderer.

flutter uses skia

Material UI just happens to be the official Android UI.

Which is irrelevant to my point, which is that it's also used where it's not native.

So Cocoa is missing from your list given iTunes on PC.

Sure, and many others are also missing. I gave some examples, not an exhaustive catalog.

This is hinted at where I say "Google, Facebook, _and other top dogs_", and "_e.g._ Material UI" -- emphasis mine.


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.

Google Spreadsheets has horrendously bad UX on the iPad Pro

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.

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.


What sort of "other purposes" would it serve for the UX to be worse? Do you have any IRL examples of this happening?

Sure I wrote them in another comment here: https://news.ycombinator.com/item?id=18604613

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.

It's unclear to me that this is a sticking point.


Two Google teams talking to each other and syncing their agendas and deliveries (or two teams in any big company) is quite a major assumption.

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.


In fact, so far Android team members have only given political correct answers when asked about Flutter.

> "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.


Chrome on iOS exists. I think you meant to say it uses WebKit (and native font rendering) instead of Blink.

A distinction without a difference.

ok

>... 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.

[1] https://pasteboard.co/HQdDD4r.png


Flutter looks amazing!

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.


That's what I thought about Tcl/Tk.

Tcl/Tk is 30 years old.

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.


React will definitely make 10 years. It’s almost at 5...

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....


> I would be willing to bet my retirement that none of the now-popular presentation technologies will be mainstream 30 years from now

X-Windows? That thing started life more than 30 years ago, and still going strong on Linux.


More due to inertia and inability to get Wayland ready than anything else.

Pattern recognition is killing innovation. https://www.forbes.com/sites/valleyvoices/2018/09/14/pattern...

What is the relevance of Tcl/Tk here? AFAIK both are still maintained and developed and used by a lot of projects.

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 (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.

Dart 2.1 is now available as well. So still kicking! :)

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.

GWT served them well for 8 years. Now the Dart one is expected to last for the next 7+ years.

Read this interview if you're interested to learn more on their reasoning: https://news.dartlang.org/2016/03/the-new-adwords-ui-uses-da...


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.

> GWT is 12 years old now

And Google hasn't maintained it for five years now, which is the point.


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.

> GWT, which is no longer maintained by Google

This is not entirely true, although the goal shifted over the years and progress (outside Google) is very slow. See J2CL, jsinterop, and elemental2.


> nobody seems to be maintaining it there

That's factually incorrect. Development of Dart for the Web has never stopped. AngularDart is still officially supported, and under active development.


Nobody in the community. Context is key.

> working on a crappy hobby app for fun

That's where it's best to explore and take chances. The only risk is wasting time.


Risk of wasting time, upside of having fun and learning.

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.


> I assume things have changed since then

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.


Is there any alternative to XML? How often do you find yourself hacking XML directly?

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.

It works fine.


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.


> UI development in Android is such a pain

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.


Are you familiar with Kotlin and Anko?

Can I ask was the UI quite simple?

Flutters Hot Reloading has spoiled me forever.

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.

The first time I experimented something like that was in Smalltalk/V.

Followed later by the Oberon OS.

Eiffel also offered a similar experience with their MELT VM and compilation to native code via C code generation.


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?


https://flutter.io/docs/resources/faq#why-did-flutter-choose...

"Is dart really open? Publishing sources does not mean a thing"

BSD license, ECMA standard.... https://github.com/thosakwe/xart


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.

Try it, you'll love Dart.


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.

[edit]: It looks like this has been addressed with the PlatformView widget: https://developers.googleblog.com/2018/12/flutter-10-googles...

[edit]: Sorry, bluetidepro - this was supposed to be a reply to you.


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.


Seems like some research and benchmarking into this potential issue is in order.

They just addressed this in today's announcement:

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.


They recently added "PlatformView" which allows you to embed any native (Android/iOS) component in the app. Sample: https://medium.com/flutter-community/flutter-platformview-ho...

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.

There's a demo of running native tests that also test flutter on iOS here: https://github.com/flutter/ios_add2app

> like a game engine

In this aspect it's very similar to Flash or QT.


or canvas or kodi (which has been improved now to not refresh the entire screen.)

you mean this Kodi https://kodi.tv/ ?

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.

That will always be Flutter's weakness.

You also don't get to use the wealth of libraries that target native development.

Cross platform always has trade-offs.


There's definitely been work on this as another commenter mentioned, and a first-party Google Maps plugin

How does interactive debugging and inspection work? This is the true power of the web as a platform.

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;

https://play.google.com/store/apps/details?id=dk.kjeldsen.ca...

https://itunes.apple.com/us/app/my-leaf-for-nissan-leaf/id14...

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.


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.

From https://softwareengineeringdaily.com/2018/07/09/flutter-with...


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.

As someone who use Java a lot and don't favor Javascript I'm grateful there is Dart.

Typescript isn't JavaScript

In fact, one of the best thing about typescript is that you can bring in almost everything you know about javascript into the game.

It took me few days to pick it up when moving from JS to typescript. I don't get it when people say it is complex or adds complexity.


> I don't get it when people say it is complex or adds complexity.

js is the complexity people are worried about. the number 1 reason i'm considering going to flutter over react is having to learn js


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.


They won't stop pushing Dart, thanks to success of Go, yet another 'good enough for the job' mediocre (at best) language.

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?


Not sure. But Flutter can't even get switches and text fields to work right, so it really has much further to go than React Native does.

I’m building my first RN app right now and I feel like the navigation animations are native (modals, etc).

(I’ve been doing native iOS since 2009)


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.


I think this is one of the things they announced today, search for "Platform Views": https://developers.googleblog.com/2018/12/flutter-10-googles...

Here is the list of issues with current implementation of "platform views": https://github.com/flutter/flutter/labels/a%3A%20platform-vi...

Google Developers' Blog has just posted an announcement on Flutter 1.0:

https://developers.googleblog.com/2018/12/flutter-10-googles...


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.

The UI for Fuchsia is written in Flutter, so it's got a pretty big internal customer too: https://fuchsia.googlesource.com/topaz/+/HEAD/shell/


You mean the OS that is developed independently from Android with completely separate teams and that nobody knows where it will be in 2 years ?

Since this is Google we are talking about, no warranty that this will ever go on one of their flagship phones.


That's just a senior dev retention project.

Or maybe not, and that's Android vNext.

Meanwhile they are adding Fuchsia support to ART, so go figure.

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.

[0]: https://9to5google.com/2018/03/02/fuchsia-friday-first-fuchs...


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.


> I think they want to own all the software at almost every level

That's what everyone wants to do. Guess what, Google might be big, but Android is big because Google has many partners.

If they try to pull that off, all their partners will drop them like a hot potato.

And I agree with you it's probably to ditch Linux cause Linux has too much political baggage, i.e. they want to fully control Fuchsia.

For us, it's probably better if Fuchsia fails.


> 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.

https://android-developers.googleblog.com/2018/11/an-update-...


From my point of view it looks a big internal politics war.

Whoever wins, we loose.


What we loose if Android side wins?

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.

On the other hand, we'll finally have an empirical resolution to the Tanenbaum-Torvalds debate!

Intel already did that for us with the Management Engine.

And if you squint a bit through how modern Treble drivers work, Google has turned their Linux usage into a kind of micro-kernel OS flavour.

https://source.android.com/devices/architecture/hidl


Since Kotlin on Android Studio is 100% JetBrains IP, I wouldn't be worried on that front.

What you think they want to let Facebook control mobile development?

Google rarely kill open source projects.

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?


Holy smokes! That's awesome! (I was aware of the desktop embedding, but also on the web... that's really cool)

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.

Platform views and especially Hummingbird are huge announcements. Wish the OP linked to the dev blog instead:

https://developers.googleblog.com/2018/12/flutter-10-googles...



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.

iOS, Android, and Fuscia. I just found out that there is now Hummingbird for web as well.

Does Fuchsia use the Material renderer, like Android?


They literally just previewed Hummingbird.

They just announced desktop and web support

Cool! Where can I find an example project to start with if I want to build an app for Linux and Mac as primary targets?

There is an embedder engine API that can be used for other platforms.

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.


Parts of React-Native are also written in C++, btw.

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.

If you have any experience with TypeScript, Dart isn't that different.

Looks like dart even uses an event loop. Their examples for handling futures look very, very similar to Javascript (and typescript, of course).

https://webdev.dartlang.org/articles/performance/event-loop#...


Reflectly rewrote their app from RN to Flutter: https://medium.com/reflectly-engineering/reflectly-from-reac...

someone did a performance test on android react vs flutter vs native app see https://robots.thoughtbot.com/examining-performance-differen...

The original study fell short on rigor and the author posted an updated version here - https://robots.thoughtbot.com/examining-performance-differen...

Would love to see something like this extended to the Linux desktop.

This is what the flutter-desktop-embedding [0] project is trying to address.

[0] https://github.com/google/flutter-desktop-embedding



Damn - that VSCode theme and color scheme from the screenshot in the article looks really nice.

Does anyone know its name?

1: https://techcrunch.com/wp-content/uploads/2018/12/pasted-ima...




The terminal theme looks similar to agnoster:

https://github.com/robbyrussell/oh-my-zsh/wiki/Themes#agnost...


Oh man, if this could get things like Signal Desktop off of Electron, I would be so happy...

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.

It does currently work on Linux, although fairly barebones. You can Google "Fluttet desktop"

That's interesting considering Linux on 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.

For those who don't know: The app on the first screenshot is inkino [1] which had two Show HN in the past months:

- https://news.ycombinator.com/item?id=16818170 (42 comments)

- https://news.ycombinator.com/item?id=18399542 (version 2.0, 2 comments)

[1]: https://github.com/roughike/inKino


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.

Disclosure: I work at Microsoft.


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.

It is the latest crush of every developer. Learn what are the top features of this new app framework: http://soo.gd/UbXY

Looks nice. I find it similar to Adobe AIR but with DART as programming language.

Except Adobe Air doesn't compile to native and the apps don't run until you nag the user to download the Air runtime.

I guess someone is very outdated on their information.

https://www.adobe.com/devnet/air/articles/aot-or-interpreter...

Air supports native compilation since 2012!


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

Cool, but I use Android.


No it does not work like that.

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.


Yeah I saw that. It's just maintained by some random guy. Which is great and all, but something like fft should really be part of the standard lib.

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.

How does it handle integration with maps libraries (e.g. Google Maps) and BLE support?

Anyone has any experience with how well those work with React Native, and could share their experiences?


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.

There's a first party Google Maps plugin, and there's a few BLE plugins, which work pretty well (using flutter_blue in production right now)
More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: