1. 15

What do you think about Flutter? Some people seem to really like it, others hate it. Curious what the Lobste.rs community thinks

  1.  

  2. 18

    Flutter: because QML was Not Invented at Google.

    1. 10

      I personally do not think this a good investment of time (unless you plan to work at Google, or benefit somehow from their sponsorship for your work).

      My reasoning is very subjective.

      Flutter is meant to allow cross-platform mobile development, plus web.

      React Native + React native Web do that for me, without injecting new programming language, new runtime and complete new, yet to be developed ecosystem.

      Dart is not a language with any revolutionary theoretical underpinnings. Dart, the language behind Flutter, is not going to make your deadlocks, unfreed lists, incorrect async state management - to be detected at compile time.

      Again, subjectively, I appreciate Google’s leadership in many technical areas (for example server and protocol security, some aspects of machine learning, backend infrastructure management). I do not think, however, they are leaders in ‘convergent mobile platform development’, or ground braking programming language research and dev (compared to MS, for example). Not yet, at least.

      I do hope, they port Flutter to android JVM, OpenJDK and .NET, and Swift. And as a library, and with Web/JS – this could then be, quite attractive, and compete with React/React native / React native web.

      1. 1

        I do not think, however, they are leaders in ‘convergent mobile platform development’, or ground braking programming language research and dev (compared to MS, for example).

        I would say they proved themselves very capable with Go. Although I agree about Dart, I just see it as an unnecessary new language that locks you into the Google ecosystem. It’s probably supposed to be to Java what Swift is to ObjC, and as a direct response too. They’re encouraging Android dev transition and they made it similar to Java for this reason.

        But I do think flutter is really interesting because of its simplicity and tooling.

      2. 6

        To me, non-native emulation of native UI widgets is a deal-breaker. Not only do these features need to look pixel-perfect, but they also need to animate and feel pixel-perfect as well. That’s a hard very hard challenge for a cross-platform UI toolkit that refuses to delegate to native libraries. Maybe for “enterprise” apps (internal to a company or forced upon hapless rank-and-dole employees) Flutter will work well, but I can’t see it being effective for premium, cross-platform consumer apps on iOS or macOS. Maybe Material/Flutter for Android, Web, and Windows, and then a separate codebase for Apple platforms?

        1. 6

          I’ve used it a bit and I love it. I’m looking forward to the web and desktop runtimes. The thing I like most, I think, is that things that seem like they should be simple are, in fact, simple. For instance, creating a virtualized list on Android is kind of a pain in Kotlin or Java, but it’s almost trivial in Flutter. That being said, I was already immersed in the Dart ecosystem, so YMMV.

          1. 4

            Well it’s google, so my only real thought is, how long until I see a “Flutter is dead/abandoned/out of favour” headline.

            1. 4

              I’ve written a couple apps now with it (including a demo that was part of the release of flutter_web at I/O a couple days ago), and I’ve been a huge fan since I first worked with the alpha ~1.5 years ago.

              Background: Been a mobile dev on both platforms since v1 on both platforms, I’m stronger on Android through.

              Upsides:

              1. The #1 upside for me is I’m just way way more productive than on either platform using their standard framework. Mobile development is fun again for me, and that hasn’t been true in a long time. I can just throw UI together and it usually works. Even if I was just writing an Android-only app, I’d prefer to write it in Flutter.
              2. Really great async support, and it’s properly built into the entire framework. Things like getting a photo from the library which can turn into callback hell on Android, end up being a few lines in a method.
              3. Lots of useful built in UI widgets. A lot of things I’d go custom for on other platforms are built in.
              4. Stable and well designed toolset. Honestly, this one is way undervalued. For example, check out the the command flutter doctor - https://flutter.dev/docs/get-started/install/macos#run-flutter-doctor - which diagnoses problems not only with your flutter install but with the native build systems for both iOS and Android. And it outputs command line suggestions to fix them. This kind of thoughtfulness is everywhere.
              5. It’s open source.
              6. The Flutter team itself. They’re experienced, older devs with huge amounts of experience. They’ve made tough tradeoffs and are standing by them. They’re also super nice and patient, just look at people taking swings at them on HN and how patiently they respond.

              False downsides:

              1. Dart. It’s fine, and also it just doesn’t matter much. The value of Swift or Kotlin on dev productivity has been hugely overestimated in my opinion. To put this to the test, ask a developer the how long it would take to develop an Android app in Java, then ask them how much time they can cut off using kotlin. It’s probably on the order of 5%. Give me that choice between Android and Flutter though and I’d probably be able to half the time estimates.

              Real downsides:

              1. Less libraries available, although you need fewer of them in my opinion.
              2. You are a bit at the mercy of the quality of the UI controls. The team has been very responsive in my experience though.

              Happy to answer any questions.

              1. 2

                Dart. It’s fine, and also it just doesn’t matter much. The value of Swift or Kotlin on dev productivity has been hugely overestimated in my opinion.

                While I tend to agree for the most part, non-nullability/optionality and value types are a current gap, and I find both help significantly when reasoning about the code. For the most part though, Dart was designed to be familiar and productive. I think it’s been successful in those regards, despite its perceived blandness.

                That said, it’s worth noting that the language team is dedicated to evolving the language. Over the years we’ve seen both large changes like the addition of a strong type system, as well as smaller improvements such as making the new keyword optional, driven in part by feedback from Flutter users.

                Real downsides

                I work on the Flutter team; here are two more:

                • Depending on intended use-case, the current lack of a great add-to-app story. We’ve done a decent job of creating a great dev experience for new apps written entirely in Flutter, but integrating a Flutter view or two to an existing app still involves some significant hand-wiring. The good news is this is a significant focus area for the team and I expect it to get better.
                • Integrating a lot of native widgets has a memory/performance cost. While most widgets can likely be written with relatively low effort in Flutter, it’s not always feasible. For widgets like WebViews that are impossible (disallowed on iOS) or complex to rewrite the overhead of the integration is relatively low compared to the overhead of the component itself, but if you need vast quantities of platform views, I’d recommend looking at other frameworks. We’re working on improvements here, but I expect there’ll always be some overhead.
              2. 4

                It’s ok. I wrote up some notes earlier this year on my experiences on writing a mobile app with it at https://tech.labs.oliverwyman.com/blog/2019/01/04/making-a-spaceteam-timer-app-with-flutter/

                1. 4

                  Compared to react native, I think that it has a few strengths that people underestimate - It’s (from a developer’s perspective) significantly simpler than many other UI stacks.

                  The layout model and widget model are quick to learn and wrap your head around - especially compared to web- everything is tidy and built from a small set small of primitives.

                  Dart isn’t a stellar language but you can learn it in one day like you can learn Go.

                  The #1 weakness is ecosystem. Flutter requires a good deal of elbow grease to re-build common patterns because the libraries aren’t fully there.

                  Source: I write flutter at work

                  1. 1

                    Are you able to share where you work? Or what kind of apps you write? I’ve been doing some Flutter professionally as well but haven’t seen it out in the wild much yet.

                  2. 3

                    my previously answered thoughts on Dart and my previously answered thoughts on Flutter.

                    Basically the language is not interesting but gives you shared code on client and server. I like the widget composition but the tooling to debug is not quite there, e.g. how do you look into failing HTTP requests? are there different tools for different environments? (still I haven’t looked into Flutter 1.0). It’s nice to have a reactive UI but Flutter is not the only framework that provides it (I guess?) so no bonus points.

                    1. 2

                      I’ve tried it a few times at milestone releases. I like the model and Dart seems cool but what’s always killed it for me is the fact that you have to write different code using different libraries if you want different OS looks, ie Cupertino for iOS and MD for Android. If you make your own UI without any standard widgets, fine; if you want basic OS-styled components, you either have one or the other or you write per-platform code. And unless I’ve misunderstood, if you use Cupertino, it’s not just hooking out into iOS/UIKit etc, it’s implementing a lookalike, which is subject to getting out of date. Maybe this is less the case since I last looked into it, in which case I’d be happy to do so again because it seems like Flutter has less of the churn and breaking changes you find in RN, but for me the point of a cross-platform toolkit is literally that you don’t have to write per-platform code.

                      1. 2

                        You’re not wrong here, that was a bummer in the past for sure. I believe they’re going to make platform dependent widget switches more automatic in the next release, but I can’t quite remember the details. I can find it if you’re interested.

                        1. 1

                          Sure, I’d be interested to read about that, if you have a minute. Thanks!

                          1. 2

                            It was mentioned in one of the talks and I/O and I can’t figure out which one now. From what I can tell it will be done via adaptive() constructors, for example: https://docs.flutter.io/flutter/material/Switch/Switch.adaptive.html

                            There are a few Flutter team members lurking around here though, maybe they can correct me if I’ve got this wrong.

                            1. 1

                              Thanks Matt!

                      2. 1

                        Flutter’s 1.0 release was in December 2018 and the first alpha release was 2 years ago. I will wait until at least version 3.0 or 4.0 to look into it.

                        1. 1

                          every now and then I’ll replicate a component or two from the Android apps I maintain and so far the flutter equivalents have dog slow refresh rates compared to the native implementations and fewer features. I think the idea is cool, but they have a long way to go.

                          1. 1

                            I guess you are talking about flutter.dev: google’s portable UI kit?

                            1. 0

                              I don’t know what it is.

                              1. 1

                                It’s something with a name that causes your favorite search engine to give you many unrelated results when you try to find out what it is.