Hacker News Reader

Comment by loic-sharma | Hacker News Reader

Hello, I'm from the Flutter desktop team. Thank you for the excellent feedback, this is truly invaluable.

Here are some updates from our side:

1. Custom context menus - We just added this feature in Flutter 3.7, which was released two weeks ago. Please give this a try and let us know what you think!

2. Multi-window - This is a high priority for the Flutter team, we have several engineers working on this project currently. Here's a video that gives an early preview on multi-window support: https://www.youtube.com/watch?v=vtB-teu57vw

Feel free to let us know if you have additional feedback; this helps us prioritize on what's most valuable for our community!

View on HN

First of all: Thank you for your outstanding work!

And sorry to ask this here, but how have the recent layoffs affected the flutter team?

We're using flutter as our main framework for our app and it's quite important.

The layoffs have sparked some fears that flutter development might slow down.

Google's Flutter team was affected by layoffs and we lost some wonderful folks. However, the number of Googlers working directly on Flutter has grown substantially in the last year.

Please keep in mind that Flutter is a community project. Google is one of Flutter's many sponsors, many of our contributors are from other companies.

> Flutter is a community project

A quick WHOIS search for flutter.dev and pub.dev domains tells me that this is not really the case.

Is there a CLA? Do I have to waive ownership of my contributions for my code to be merged? If yes then it's not a community project. Domain ownership has little to do with it. Look at who owns github.com :)

CLAs are always a good idea if one is maintaining an open source project. I'm not going to track down every single contributor who made some small PR perhaps, just to make a license change.

Why is your project changing the license, and why do you assume that contributors would still have done so under whatever license you're changing to?

The license could change for any number of reasons, making a paid version, making it GPL, etc. With a CLA, I don't have to assume, I'm able to change it regardless, that's why for maintainers they are useful.

Keeping the software free, i.e. not proprietary, even from maintainers trying to make it so, is the very point of GPL. When you ask contributors to sign a CLA, you are saying that you might want make it proprietary in the future and reserve the ability to do so. You should never sign one if you don't want to contribute to proprietary software.

As a contributor I wouldn't want the code I made to be under a different license in the future.

And I'm not going to contribute any change, no matter how small, to a project whose maintainer reserves the right to change the license in the future.

There is a CLA, so that folk can attest that contributions are theirs, and that they're free to be used by others, and that everyone who uses Flutter can feel comfortable that there are no patent or IP rights reserved by contributors.

It's open source software, developed in the open under a permissive license. You don't have to work for Google to have contributor access or the right to approve others contributions. Google kindly sponsors a fair amount of infrastructure (testing labs, etc.) and pays for a lot of people to work on Flutter. If that doesn't meet your definition of "community", then fair enough -- but the spirit that we work under is that the "Flutter team" is everyone who contributes code.

Hey, first let me be clear that I think it's great that Google is developing Flutter in the open, publishes it under a permissive license while also trying to get along with other contributors.

However, it's not a community project, by any definition of community, because there is a power imbalance between Google and other contributors. Accepting patches or even allowing non-Google people to accept patches from anyone is not enough.

> There is a CLA, so that folk can attest that contributions are theirs, and that they're free to be used by others, and that everyone who uses Flutter can feel comfortable that there are no patent or IP rights reserved by contributors.

No, there is a CLA so that Google keeps the ability to relicense future Flutter releases however it seems fit.

Of course everybody owns their own contributions, git log clearly shows who owns what. BSD license already assures that they are free to be used by others, and if patents were a concern, AFAIK the Apache license would've been a better option (IANAL). You don't need a CLA for any of that.

Users and contributors are bound by the BSD license. Google however gets special treatment:

""" Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. """

I hope the power imbalance is clear this time?

Again, it's great that Google develops open source software under a permissive license. Mad respect. I'd happily sign the CLA were I to send code to Flutter. I'm also not saying that Google shouldn't have a CLA, I fully understand, and maybe I'd do the same (maybe not). But let's call it what it is.

> but the spirit that we work under is that the "Flutter team" is everyone who contributes code.

Sorry but you sound like that boomer SMB owner who keeps saying "we are a family".

Thank you! That's reassuring and I strongly believe that Flutter is the best option for developing cross platform apps right now.

I very, very strongly disagree with this. On web, Flutter is flatly awful (and there’s no reason to expect it to get much better—it’s chosen a paradigm that makes it impossible to do a good job on the web). On desktop, well, this article describes various limitations and problems.

Flutter is unquestionably designed mobile-first, with everything else a distant second. Flutter may be the best option for developing cross-platform mobile apps right now (I don’t know), but if you care about web or desktop, it’s not a particularly good choice. Things based on web tech are very likely to be better.

Is Flutter open source?

Yeah it is under a BSD license:

https://github.com/flutter/flutter

It's open source the way Chrome is open source: the source is there, but the development is ~100% by Google

Not 100%, at least 30% of PRs are done by outside Google contributors.

How relevant are those PRs to the actual development of the product?

That is, fixing minor bugs or translation strings vs adding new web APIs etc.?

Google Chrome is not open source, Chromium is.

[Reference](https://en.wikipedia.org/wiki/Chromium_(web_browser)#:~:text....)

People keep pointing this out as if this made a grain of difference.

A community project? Flutter.dev literally says "Flutter is an open source framework by Google [...]" There is no list of sponsors on their webpage either, only a list of companies using Flutter. Google owns the logo and the trademark, controls the github repository, etc. Having contributors from other companies does not make the project into a community project.

You’re supposed to feel better, not ask questions. Besides they won’t say anything that affects their own job security (nor should they imo).

Thank you for the great work! Flutter and Dart are awesome and keep getting better. I'm coming from the land of Scala, Erlang, Clojure, TypeScript, and I'm loving the general approach to the engineering and design that Flutter and Dart teams have. Kudos!

Last time I used flutter for desktop, setting custom window size required an external package. I think it's a significant use case for many people.

Agreed! We will add support for window customization as part of the multi-window effort.

Do you have any pointers for someone who would love to contribute to Flutter and Dart as an open source contributor? Is there some guideline for what kind of contributions will be considered, areas where contributions are desired, etc?

Please check the contribution guide: https://github.com/flutter/flutter/blob/master/CONTRIBUTING....

We strive to be an open community. Anyone can become a Flutter team member if they contribute frequently :)

Thank you! I think that's a great attitude and a key to the long-term success.

We've got a guide here that covers some of these areas: https://github.com/flutter/flutter/blob/master/CONTRIBUTING....

For a lot of first-time contributors, improved documentation and added tests are a great way to dip toes into the water. We also have a 'good first contribution' tag on our issues log that might be a source of inspiration: https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Ai...

I'll mark the "better tell Tim" about the HN article off my list. :)

Awesome, thanks!

Hi there, I have been a happy flutter user for quite some time now, keep up them good work!

Same, contrary to some of the comments here I’ve had nothing but great experiences coming from a purely web background previously.

same here,keep up the great work.

by the way dart is my favorite cross platform language nowadays beyond flutter.

dart is my favorite cross platform language nowadays beyond flutter

Yeah, it's very underrated. I find it nearly as expressive as Python with far better maintainability and performance.

I work on Dart, and I'm glad you like it. I always like getting feedback from users. If there was something you could change about Dart, what would you pick? What would you keep just as it is?

i will start by saying i love dart. i learned it solely so i could make flutter apps. but now, three or four years later, i can say for certain that i love dart a lot more than i love flutter, which i have mixed feelings about.

i've learned at least a half a dozen languages over the years, and dart is now my favorite. so much so that i am converting existing projects to it. for example, i have a series of scripts i wrote, in python, to automate away the boring parts of my job, which i am now converting to dart. at this point, for me, trying to get anything done in python is like wading through molasses. (like, why does almost any change to a python implementation file cause you to also have to revisit the imports section? ugh, i hate that so much.)

my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance. programming is thinking, and i really don't like you dictating the way i ought to think. (yeah, i know you won't do it, but that's my big one.)

my second big change would be to allow me to implement a big dart class in two or more implementation files. the business logic in the flagship flutter app i maintain is getting unbelievably complicated, and large chunks of it cannot be moved out of the one object it is in, due to inheritance reasons.

> my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance.

Yeah, I get that. In personal projects, there's something to be said for just Having It Your Way. But the formatter is focused on ecosystem level improvements where configurability is an anti-feature.

> my second big change would be to allow me to implement a big dart class in two or more implementation files.

You can sometimes accomplish that by moving chunks of methods out into seperate mixins and mixing them into your class. I think mixins are generally underused in Dart. But if that doesn't work, the proposal for augmentation libraries would probably help:

https://github.com/dart-lang/language/blob/master/working/au...

I'm glad you're enjoying Dart!

the syntax is similar to C/java/C++ so the out-of-box experience was great, please keep it. I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.

I use dart for scripting as well, which works really well.

For deployment I wonder if Dart can be made a little like Go (or C/C++): to build into a single static executable instead of depending on system C shared libraries.

I gave up on Go and embraced Dart, so the `dart build` and `static binary` are kind of what I missed from Golang when started with Dart.

> I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.

It's "dart compile":

    $ dart compile --help
    Compile Dart to various formats.

    Usage: dart compile <subcommand> [arguments]
    -h, --help    Print this usage information.

    Available subcommands:
      aot-snapshot   Compile Dart to an AOT snapshot.
      exe            Compile Dart to a self-contained executable.
      jit-snapshot   Compile Dart to a JIT snapshot.
      js             Compile Dart to JavaScript.
      kernel         Compile Dart to a kernel snapshot.

not really, dart-compile does not do pub-get automatically, while dart-run does. dart-build is basically a (pub-get + dart-compile) to be "consistent" with other modern languages such as 'cargo build' or 'go build'

    dart_build () 
    { 
        [[ -f pubspec.yaml ]] || return;
        DART=$(grep ^name pubspec.yaml | awk '{print $2}');
        dart pub get;
        dart compile exe bin/"$DART".dart
    }

That's great to hear! When I get the chance, I'll update the article to note that custom context menus are actually supported now.

Is impeler going to affect (in good way) the performance/latency on desktop too? (I think it's mostly for iOS now, right)?

The plan AFAIK is to make it the default everywhere but they are just rolling out each platform in some kind of prioritised order.

Yup, but we're focused on mobile first as these are the most resource constrained platforms. We're also experimenting with 3D support in Flutter using Impeller. Check out these demos from Flutter Forward: https://youtu.be/zKQYGKAe5W8?t=6955

You can learn more about Impeller here: https://www.youtube.com/watch?v=gKrYWC_SDxQ

Something being highlighted about Flutter is that it ultimately compiles to native code so unlike RN which transpiles to native widgets, its UI animations should technically be buttery smooth.

But in watching the flutter announcement video https://youtu.be/Nu5m1FiS5X4?t=60 (timestamped link) on the screen as menus are opening and the mouse cursor is shown selecting different items, there is... a very perceptible stutter and lag. What is that due to?

There are a lot of levels of indirection here:

* A video on YouTube...

* Of a livestream...

* Of a video made by a separate video production team...

* Based a slideshow (probably Google Sheets)...

* Containing a pre-rendered video...

* Of a screen recording...

* Of a Flutter desktop app.

Any and all of those can introduce latency or lag in the video. It's a great form for showing users features, but probably not a great way to evaluate UI performance, unfortunately.

On the one hand, ok... sure... on the other:

this just makes me think of the fact that this sort of thing would absolutely never fly at Apple. And I really, really want to say that is shouldn't fly at Google either. They're spending what, 400k on the median developer annually? Have standards, make them have some sense of responsibility and respect for their craft so they don't do this. I mean, like come on, one of the main value propositions for someone considering Flutter as opposed to RN is the fact that it isn't transpiled, there is thus an expectation for widget performance to be basically be similar to that of native code -- well, this is exactly where you proudly and loudly showcase this -- in an announcement video. Widget performance should be absolutely flawless in the presentations.

But all that said, no I don't think that's what's going on here. The things shown right thereafter are stutter free. I think this is a quirk with Flutter. While for mobile/desktop it compiles to native code, for web it does transpile to JS and I think that's perhaps what is being shown there. Though I would think if they wrap it in some sort of wasm the lag wouldn't be perceptible.

It just really grates me that in this day and age this is the reality of UI. If you'd told me 10 years ago that a simple menu shown in a major UI toolkit announcement by the main web player would have these kinds of problems I'd have assumed you were just bad at telling jokes. It also makes me sad because I want Flutter to succeed but seeing these kinds of missteps gives me a pause.

edit: I see now that you're a googler, I'd have phrased it differently if I'd known. Cheers.

Hi! I was wondering about the coexistence of Flutter and Kotlin in Android development. Is there any good write-up to help devs to choose between them depending on the use case?

Not who you want an answer from but for me if I was writing an android only app I'd go for kotlin, if I wanted android, iOS, desktop, and web I'd go dart/flutter.

Reply on news.ycombinator.com