[hliyan]

I've been playing around with Flutter for a few weeks now and I'm convinced that this is the future of cross platform app development. I was initially put off by having to learn an obscure language (Dart), but the reality is, it's a lot easier to learn than learning all the semantics, tools and practices that come with a massive ecosystem like React.

[ryanwaggoner]

Eh. People have been saying this about cross-platform frameworks for what, 25 years?

“Build once, compile everywhere!”

They all come and go, but native seems to always win in the end. It seems like the hierarchy over the last couple decades in terms of “market share” for successful projects is: web > native app > hybrid app. I really doubt any framework is going to change that, or become all that dominant within what is basically a small niche.

[fauigerzigerk]

Flutter is the native toolkit on Fuchsia though. If (as some expect) Fuchsia is the Android successor (or somehow merges with Android) then we will be in a different situation.

The native UI toolkit that powers 85% of all mobile devices will then also be usable on the remaining 15%. That changes the equation for all but the most high profile iOS apps.

[everdev]

I'm evaluating it. Why do you think it's the future? What's the feature you value most?

[hliyan]

I've been a React fanatic for several years, so my opinion is colored by that:

1. Great DX (developer experience) - a single language (Dart); no need for JSX, JavaScript, JSON, Flux/Redux and various other libraries. You can focus on the business logic rather than battling the ecosystem.

2. A single set of components (no iOS or Android specific navigator components etc.)

3. No longer need a JS engine to run - truly native

4. As fast as promised

[grigy]

Being agree with all 4 points I see two drawbacks:

1. Not using OEM widgets. Even the rendered widgets may look good, they can't beat the native widgets optimized for the particular platform.

2. The choice of Dart as the main language.

I can understand both points though

[quangio]

I don't think using non-OEM widgets is a bad thing because it's not like Electron; Flutter uses Skia to render widgets, and it's fast. There is an article https://medium.com/flutter-io/why-flutter-doesnt-use-oem-wid...

[foepys]

I'm always concerned that accessibility is being left behind. Android and iOS both put great efforts into making their UI accessible, why do the work again? Chances are that the accessibility of those third-party components will be worse or maybe doesn't even work at all.

[egeozcan]

The problem is that the accessibility work already needs to be done on every platform (for now we have two really popular ones but nobody can be sure what the future brings).

Also, if you could just recompile your app for a new platform and release (more or less), it would remove the biggest barrier to entry for possible new platforms: Adoption.

[malkia]

I love Flutter, and how it looks, but while I was at the Google I/O Extended I was given an Android Things Kit. That specific version of the kit did not had GPU, and later (at home) when I tried Flutter - it was running very slow, while other android apps were manageable.

Then again, this is more of an outlier (today) with the GPU present almost on any mobile device, but still something to know about (e.g. flutter won't be of good use there).

[gcb0]

that's an interesting point. wonder how bad it is for battery since it takes away the cpu/gpu decision from the OS

[mwcampbell]

From the article:

> In other words, in today’s market, a branded, custom UI is king.

Does a custom UI per app not make it more difficult for people to learn each new app? Didn't the platform developers write their human interface guidelines for a reason? Or was that level of consistency only necessary in the early days of Mac and Windows, when the temptation was to port a DOS app straight over rather than redesigning it as a GUI?

[yorwba]

Platforms also like their branded, custom UIs. When you build an app that uses the platforms widgets, you reinforce the platform's brand. When you use the same look everywhere, on the web and for apps on each platform, you reinforce your own brand.

If platform developers cared so much about consistency, they wouldn't change their UI design just to freshen up their image or because design trends have changed. Maybe looking and behaving like everyone else really has a major influence on user adoption, but it usually seems to be ignored in favor of branding.

[IshKebab]

Not using OEM widgets has huge advantages too though - easier portability, you can preview any OS style on any device (e.g. develop an iPhone app even if you don't have an iPhone), you don't rely on the underlying platform as much (e.g. if maybe that platform doesn't get updated very reliably!).

Really the only downside is that it is a ton of work to make it match the look of the native widgets. They've done a good job though. I really doubt 99% of people could tell at all.

Dart is ok. Better than Java or Javascript at any rate!

[cageface]

It’s true it’s very difficult to completely replicate the look and feel of a native toolkit with something like this.

However, my experience has been that most people want a heavily customized and styled UI that looks similar on both iOS and Android because a generic stock UI doesn’t have enough visual bling to attract users or establish a strong brand. And it looks like doing that kind of customization should be a lot easier with Flutter than it is with either native platform’s native APIs.

[skolemtotem]

How is it native if you're just replacing a JavaScript VM with a Dart VM? Or is the Dart somehow compiled to native code?

[tybit]

Dart has a VM (with hot reloading) for dev time and an AOT compiler for release builds.

I’d say that’s one of the most attractive things about Dart to compensate for yet another language.

[pritambaral]

How large and invasive is the Dart runtime though? Running in a VM and running with a runtime are only so far apart. And I'm interested in distribution package sizes too.

[afsina]

Here is some info: https://flutter.io/faq/#how-big-is-the-flutter-engine

[myguysi]

You’re right, it gets compile to native code

[bmpafa]

I view the absence of JSX as a liability. I like flutter, but I find a lot of the syntax to feel 'different for the sake of different.'

[ma2rten]

I tried both Flutter and ReactNative. I am not an expert, so take it with a grain of salt, but here is my first impression:

I would say the best part about it is the hot reload, which maintains application state. It's compiled to native code so it's going to run faster than ReactNative which is a javascript bundle that runs besides your app. Compile times are fast, but not instantaneous and you have to trigger the reload manually.

I think it also has the most complete implementation of Material UI out there. It implements widgets that are not implemented in iOS, Android nor Web. It's like having something like bootstrap that makes it easier to build a good looking app. I feel like you really need a mock first to build a reactnative app, but you could get away with just writing code in flutter.

Unlike ReactNative there is no way of trying it without installing the Android or iOS development environment. Initially that was a bit of a barrier for me as a first-time mobile dev, but not a big deal eventually.

It's not as mature as ReactNative. There was no build-in way to do audio, something I need for the app I am trying to build. However, I found a plugin for it on github.

I know Google has a reputation of canceling projects, but Flutter is used to develop the Google AdWords app so I don't think it will go away anytime soon.

[eklavya]

You don’t have to reload manually. Reloads automatically, make sure you have turned on reload on save in vs code or something similar in IntelliJ.

[ma2rten]

I see. I am using vim + commandline.

[yorwba]

You could try writing a shell script using inotifywait to look for changes and then notify the program that it needs to reload the code.