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

331–340 of 748 posts

Re: We're forking Flutter

#331

Post by cageface »

mdaniel wrote: post #315

While surfing around the various repos, I was reminded about the bad taste I got from the last time someone sung the praises of Flutter/Dart; this thing is firmly in the "Android SDK-ish" school of thought: download a shitload of prebuilt binaries from storage.googleapis.com, dontyouworryaboutit $ curl -I https://storage.googleapis.com/flutter_infra_release/releases/stable/macos/flutter_macos_3.24.4-stable.zip

Of all the different dev stacks I've used Flutter has given me the fewest issues across updates. I've never run `flutter upgrade` and then had serious trouble getting an existing project to run.

Compared to js, react & react native, python, ruby etc I've just never hit the same bitrot so they're doing something right.

Re: We're forking Flutter

#332

Post by crossroadsguy »

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…

Haha. Oh, most people know! They might not be knowing it’s Flutter to be specific but they sure know it’s some hybrid/non-native crap.

I recently started using Ente migrating from Authy and goodness it feels and looks awful. I wish 2FAS had a desktop app. There was a native alternative that allows exporting codes. (This is not against Ente devs. I am sure they are a small team bringing out a FOSS product. This is just my preference)

Re: We're forking Flutter

#333

Post by int_19h »

knifie_spoonie wrote: post #327
deergomoo wrote: post #251

Earlier quoted context omitted.

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…

> Of course, I recognise that, a. most people just don’t care about platform idioms This is the big one. HN commenters are not representative of the average user. You'd have to specifically point out the differences for them to even notice, and even then they simply don't care.

Casual users don't care about the app "looking wrong". They do care about the app not working like other apps on their phone, though.

Re: We're forking Flutter

#334

Post by iml7 »

I couldn't agree more, """In other words, I believe there are blind spots because Flutter team members don't actually use Flutter.""" Electron creators made atom, the best text editor, and then vscode, And flutter doesn't have a signature app to show that it can be used for serious purposes. Currently, the most famous open source app in the community is appflow.io, I compare the current state of appflow.io to the current state of flutter, even the unfixable bugs. I compare vscode to the JavaScript ecosystem, with both advantages and disadvantages,

Re: We're forking Flutter

#335

Post by heavyset_go »

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 is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.

I was a Flutter early adopter going on for like 7 years ago now, and Flutter has its place, but I don't know if I could repeat your sentiment with a straight face. Especially when comparing it to Qt.

Re: We're forking Flutter

#336

Post by deskr »

stux wrote: post #264

https://github.com/flutter/flutter/pulls?q=is%3Apr+author%3A... - 0 open PRs - 2 PRs merged, 1 PR closed in the past 4 years - All PRs reviewed by a member of the Flutter team within 24hrs - [“If I'm still supposed to write tests, even for this change, then this is probably as far as I take the PR.”]( https://github.com/flutter/flutter/pull/128910#issuecomment-... ) - 40+ PRs from 2019 So, disgruntled ex-employee?

I can understand the test frustration on both sides.

* He's being asked to fix tests that were already failing. That can be an enormous task depending on the nature of the failure and the code base.

* The team doesn't want to merge his PR since they don't have a test. The code is presumably working without his PR and understandably they won't change a single byte without seeing tests work.

Re: We're forking Flutter

#337

Post by lopatin »

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…

> we do not want, or intend, to fork the Flutter community.

I can't reconcile that statement with the rest of the blog post. Good intentions aside, this is exactly what they are on the path to doing.

From the post:

> By forking Flutter, we get to decide what gets merged.

I'll allow myself to be naively blunt since I just learned of this and I don't have a stake in this battle, but it seems like a nice little coup attempt that Google can squash by putting more resources into Flutter if they feel the pressure.

Re: We're forking Flutter

#338

Post by jonahx »

KTibow wrote: post #71

> Communication monoculture This point seems like a callout to a certain discussion and I kind of want to see it

This kind of PC-jargon also makes me want to place a bet that the alleged "monoculture" is some perfectly reasonable insistence on either clarity or basic politeness. Willing to be proved wrong though!

Re: We're forking Flutter

#339

Post by int_19h »

jeremyjh wrote: post #307
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…

Win32 is the native GUI toolkit on Windows. Winforms is a .NET wrapper to it. There isn't any debate to be had there. Yes, the same vendor provides other toolkits. Linux is a kernel project, and different distributions are for many purposes best considered to be different OS's. Desktops based on Linux mostly are either GTK or QT, and so the native toolkit depends on the desktop you are using. Is this too much fragmen…

Win32 is no longer the native GUI toolkit on Windows, given how much of the OS GUI itself is not using it (new Settings etc). If the argument is that it ships in the box, well, so does UWP XAML.

Re: We're forking Flutter

#340

Post by int_19h »

c-hendricks wrote: post #330
contextfree wrote: post #222

Earlier quoted context omitted.

"WinUI3 hasn't even officially launched" ? It officially launched with version 1.0 and it's now on 1.6?

I can't really speak to the differences but > At this time, there are two generations of WinUI: WinUI 2 for UWP and WinUI in the Windows App SDK (WinUI 3). > https://learn.microsoft.com/en-us/windows/apps/winui/

Hence why OP was specifically talking about WinUI 3 (which is indeed at version 1.6.1 as of right now).
Post reply on HN