541–550 of 748 posts
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?
Earlier quoted context omitted.
Only on HN do I hear anyone talking about platform native controls versus unified UI across devices. I have not once heard of such a complaint in the real world and indeed, I have more often heard users wanting a unified UI over one that changes with each platform, simply because these days we have multiple devices where we expect apps to work the same.
You have to listen to the details, like "where is the back button", "Why does text work differently". There are some people that understand that it is different from the standard, but most just get annoyed. The discussion here is from a technical perspective why it is better, conformity of the app on different platforms vs standard behavior between different apps. There are very few people that care about the technic…
[flagged]
> 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…
Key statement: "As Flock ships important bug fixes and features, the Flutter team can then choose to add those to Flutter, on their schedule. " I see a lot of negative comments but I think this will be a net positive over time to the Flutter community and to the technology itself. I think it will also give Google a reality check on the needs of the community.
Flutter Founder here. I'm very pro open-source, and pro taking-action, so hopefully good things will come out of it. I think this particular author is mostly stirring up a bunch of noise and does not represent a significant chunk of the community, but we'll see. :shrug:
Is it time for HN to finally support Slack-style emojis?
Earlier quoted context omitted.
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.
Casual users do care about app behaving wrong, though. If you can't copy or paste things, or if the navigation is backwards, or if the calendar looks weird etc etc - it all causes some minor frustrations, when things don't behave as user wants them to behave. They don't know what "native" means, obviously - they don't have that knowledge. They just know crappy apps from well-behaving apps, because they have a frame o…
> 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…
What are some examples of good 'impossible to tell' UIs built with flutter on desktop or web?
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 abstraction you put on top of that hackish foundation, you are still running it in the program (browser) designed to show text. So you can select buttons, navigation controls, images, sound players, etc. And it feels very native to web users.
But when you actually think about it, it's an insanely stupid UI choice that neither of proper UI frameworks would even consider. Sure, you can "opt-out" with recent CSS controls for selection, but it's again, a hack - the default choice of "everything is selectable" is made by default for you by the browser. What does it even mean - select button widget? Why would you enable this complicated selection functionality for your UI that allows users to select navigation buttons with a blue selection box? Of course, if your app needs this functionality - you can add it. But otherwise, it would be labeled as a very stupid UI choice. Yet, feels native to web.
Another example is zooming. Because UI apps written in web stack can't completely hide the fact that what they are doing is essentially trying to morph text primitives into complicated UI widgets (makes sense for 2024, right?), and the browser is essentially a text viewer, everything is zoomable and feels "native" to be able to zoom a web app. And yet, this rarely works as intended. In any other UI framework, making zoom functionality requires thinking about what and how you want to zoom and why. OS text size preferences are well handled by flutter, but sometimes you do want to add your own zoom functionality. In web though you just blindly zoom everything, often blowing off the layouts and that feels very "native" to web.
My point is, that I don't think UI frameworks should try to match the nativeness of web, especially when they start targeting the wasm platform. These couple of decades of proliferation of web frameworks built on top of HTML/JS/CSS should just wane in history as a dark period of software engineering.
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…
> 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. There are DOZENS of us!!! I try my absolute best to find apps that use the native Apple language, both design and code. I can't stand these framework apps. I will Pepsi challenge this with anyone who asks…
Earlier quoted context omitted.
I'm going to be honest. C# , NodeJS, Python and rarely Java( had a rough year), pay my bills. Flutter/Dart doesn't. If you know someone hiring a Flutter developer I'm 100% down to interview. I don't hate Kotlin, it feels like Google's answer to Swift( although Java was never as hard as Objective C). I even built a small project with it. Can we at least agree it's weird Google is trying to promote 2 different language…
> Can we at least agree it's weird Google is trying to promote 2 different languages for multiplatform development? Google doesn’t promote anything. There are two competing teams with their own agendas. Flutter’s bills are mostly paid by internal usage, as far as I know. Android is mainly focused on Android part of Compose. Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter…
I'm not exactly senior to senior, but I hopped from mid level hobbyist Unity dev to professional Unity dev , to mid level .net dev. I have a very specific niche though.
I'm very comfortable with my career.
>Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
Android Studio is free ? Are they really making that much money off users using Kotlin outside of Android Studio ?
Earlier quoted context omitted.
What kind of users/apps are these? I'm genuinely curious about this, actually. I have a couple of apps with 100K+ installs, and I talk to people who are actual users from time to time. I have never ever heard the claim that they don't like UI because it doesn't feel native. Like ever. But I can imagine that in some niches/demographics/app types it might be different. Can you share some evidence or explain how you bui…
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.