Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

501–510 of 748 posts

Re: We're forking Flutter

#501

I'm confused .. is this a Google-led fork? Is "Flutter Foundation" a google sponsored foundation? If not, why use "Flutter" trademark? Also, if the fork is called "Flock", why is this called a "Flutter Foundation"?

Google is the „owner“ of flutter, why would they fork their own thing? The post is describing the problem the author has with google.

They kind of did it before with DartAngular. Maybe this is a Red Hat/CentOS division, where Flock is an upstream community edition and Flutter is ... I don't know.

I asked because it is confusing. My assumption would be that if this is an independent organization they couldn't use 'Flutter' because that is a registered trademark of Google, and they would say they are not connected to Google. I'm looking through their website and github repo for any statement that either asserts or denies a connection to Google - and I'm not seeing it.

Re: We're forking Flutter

#502
The thing I dislike about Dart and some other language like Swift or Ruby is that they only have one application.

With Dart you write Flutter aps. With Swift you write iOS apps. With Ruby you write Rails apps.

Java, C#, Rust, C, C++, Go, Python are usable for more than one thing.

I am not saying Dart and Flutter aren't nice, but for sure I would love to see Dart extending to more than just Flutter and making Dart usable for more would be an initiative I would applaud.

Re: We're forking Flutter

#503
Our industry has few innovative ideas in past decades ranging from small to large. Rust, React, Tailwind, Typescript, Nix come to mind. All these did things differently enough to seem weird at first.

Flutter is hands down the best DX product with a beautiful language. It is modern Qt and destined for great success given it doesn't get sent to Google's graveyard.

As for the fork, I don't see anyway it not significantly diverging from upstream because bug fixes might involve refactoring which would make difficult to pull in upstream changes.

Re: We're forking Flutter

#504
post #368

Earlier quoted context omitted.

“Flutter team members don't actually use Flutter.” (as per the website). This could explain a lot.

> This could explain a lot. Only if you're oblivious to the day-to-day activities of a software project. They work on building a framework, not on using said said framework to build something entirely different that has no bearing in how to build a framework.

It does, however, have bearing. Despite how common the practice may be in the corporate world, developing a framework without any regard to the user experience thereof is pretty suboptimal

Re: We're forking Flutter

#505

Earlier quoted context omitted.

I can no longer speak for the Google team (since I no longer lead it), but my understanding is that yes, Google is focusing their efforts on other platforms rather than Desktop (despite themselves using Flutter on Desktop for a variety of platforms). Canonical is contributing to the Desktop efforts substantially.

Canonical gave an update on Flutter desktop last weekend at their Ubuntu Summit: https://events.canonical.com/event/51/contributions/533/

It’s a bit unsettling to see Ubuntu demo stuff on Windows (I know that Flutter looks and behaves the same on Linux, but still).

Re: We're forking Flutter

#506

The thing I dislike about Dart and some other language like Swift or Ruby is that they only have one application. With Dart you write Flutter aps. With Swift you write iOS apps. With Ruby you write Rails apps. Java, C#, Rust, C, C++, Go, Python are usable for more than one thing. I am not saying Dart and Flutter aren't nice, but for sure I would love to see Dart extending to more than just Flutter and making Dart usa…

I'd like it the other way around and want to see Flutter APIs for other languages (lets say Kotlin). Personally I feel no desire to learn Dart to use it only for Flutter.

Re: We're forking Flutter

#507
post #348

> How large is the Flutter team, today? Google doesn't publish this information, but my guess is that the team is about 50 people strong. > That's 50 people serving the needs of 1,000,000. Doing a little bit of division, that means that every single member of the Flutter team is responsible for the needs of 20,000 Flutter developers! That ratio is clearly unworkable for any semblance of customer support. This is a we…

PHP Foundation has 10 developers and runs a substantial part of the web. 50 developers are definitely the wrong reason to fork flutter.

Flutter has much bigger scope than PHP Foundation. It's more fair to compare PHP Foundation scope to Dart Lang and Dart SDK. Flutter scope on top of that is Flutter Engine, Flutter Widgets, Flutter Framework, Flutter Packages, Dev Tools (IntelliJ + VSCode). PHP also support desktops/server environments instead of Flutter 6 platform (iOS, Android, Windows, Linux, MacOS, Web). Making crossplatform UI toolkit is the most labor intensive - PHP Foundation is not developing that. PHP had also 2 decades ahead of development.

Re: We're forking Flutter

#508

The thing I dislike about Dart and some other language like Swift or Ruby is that they only have one application. With Dart you write Flutter aps. With Swift you write iOS apps. With Ruby you write Rails apps. Java, C#, Rust, C, C++, Go, Python are usable for more than one thing. I am not saying Dart and Flutter aren't nice, but for sure I would love to see Dart extending to more than just Flutter and making Dart usa…

Ruby is exactly as versatile as all those other languages you list. It was made before Rails was, and it can do everything eg Python can. It's not very popular anymore outside Rails but eg lots of people did APIs in Ruby using stuff like Sinatra. I personally did lots of CLI utilities in Ruby. It's really nice for stuff like that.

Re: We're forking Flutter

#509

The thing I dislike about Dart and some other language like Swift or Ruby is that they only have one application. With Dart you write Flutter aps. With Swift you write iOS apps. With Ruby you write Rails apps. Java, C#, Rust, C, C++, Go, Python are usable for more than one thing. I am not saying Dart and Flutter aren't nice, but for sure I would love to see Dart extending to more than just Flutter and making Dart usa…

The Dart community tries to extend itself outside Flutter, there’s Serverpod for backend development for example.

It’s the Dart Team that is focused on Flutter.

Re: We're forking Flutter

#510
> sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.

This is what's wrong with companies trying to do OSS. They are literally unable to get over themselves and tap into the one quality that makes OSS so worthwhile: tapping into third parties volunteering their time, creativity, and ideas. The need to tightly control direction and strategy of a project leads to companies putting up walls that make it hard to tap into this.

IMHO, Google made several mistakes with Flutter that stem from their "not invented here syndrome". Effectively they've been competing with their own people on things like Kotlin, Kotlin multiplatform, and now Compose Multiplatform which is emerging as a direct competitor to flutter (does the same things on the same platforms). The obvious move years ago would have been to open up the flutter platform to other languages than Dart (especially Kotlin) and share code across both ecosystems and make the combined solution a better one.

That never happened. Dart is alright but in the end it's just another Java/Kotlin like language. IMHO Kotlin is nicer. But that's just me. Interoperability between Swift and Kotlin native now exists on IOS. Compose works on IOS. But Dart-Kotlin interoperability is not a thing.

This is not some kind of oversight. This is so obvious that it must have been proposed, multiple times, and blocked by Google management for internal political reasons. I have no other explanation. Any technical blocking issues would have been fixable/addressable. They chose not to. And now Flutter is de-prioritized internally and the team reduced in size because Google created another dead end. This is self inflicted failure. It took an outside team from Jetbrains to take Jetpack Compose and turn it into the multi-platform solution it is now becoming.

A foundation with a fork is the right move. Fix the above and great stuff might happen. Google doing things alone isn't working for them. Repeatedly. They need outside help. It's there for the taking. They should not fight this foundation but back it with money and transfer the entire flutter team to it.

Post reply on HN