Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

Post reply on HN
Print view View original

271–280 of 748 posts

Re: We're forking Flutter

#271

Post by wiseowise »

sterlind wrote: post #168
kgeist wrote: post #139

Earlier quoted context omitted.

What about Python? They had 34 core developers in 2017 [0]. Python is used by millions of devs. They have to support a multitude of platforms as well. Same goes for a lot of programming languages like Go: a pretty small core, the rest is external contributions. And they have to support all sorts of platforms/configurations as well (probably more than Flutter does). [0] https://pythondev.readthedocs.io/core_devs.html

to be fair, Python's performance has lagged far behind comparable languages (e.g. JS) for at least a decade. maybe more devs could give it the V8 treatment?

V8 is a matter of investment of billions in expertise and time.

Re: We're forking Flutter

#272

Post by bmitc »

It really makes me wonder how and why Microsoft and Google can't create a cross-platform GUI ecosystem that lasts. Like, they both will have multiple operating systems and platforms such as web and mobile in use at their company and no doubt build a huge amount of bespoke tools. Wouldn't it behoove themselves to create a cross-platform GUI solution that actually works, is maintained, etc.?

I have been looking into building one myself, and for a company the size of Google or Microsoft, the task almost looks trivial. But somehow, they create these huge monstrosities like Flutter and .NET MAUI that crumble under their own weight.

This is especially true for Microsoft who sits upon two of the best languages around in C# and F#. Flutter often has a tough sell because it comes with Dart and vice versa. For Microsoft, is it really that hard to have a three-tiered approach to cross-platform development in that there is a separate, dedicated platform for each of web, mobile, and desktop that share common components (like drawing and animation APIs), architectures, paradigms, and of course languages?

GUI development on desktops is just a complete mess right now. Qt Quick with QML is okay, but it has a huge amount of strange limitations and has a surprising lack of just plug and plug UI components, like charts. Plus, you have to use either C++ or Python. Flutter seems better but also suffers from the lack of professional plug and plug widgets and requires the use of Dart, which is even less ideal. Plus, it requires the support (or lack thereof) from Google. For Microsoft, I could list at least half a dozen cross-platform approaches in a single blink of the eye.

Re: We're forking Flutter

#273

Post by dekhn »

ignoramous wrote: post #235
gman83 wrote: post #171

Earlier quoted context omitted.

No Eric founded Flutter at Google. However, Google had previously acquired another company called Flutter, and they had that domain lying around, and decided to use it. That's what I understood, at least.

Gotcha. To use "Founder" then seems like a weird choice? I guess, I must catch up to the changing meanings of words used in SV.

The canonical way to say this inside Google would be closer to "I created the Flutter project and launched it externally" instead of "founded"

Re: We're forking Flutter

#274

Post by xster »

skybrian wrote: post #82

Back when I worked on GWT, we had trouble accepting outside contributions because the team had a mandate to support Googlers. That is, much like other libraries and tools at Google, changes could not break google3. This means testing patches against google3 and either changing the patch, or fixing whatever code used it, and these are tasks that no outsider can do. Shepherding these patches is no fun when you have you…

The main Flutter GitHub repo does have infrastructure to run PR against all Google internal tests (which as you say, does find real bugs). https://imgur.com/a/Ih2oQIS

disclaimer: my team runs said infrastructure

Re: We're forking Flutter

#275

Post by ur-whale »

deergomoo wrote: post #215
divan wrote: post #120

> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…

> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell You can't be serious. Maybe on Android, but on other platforms—especially iOS—they stick out like a sore thumb. A number of them just look like Material Design Android apps awkwardly transplanted over, but I know that's down to the developer so I won't hold that against Flutter. But scrolling through th…

> but they don't fit in.

You seem to say this like it's a bad thing?

Re: We're forking Flutter

#276

Post by [deleted] »

dotancohen wrote: post #211
epcoa wrote: post #204

Earlier quoted context omitted.

What's a native UI? The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)? And then Android? Ironic then that Google is the one behind Flutter. The concept of native outside of MacO…

I would consider both GTK and Qt native on Linux.

[deleted]

Re: We're forking Flutter

#277

Post by wiseowise »

ignoramous wrote: post #150
refulgentis wrote: post #143

Earlier quoted context omitted.

If you think its not popular until that increases past one of: JS, Python, Java, C#, PHP, C/C++, Ruby, Go, or SQL...I don't really know what to say. :)

Flutter in Kotlin instead of Dart would have killed ! Alas. Hopefully, Kotlin Multi-Platform holds up as good as Flutter has (the rendering architecture based on Skia seems similar between the two frameworks).

> Flutter in Kotlin instead of Dart would have killed!

Killed the framework for good, true. No pattern matching, joke destructuring, static delegation, reliance on Gradle (puke).

I don’t understand how Dart still has bad reputation when it leapfrogged this joke of a language long time ago.

Re: We're forking Flutter

#278

Post by brewii »

deergomoo wrote: post #251
divan wrote: post #233

Earlier quoted context omitted.

Sure, but not every cross-platform app developer wants their app to look "native to iOS". Especially if you want your app to look the same on all platforms and/or have some creative design.

I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun. I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did. Of course, I recognise that, a. most peopl…

Pretty sure most large succesful apps have their own UI and UI design teams. Cant remember the last time i saw anything cupertino in an app. Even Apples own 'Home' app only loosely use cupertino. Id say the most noticable effect is the bottom modal sheet slide up effect. on ios the original screen animates into the background a little bit. Apps that dont implement this can be spotted but thats not unique to flutter at all and flutter even offers a pretty good cupertino scaffold package that does this animation.

Re: We're forking Flutter

#279

Post by hersheyhersh »

Flutter founder here. We use Flutter to build Mezzi (www.mezzi.com). In fact, we've worked with the OP (Matt) on our app. He's super knowledgeable about Flutter and it's inner workings. A great dev too.

Flutter is awesome, but there are definitely bugs that lie unfixed for an uncomfortable period of time. This is not unique to Flutter ... with any open source project there's a lag between bug reports and bug fixes.

The thing I worry about is that its going to be really hard to get a large number of PR reviewers up to speed for this fork, while also maintaining reasonable quality.

I think it's going to be difficult to maintain a separate fork without diverging from Flutter, because over time, the fork will accumulate bug fixes and features that the Google version will not accept (by definition, since the proposal is to be more accepting of PRs). How are we supposed to go back to the Google version of Flutter as the fork diverges more and more from the original?

Or is the proposal that we should stick with the fork, and the fork will over time pull in the new features and PRs from the Google version? But how will that work after say 12 to 24 months of divergence? There's going to be a hodgepodge of new features and bug fixes on the fork, and then Google will release a new version of Flutter with a whole set of new capabilities ... and we'll be stuck having to choose. Or we'll have to do a really hairy merge between the Fork and the new version from Google.

This just seems scary to me. Especially since for any given team, there's usually one ... or maybe two things we want to patch into the Flutter tree. Its easier for us to just apply those fixes onto a new version of Google's flutter tree than it would be to patch a whole community's worth of bug fixes and features onto the new Google tree.

I think the preferable course of action is that the community should work with Google to see if there's a way to improve the speed of PR reviews.

I'm worried about the chaos that forking could cause in this community that doesn't really have a huge number of contributors yet.

Re: We're forking Flutter

#280

Post by nox101 »

divan wrote: post #120

> We describe Flock as "Flutter+". In other words, we do not want, or intend, to fork the Flutter community. Flock will remain constantly up to date with Flutter. That was the first fear when I saw the title - splitting community and having two incompatible versions. Good to see it addressed in the post. The second was just a fear of how it would complicate the development process, but it seems to be a drop-in replac…

flutter's custom canvas render on web means so much of the web stops working or is slow. type anything non ASCII like an emoji or CKJ and eat while it downloads a font. No other pages do this. Text fields are missing all the standard context menu options like define, translate, etc... Things that would be selectable on any other page are not, etc....
Post reply on HN