Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

571–580 of 748 posts

Re: We're forking Flutter

#571

Earlier quoted context omitted.

As someone desperately fighting to keep their company's main product to stay using a native desktop UI, Microsoft makes it real hard. WinUI3 hasn't even officially launched and it already feels like it's on life support. QT is good, but even qt seems to be starting to use a web renderer.

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

It's really something I know nothing about so I googled WinUI3 and the 3 first results are microsoft website and github, and the next two are "is winui3 dead ?" and "Oh winui3 is really" dead. So it doesn't inspire confidence :)

Re: We're forking Flutter

#572
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.

Which programming languages have a good developer experience with flutter beside dart ?

Re: We're forking Flutter

#573
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 att…

> can squash by putting more resources into Flutter

So success?

Re: We're forking Flutter

#574
post #24

Earlier quoted context omitted.

Flutter founder here. When I led the Google team we had pretty good analytics. `flutter` was for a long time opt-out with analytics and would phone home to Google and report usage. We filtered out docker containers and things that looked like CI and saw usage near 1M monthly actives when I left Google a couple years ago. I'm sure it's up since then. There are 10s of millions of web developers in the world. Doesn't sh…

Wait, did you just publicly admit to Google collecting terminal device information without user consent?

Its not the coolest thing but idk if it’s unexpected or scandalous

Re: We're forking Flutter

#575

Earlier quoted context omitted.

Which flutter apps do I likely use?

The only one I often use is Immich. It's laggy and at times freezes completely for a second. I don't think that's the developers fault though, I don't have that issue with any other android app.

I recently started Immich and also say the awful lag. But apparently this is due to a slow "album sync" running often on the main thread. Not the fault of flutter.

I don't know how syncing my 200 albums can be that slow but they are a big project to move it off of the main thread.

Re: We're forking Flutter

#576
post #547

Earlier quoted context omitted.

My comment was related to mobile apps. Web apps built on Flutter definitely can be distinguished. The thing is, with web apps, people have developed feelings for the "nativeness" - because browsers make a lot of UI choices for them. A typical example is a selection of the text. Because web apps are built using XML-based typesetting language from 80-s, everything is selectable by default. No matter how many layers of…

> But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider. You say "insanely stupid", I say wonderful. Everything you apparently hate about the web is what makes it good for users. Content is primary, and my user agent can resize it, restyle it, copy it, extract it, link it, read it to a blind person... If you want to make a binary blob app, jus…

> You say "insanely stupid", I say wonderful.

Yes, that's the most common response. I've heard stories about "how wonderful when you can select everything" multiple times, and that's, of course, just shows how human rationalization works.

And yet, this "feature" or "UI choice" is not even a choice. It's just a byproduct of using the wrong stack for the task. Like, nobody ever sat and asked, "Do we want our apps to have everything as a selectable feature?" before shipping this "feature". It just happened, and then, of course, millions of humans, having no actual choice over it, naturally rationalized that as a "wonderful" feature.

Re: We're forking Flutter

#577

Earlier quoted context omitted.

A lot of people try an app and stop using it. Talking to active users seems you are missing the people who don't like it enough to stop using it.

I've built apps with pretty high retention rate so even if they're annoyed, it doesn't seem like they really stop using them. Mostly though, based on user feedback we collected, not once have I heard anything about UI complaints. It really feels like this is a common refrain on HN about what HNers think happens in theory versus what actually happens in reality wrt user preferences.

Note, this has nothing to do with your app or this specific discussed GUI, but this is something I have noticed over time...

I think that what is commonly seen by devs as complaining and being overly concerned with details that don't matter is instead a some of the time advocacy for doing things the right way for the sake of it. It is totally possible to build things that meet the bare minimum requirements for user retention and for people to not complain, but that doesn't mean that it is optimal. You can build Soviet style housing blocks that people live in that are completely functional and that no one will have any problem with, but the quality of life is degraded as opposed to what could have been built.

It can be tough seeing through the grumpy nerd 'I want it my way because my way is best' and finding what is actually 'this is a good thing that we should be doing, and if we did there would be a marked improvement for everyone', but I would not forsake one due to the other.

Re: We're forking Flutter

#578
post #382

Earlier quoted context omitted.

I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms. 99% of people I know IRL are in one ecosystem, with the exception of some that have an iPhone/iPad + Windows PC

In a previous company when we were looking at precisely this problem, building out multiple platform support, we did UX studies where this question in particular came up. The vast majority of people said they wanted apps to act consistently across devices. Most people on the planet use Windows with Android, statistically speaking, which are not similar devices at all, at least on Apple platforms you can use Swift for…

> The vast majority of people said they wanted apps to act consistently across devices

You shouldn’t trust what users say they want. It many times doesn’t correlate with what they want. Certainly, I would try and figure out what they mean with “act consistently”. My suspicion (for which I have zero evidence) is that they’re more talking about high-level similarity than about nitty-gritty details such as how many milliseconds to hold your finger down to select and edit text, how scrolling works, etc.

Also, I suspect they want devices to act constantly across apps, too: copy-paste should work, text editing should behave identically, sharing controls should be the same, etc.

In the current world (and, I think, in any world where there is competition in any form between platforms), they cannot get both, so then, it boils down to what is more important.

For me, that’s platform consistency. For example, I find it easier to get used to text editing being different on a phone and on a laptop than to get used to a zillion minor inconveniences/annoyances in typing and editing behavior between apps.

I also find it less of a problem if text and emoji look slightly different on a different device than when they look slightly different between apps.

Re: We're forking Flutter

#579
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

I know I use exactly one and it sucks. It’s all janky and weird compared to the rest of the system.

Re: We're forking Flutter

#580
post #477

Earlier quoted context omitted.

> but I know that's down to the developer so I won't hold that against Flutter. That is absolutely an issue with Flutter, which throws away the underlying platform UX and draws to a canvas. It gives you relatively few tools to target "native look" controls for each platform without maintaining multiple UIs in parallel composed of entirely different widgets.

> the underlying platform UX and draws to a canvas Frame buffer? Canvas is the javascript term.

Flutter uses canvas when targeting the web. (At least it was the last time I looked at it years ago)
Post reply on HN