[HN Gopher] We're forking Flutter
___________________________________________________________________
We're forking Flutter
Author : alexzeitler
Score : 802 points
Date : 2024-10-28 19:24 UTC (1 days ago)
(HTM) web link (flutterfoundation.dev)
(TXT) w3m dump (flutterfoundation.dev)
| arccy wrote:
| To still use flutter in the name when your project is called
| flock seems beyond misleading.
| throwaway19972 wrote:
| Better than using a distinct name for a mostly-identical
| project or effort (looking at you, MariaDB).
| concerndc1tizen wrote:
| "MariaDB is named after Widenius' younger daughter, Maria.
| (MySQL is named after his other daughter, My.)" (Wikipedia)
| philshem wrote:
| https://en.wikipedia.org/wiki/Michael_Widenius
| throwaway19972 wrote:
| (No insult intended to Maria or Michael, it's a lovely name
| in itself.)
| SahAssar wrote:
| Are you suggesting that they should have used a name that
| might lead Oracle to sue them instead of being clearly
| differentiated?
| topspin wrote:
| Also, there is an existing messaging and collaboration tool
| called Flock: https://www.flock.com/
| mhd wrote:
| My onions, let me show you them:
| https://en.wikipedia.org/wiki/Flock_(web_browser)
| ClassyJacket wrote:
| And a fantastic way to get sued out of existence by a rich
| corporation.
| quesera wrote:
| FWIW, the only realistic legal action right now is a cease
| and desist letter.
|
| Which will be responded to swiftly with no lawsuits or
| damages exchanged.
| normie3000 wrote:
| > What do you do if the team won't work on that bug for 2 years?
| Well, if it's a serious bug for your company, then you stop using
| Flutter. You don't have a choice. You need to keep moving
| forward. Your team doesn't know how to work on the Flutter
| framework, and the Flutter framework team is either unresponsive,
| or at least completely non-committal towards a fix.
|
| Are there no escape hatches?
| michaelmior wrote:
| > Your team doesn't know how to work on the Flutter framework
|
| The only escape hatch I can think of is to either have the team
| learn how to work on Flutter itself or hire someone who can.
| mckn1ght wrote:
| Xplat FWs are just technical debt to prove a concept. Once
| you find critical mass the first order of business should be
| converting to native so you can remove that entire layer of
| additional complexity. Similar to paying down student debt to
| minimize how much interest you wind up paying on them after
| getting a good job.
|
| IMO this should be the natural order if you size use it at
| all, not the emergency case.
| mvac wrote:
| Very sad article to read. I just expect the original Flutter will
| now die a slow death. I applaud the effort and hope they will be
| able to find a monetization model that works to support the
| development. There have been similar projects based on
| technologies that Microsoft has killed (Silverlight -> OpenSilver
| and various .NET-based cross-platform technologies) that serve
| their customers well. Unfortunately, none of them are in any way
| "mainstream" like Flutter is today.
| normie3000 wrote:
| > There have been similar projects based on technologies that
| Microsoft has killed
|
| Isn't flutter from google?
| michaelmior wrote:
| Yes. But the other technologies mentioned were from
| Microsoft.
| mvac wrote:
| Yes, it is. I was just thinking about what happened when
| other companies did something similar.
| spwa4 wrote:
| Didn't Google suddenly kill GWT, which is a bit like
| flutter?
| DannyBee wrote:
| No, it transitioned it to others after signaling it would
| for well over a year, so i don't think you could call it
| sudden:
|
| "In 2011 with the introduction of the Dart programming
| language, Google stated that GWT would continue to be
| supported for the foreseeable future while also hinting
| at a possible rapprochement between the two Google
| approaches to structured web programming. However, they
| also mentioned that several of the engineers previously
| working on GWT are now working on Dart.[6]
|
| In 2012 at their annual I/O conference, Google announced
| that GWT would be transformed from a Google project to a
| fully open-sourced project.[7]
|
| In July 2013, Google posted on its GWT blog that the
| transformation to an open-source project was
| completed.[8]"
|
| Google funded/helped for some number of years after that.
|
| It still is going, afaik, with gwt 2.11 being released in
| january, 2024.
|
| https://www.gwtproject.org/
| baueric wrote:
| That might be the wrong way to interpret this. It actually
| validates interest in the framework. This change personally
| excited me and injects some change into the ecosystem that
| could result in a better future.
| kernal wrote:
| >Very sad article to read. I just expect the original Flutter
| will now die a slow death.
|
| I find it odd that you would think this fork would even have an
| impact on Flutter or its roadmap.
| riku_iki wrote:
| > What do you do if the team won't work on that bug for 2 years?
| Well, if it's a serious bug for your company, then you stop using
| Flutter. You don't have a choice. You need to keep moving
| forward. Your team doesn't know how to work on the Flutter
| framework, and the Flutter framework team is either unresponsive,
| or at least completely non-committal towards a fix.
|
| they could pay contributor or issue bug bounty..
| hobs wrote:
| Based on the article's premise getting that merged is the
| problem, not fixing code.
| riku_iki wrote:
| right, making maintainers happy is part of that work.
| throwaway032023 wrote:
| Yeah this isn't drive-by contributions where you shit out a
| PR that works for you but makes the test infra fail and you
| get upset. Ppl need to think big picture.
|
| One big problem, I think, it may not be visible all of the
| test infrastructure if your outside google. Don't know.
| Gerritt is its own world and googlers live there not in GH
| (it appears).
| rubiquity wrote:
| They estimate there are one million Flutter developers/users.
| Have I been sleeping under a rock?
| normie3000 wrote:
| I was wondering the same. How many Android developers are
| there?!
| yieldcrv wrote:
| they're just too close to the problem and overestimating their
| relevance.
|
| just because someone cloned a repo once or an NPM package was
| downloaded doesn't mean someone is a flutter dev. I don't know
| what the best metric would be, but its relevance is definitely
| overstated
| fhd2 wrote:
| Yeah, people like to count their "downloads" and call that
| their "users", but it's at least an order of magnitude
| difference in my experience. Sometimes a 100x difference.
| muglug wrote:
| Assuming there are 20 million software engineers in the world
| writing code professionally, 1 million Flutter developers seems
| massively optimistic.
| lysace wrote:
| Yes. Realistically off by _at least_ a magnitude. There is
| literally zero chance there 's 1 million active developers
| working on this experimental Google Tech out there.
| Barrin92 wrote:
| >working on this experimental Google Tech
|
| while I'd agree with you that 1 million is too high,
| Flutter certainly is not experimental Google tech. It's
| widely used in particular internationally. I talked to a
| ByteDance guy two or three years ago and I think they alone
| had about 1k Flutter engineers. Nubank, Alibaba, BMW, Ebay
| use it extensively.
|
| Flawed metric but eyeballing VScode Extension installs,
| Python 140m, c# 30 mil, Go 15 mil, Flutter 10 mil. It is
| very, very popular.
| lysace wrote:
| 100k seems more reasonable.
| kllrnohj wrote:
| Flutter has more usage among professional devs than React
| Native does per stackoverflow survey
| https://survey.stackoverflow.co/2023/#section-most-
| popular-t... and statista has similar-enough numbers:
| https://www.statista.com/statistics/869224/worldwide-
| softwar...
|
| Seeing as React Native has somewhere around 1 million
| active developers, Flutter almost certainly does as well.
| adamc wrote:
| Just looked via google, and while no one really _knows_ ,
| common estimates of the number of web developers seem higher
| than that, on the order of 27 million.
|
| Your point may still be valid, but... is 3-5% really that
| high?
|
| (No dog in this, I'm not doing web development at the moment,
| although I have and probably will again.)
| e63f67dd-065b wrote:
| There's 200k weekly downloads of node on npm. A million flutter
| devs means that there's a comparable amount of node devs to
| flutter. I'm not sure how else to estimate it, but there's 170k
| github stars of flutter compared to 100k node, and a roughly
| equal amount of forks.
|
| The 2024 SO dev survey
| https://survey.stackoverflow.co/2024/technology/ has flutter at
| 10% and nodejs at 40%. Github language stats has JS about
| 10-15x the popularity of dart, but seeing as JS is more than
| just node it might pan out.
| https://madnight.github.io/githut/#/pull_requests/2024/1
|
| So I guess looking at the stats 1M flutter devs is not an
| implausible number on its face.
| notpushkin wrote:
| > There's 200k weekly downloads of node on npm.
|
| I'm pretty sure Node developers _usually_ don't install Node
| from npm.
| monocasa wrote:
| Does nvm not use npm internally?
| pzo wrote:
| Github shows 98% of code is "Shell" on top of that there
| are also many different package managers that people use:
| fnm, volta that are build with rust. You can also install
| nodejs using homebrew.
| ramesh31 wrote:
| >Does nvm not use npm internally?
|
| No. It downloads binaries from nodejs.org. There is no
| "official" canonical means of managing Node versions.
| It's just a grab bag of community tools like NVM.
| nicce wrote:
| I would dare to say that average person who works with
| Node does not use nvm.
| chamomeal wrote:
| Really? I think it's even recommended on the node
| website's install page
| yen223 wrote:
| Yeah. For comparison, there are 27 million weekly downloads
| for React.
|
| I'm not sure what conclusions we can draw from either
| number.
| spankalee wrote:
| I use Node every day and I've never even heard of the 'node'
| package before. I think it's very niche.
| eseidel wrote:
| 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 shock me that Flutter could be over 1M monthly (and
| probably several million annually).
|
| There are just a lot of apps and app devs out there.
| punduk wrote:
| Are there any statistics on how much of it is used in
| production?
| pzo wrote:
| If there would be 1M flutter devs per year and on average
| team had 10 devs (rather rare most mobile teams would be
| smaller except really big apps) and development of app
| would take ~1 year you would expect minimum 100k new
| flutter apps in app store every year. That seems highly
| unlikely.
| punduk wrote:
| I agree. Flutter is a project I like, but the numbers
| given regarding statistics remind me of this video
| https://www.youtube.com/watch?v=A-RfHC91Ewc
| plorkyeran wrote:
| I suspect there's a lot of larger apps out there which
| use Flutter for one feature or set of screens but the
| majority of the app isn't written in Flutter. You could
| have a team of 100 working on a app where only three of
| them actually touch flutter on a regular basis, but
| depending on how exactly you capture analytics all 100 of
| them may get counted.
| manmal wrote:
| I've worked for over a year, almost full time, on an
| internal Flutter app that never saw the light of day
| (maybe later, if the stars align). Many apps just get
| their support section revamped with Flutter because
| there's no need for that to look fancy; but they'll still
| count against that quota. Many devs prototype their side
| projects with Flutter, but never release them. Etc
| distances wrote:
| I'm pretty sure many/most professional app developers are
| in long-term projects, working on the same app(s) year
| after year. So for those devs the app count never goes
| up. That's at least my experience -- development work
| only stops when the app is pulled off the stores for
| business reasons.
| eseidel wrote:
| https://flutter.dev/showcase has a few examples. Flutter is
| everywhere at this point. TikTok in China (Douyin), PUBG
| Mobile, MGM Resorts, eBay Motors, Kijiji.com, Grab are a
| few off the top of my head. And of course a whole bunch of
| Google apps (GPay, Earth, Classroom, etc.), Toyota cars, LG
| TVs, Google's own hardware devices, etc. Tonal is probably
| the app I used most often that's Flutter. Caribou Coffee,
| Betterment, Norwegian Cruise Lines, NuBank, Realtor.com are
| other random apps I've used that are Flutter.
| xster wrote:
| small nit: many daily driver apps in China are partially
| Flutter. But TikTok is not at the present
| refulgentis wrote:
| small nit: douyin is. is it possible you read "TikTok in
| China (Douyin)" as "TikTok in America"?
| Vt71fcAqt7 wrote:
| Do you have a source for that claim? I'm pretty sure that
| is incorrect. Bytedance has said they use Flutter but for
| other projects.[0] Douyin is not mentioned anywhere.
|
| [0] https://flutter.dev/showcase/bytedance
| refulgentis wrote:
| Yes, via the Flutter founder here:
| https://news.ycombinator.com/item?id=41975474
| eseidel wrote:
| I don't have access to any devices with Douyin on it, so
| I cannot confirm current usage.
|
| My knowledge of their usage is from discussions with
| ByteDance some many years ago when I was in charge of the
| Flutter project at Google. At the time they were using
| Flutter in 50+ applications (probably most of them
| internal), including Douyin (TikTok for China) as well as
| physical hardware kiosks on their campus, web apps, etc.
|
| https://flutter.dev/showcase/bytedance
| Vt71fcAqt7 wrote:
| I just tested Douyin 23.5 from 2022[0] and it does not
| have the two finger scroll bug.[1] It is of course
| possible they were carrying their own patch for it all
| this time but that seems unlikely. I doubt they are using
| Flutter or if they did it must have been a long time ago.
|
| [0]
| https://douyin.en.uptodown.com/android/download/87248716
|
| [1] https://github.com/flutter/flutter/issues/11884 -
| click on the search button in Douyin on the main page and
| search for something to get to a regular ScrollView. You
| don't need an account for this.
| refulgentis wrote:
| Flutter two finger scroll "bug" is gone.
|
| I wouldn't say its unlikely they carried a patch for it,
| I just wrote a framework patch that I apply at build time
| in CI and locally.
|
| I refuse to sideload arbitrary APKs, especially from
| bytedance. I feel bad because that is irrational, you
| did, and it'd be really helpful if I did and just did
| this myself, but, you should install FlutterShark and
| check: https://play.google.com/store/apps/details?id=com.
| fluttersha...
| Vt71fcAqt7 wrote:
| >Flutter two finger scroll "bug" is gone.
|
| Why is "bug" in scare quotes here? It was most definitely
| a bug.
|
| >I wouldn't say its unlikely they carried a patch for it,
| I just wrote a framework patch that I apply at build time
| in CI and locally.
|
| The actual fix was pretty involved. I doubt a large
| company like Bytedance would want to carry around extra
| patches at the gesture level that make the dev cycle more
| difficult. Having one person carry a patch on their local
| machine is a different story.
|
| Anyway, the Bytedance blogpost says only 200 devs are
| using Flutter which would make no sense if it was used in
| Douyin, and LibChecker[0] returns no results for
| libflutter.so.
|
| [0] https://github.com/LibChecker/LibChecker
| refulgentis wrote:
| > Why is "bug" in scare quotes here? It was most
| definitely a bug.
|
| Is it? I thought it was cool, I can't think of why its
| disruptive to scroll a list faster if you scroll with
| more fingers.
|
| > I doubt a large company like Bytedance would want to
| carry around extra patches at the gesture level
|
| I'm a solo endeavour, and I spent ~30 minutes to do
| exactly this (patch gesture behavior) two days ago. I was
| stunned how easy it is. But I grew up on versioned closed
| source dependencies on Apple iOS frameworks that you had
| to patch the runtime at runtime to fix, so I'm easily
| wowed.
|
| > 200 devs are using Flutter which would make no sense if
| it was used in Douyin
|
| Seems reductive: "Only" 200 fulltime, 800 in the
| company...and we're in a discussion about how 50 maintain
| _the entire framework_. :)
| flawn wrote:
| If you have an Android phone, get FlutterShark and check
| which of your installed apps use Flutter. It's a surprising
| amount actually. For example, I just recently discovered
| that Supercell uses Flutter for their Supercell-ID flow.
| kgeist wrote:
| FlutterShurk says 3 apps on my phone use Flutter. Device
| Info (a different app) reports that's 0.2% of all my
| apps...
| IshKebab wrote:
| I only got one (ASDA), I'm pretty sure it's just a
| webview though so I'm not sure why they are using
| Flutter.
|
| Hard to say it is "everywhere". It's probably more
| popular than any of the other cross platform alternatives
| though.
| ascorbic wrote:
| There are 25 on mine, so ymmv
| sundarurfriend wrote:
| It was 8 out of 86 apps for me (9% of my apps). Including
| Hacki, the HN client. It's a good variety of apps too,
| from big billion dollar companies to tiny games I
| downloaded from F-Droid.
| distances wrote:
| Interesting to check, thanks for the tip. I have 6
| Flutter apps, half of which I had assumed to be in React
| Native.
| kernal wrote:
| I had about 30 apps. That surprised me.
| no_carrier wrote:
| I have a pretty limited understanding of mobile
| sandboxing, but how does FlutterShark have access to
| analyse all the apps on my phone?
| drilbo wrote:
| >android.permission.INTERNET
|
| > _android.permission.QUERY_ALL_PACKAGES_
|
| >com.google.android.gms.permission.AD_ID
|
| >android.permission.ACCESS_NETWORK_STATE
|
| >android.permission.WAKE_LOCK
|
| >android.permission.FOREGROUND_SERVICE
|
| seems like imo the type of thing you should be prompted
| for but what do I know
| IshKebab wrote:
| Since the beginning of Android apps could see what other
| apps were installed on your phone without asking for
| special permission.
|
| They _finally_ added a permission for it -
| QUERY_ALL_PACKAGES - in Android 11 (2020). Unfortunately
| it 's one of those stupid permissions like filesystem
| access where you have to apply for it via a form, and
| only whitelisted use cases are allowed:
|
| > Permitted uses involve apps that must discover any and
| all installed apps on the device, for awareness or
| interoperability purposes may have eligibility for the
| permission. Permitted uses include device search,
| antivirus apps, file managers and browsers.
|
| I suppose that situation is slightly better than "anyone
| can do it for any reason".
| blinding-streak wrote:
| Other anecdotal apps: Google Analytics mobile app.
| BetRivers online sportsbook (one of the largest in the US).
| gfarah wrote:
| I can share an example from our company's experience:
|
| - 5 years using Flutter - 31 full-time devs - 3 platforms
| (iOS, Android, and Web) - 1.3 million monthly active users
|
| Overall, we're very happy with our decision to use Flutter
| 999900000999 wrote:
| Thank you for creating my favorite app framework.
|
| That said, I literally only use Flutter as a hobbyist.
|
| I made a basic web game for a friend, and a small web app
| that helps me manage my music lyric videos. I ultimately
| picked Flutter because I find it easier than actually
| building websites.
|
| Dart is amazing.
|
| But I'm not deploying to millions of users. At most 10 people
| have seen my Flutter apps.
|
| It's VERY good for creating quick crud apps with Firebase.
|
| Just counting the number of us who have it installed and
| might of spun up hello world says nothing about it's actual
| market share.
|
| To be clear, I absolutely love Flutter, but it's still not
| something I really see job listings for.
|
| Dart is great too BTW.
| refulgentis wrote:
| on behalf of one of the Flutter founders, thank you for the
| thank yous.
|
| I bet they'd mean a bit more if it wasn't coupled to a
| lengthy thinking-out-loud post that casts doubt on it,
| based on how many job listings you see, for something you
| don't look for job listings for.
|
| Quick Google shows _Dart_ 10th, right below SQL, right
| above Kotlin.
| https://www.devjobsscanner.com/blog/top-8-most-demanded-
| prog...
| davedx wrote:
| 0.58% of jobs?
| refulgentis wrote:
| 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. :)
| ignoramous wrote:
| 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).
| refulgentis wrote:
| Yes, I agree, trying to use Kotlin instead of Dart would
| have killed Flutter.
|
| I've been hearing about Kotlin multiplatform just as long
| as flutter, and writing Kotlin since 2019.
|
| Kotlin is a horrible daily driver.
|
| I worked on Android for Google at 7 years, and maybe it'd
| have a better chance if it _didn 't_ win internally. As
| it stands, there's too many organizational boundaries
| created, and each organization holds itself accountable
| only within itself, so it's sort of the worst of all
| worlds, impedance mismatches everywhere, and nobodys
| fault they exist
|
| I'm always stunned to read wish casting about Kotlin
| because there's ~0 path to even basic things that change
| productivity dramatically, like hot reload.
| 999900000999 wrote:
| 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 languages for multiplatform
| development?
|
| Let me compare Unity to Flutter for a bit. When Unity
| jobs are hard to come by, I'm still an OK C# dev.
|
| Flutter/Dart doesn't offer they same freedom. Say what
| you want about Microsoft, but C# can essentially do
| anything. Including keeping me employed.
| refulgentis wrote:
| Only for the crowd, I need point out that no one's
| arguing there's more Dart jobs than C#.
|
| Re: multiple frameworks, I worked at Google and would
| argue I know as much as anyone does exactly what happened
| there, so I can't agree it's weird, per se. Handwaving,
| I'd say that's because the situation seems more 'certain'
| or 'settled' to me, for good reasons, but ones not worth
| getting into.
|
| There's absolutely tons of threads to unpack in your
| comment, I wish we were in person.
|
| Speaking generally, based on observation you gravitated
| most towards discussing qualities of a job one might or
| might not get:
|
| I essentially left my job at Google for no paycheck,
| partially because Google x Koyaanisqatsi, partially
| because I just couldn't imagine having to go back to
| write Kotlin and/or Java day to day and being criticized
| either way. That being said, it's deflating seeing
| Flutter job listings after getting into this whole
| industry from iOS dev. Thing with Flutter jobs is there's
| tons of low priced job seeking competition that are smart
| as hell.
|
| That's because it is unusually effective in environments
| where people can't afford a Macbook only for iOS dev, and
| at this point in its lifecycle, it self selects for
| people who get experience with new frameworks
| 999900000999 wrote:
| Do you personally dislike Java/Kotlin ?
|
| Java just feels like a less refined C# to me, but I'd be
| fine with it if offered a FAANG job.
|
| I've tried to learn C++ too since I think I'd open up
| some job opportunities, but it's just too hard for me.
|
| So who won, Kotlin or Flutter ?
|
| From your last paragraph, I take your prefer to work as a
| Flutter dev all else(pay) being equal?
| rvnx wrote:
| They want both implementations to compete, and then they
| deprecate one of them.
| refulgentis wrote:
| Thats an excellent summary, and its fair for you to
| assume that question has been settled.
| rvnx wrote:
| (On a serious note), inside Google you tend to get more
| easily promoted if you launch new products than if you
| maintain existing products, so it could be tempting for
| the employees themselves to follow in that direction.
| mdaniel wrote:
| > I don't hate Kotlin, it feels like Google's answer to
| Swift
|
| You have the wrong order: _JetBrains_ created Kotlin[1],
| and anything Google had to do with it was just adopting
| _their_ language. Same story for Gradle choosing it over
| Groovy
|
| 1: https://github.com/JetBrains/kotlin
| wiseowise wrote:
| > 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's lunch and
| promote Kotlin usage to drive their IDE sales.
|
| > Let me compare Unity to Flutter for a bit. When Unity
| jobs are hard to come by, I'm still an OK C# dev.
| Flutter/Dart doesn't offer they same freedom. Say what
| you want about Microsoft, but C# can essentially do
| anything. Including keeping me employed.
|
| I might be wrong, as I've worked with .Net
| professionally, but I doubt you can jump from Senior
| Unity C# developer to Senior Asp.Net developer. Language
| is a small part in modern development.
| 999900000999 wrote:
| >I might be wrong, as I've worked with .Net
| professionally, but I doubt you can jump from Senior
| Unity C# developer to Senior Asp.Net developer. Language
| is a small part in modern development.
|
| 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 ?
| wiseowise wrote:
| Android Studio is subsidized by Google and works pretty
| much only Android. The moment you have to work something
| more, e.g. some Web stuff you need to pay for IntelliJ
| Ultimate as it's only IDE that supports Kotlin.
|
| They even have Ktor (Kotlin web framework) plugin
| available only in Ultimate. For any non-trivial Kotlin
| development you need to have Ultimate.
| mdaniel wrote:
| > you need to pay for IntelliJ Ultimate as it's only IDE
| that supports Kotlin.
|
| That is so stunningly false that I am pretty sure I'm
| feeding the trolls:
| https://github.com/JetBrains/intellij-
| community/blob/idea/24... (Apache 2)
| wiseowise wrote:
| Right. Good luck developing Kotlin multiplatform, Ktor,
| Spring, anything web related or native with Intellij
| community.
| pandeiro wrote:
| There's no hot reload in Android (kotlin) dev? Wow
| refulgentis wrote:
| yeah, it fascinates me - both Apple and Google started
| these new UI framework things after Flutter, and both
| didn't land it, but instead, landed some half-baked thing
| where individual components can render live _in the IDE_.
|
| That may sound more useful than it is: think "oh I can
| specify a dummy title and subtitle for a list view cell
| in code, then open a special pane in the ide to preview a
| source file, and then resize the window to imitate
| different screen sizes!", not, oh there's a bug, fix,
| save, insta-reload, verified fix. No holistic screens, or
| loading info from a database, or mutating data.
|
| I assume this is an extremely hard problem. I remember
| trying to get Obj-C hot reload working 15 years ago and
| it kinda half-worked some of the time. And its not like I
| can edit the C++ my Flutter app is linking against and
| get instareload.
|
| But still, it's one of the things thats easy to point out
| and drives home that these once-a-decade-or-two
| frameworks started in response to React Native/Flutter
| aren't addressing the fundamentals of what made them a
| sea change. Industry is risk averse and we make too many
| decisions similar to staying on track to launch MacOS
| 9.110 in 2024, instead of biting the bullet to get OS X
| done.
| wiseowise wrote:
| > 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.
| Capricorn2481 wrote:
| Just seems like personal preferences. I've used languages
| with extensive pattern matching and don't feel like I'm
| missing out without them. Don't really see the problem
| with Gradle or Static Delegation either.
| wiseowise wrote:
| Then you won't understand what made Flutter "click". I
| work with Kotlin, Gradle and Compose on a day to day job
| and it is absolutely dreadful experience. Sure, it beats
| working with Java... Java 8.
| EdwardDiego wrote:
| Thanks for explaining your stance not a whit.
|
| I was genuinely interested in your thoughts, "you
| wouldn't understand it, but trust me" is deeply
| unhelpful.
| wiseowise wrote:
| It's more of a "too hard to translate all the
| frustrations that you encounter in day to day" rather
| than "trust me, bro".
|
| Glad you found it useful.
| alias_neo wrote:
| > I bet they'd mean a bit more if it wasn't coupled to a
| lengthy thinking-out-loud post that casts doubt on it,
| based on how many job listings you see, for something you
| don't look for job listings for.
|
| Did you really just thank the guy for saying thanks, but
| give him a big fuck you in the same breath for not being
| a 100% kool-aid drinker?
|
| Speechless.
| openplatypus wrote:
| Wait, did you just publicly admit to Google collecting
| terminal device information without user consent?
| professor_x wrote:
| Its not the coolest thing but idk if it's unexpected or
| scandalous
| markus_zhang wrote:
| It's possible that they also count students and amateurs such
| as me, who only used it in a small project never published.
| There _could_ be a million I guess, but professional developers
| are probably a lot less.
| vivekd wrote:
| I think this is a strong possibility. For example, I don't
| work in programing and don't intend to ever work in the
| field. I do it as a hobby. I downloaded flutter, played
| around with it for a few weekends and decided it wasn't for
| me. If you go solely by number of downloads I would be
| counted as a 'flutter developer'
| breck wrote:
| Wow, I had seen signs that Flutter was something special for
| years, but hadn't checked in a while.
|
| Some relevant data:
|
| - Over 165K GH stars
|
| - Over 140K subredditers
|
| - Over 500K YouTube subscribers
|
| The 1M estimate is at least ballpark accurate.
|
| https://pldb.io/concepts/flutter.html
| fastball wrote:
| Does subscribing to a coffee-tuber automatically make you a
| barista?
| DaiPlusPlus wrote:
| James Hoffman, I presume?
|
| I don't sub him on YouTube - but I'm not lying when I say
| everyone I know IRL who does sub his channel has worked as
| a barista at some point in their lives (...and purchase
| actual chemical-lab supplies for their coffee brews).
| zippergz wrote:
| My experience when I last looked into Flutter was that it was
| heavily used in India - at least based on who participates in
| the community online - and much less elsewhere. That's not a
| value judgement, just might be a factor in why you don't hear
| much about it if you're not in India.
| justmarc wrote:
| Flutter is truly a piece of great tech with remarkable quality
| and value. I hope the right path will be found.
|
| I think companies using it for commercial purposes (like what
| we're doing) should contribute something to the effort to help
| make sure Flutter not only survives, but flourishes.
|
| Bug bounties, supporting individual developers, supporting
| efforts and initiatives, professional services, or any other way
| that helps the project move forward will be great.
| normie3000 wrote:
| > Flutter is truly a piece of great tech with remarkable
| quality and value.
|
| How does it compare to React Native from user and developer
| experience perspectives? Are there other competitors?
| justmarc wrote:
| Faster and better in almost every respect we've looked at vs
| React Native or Electron. We're super happy with this choice
| we made quite some time ago.
|
| I'm not qualified to give an in depth review/comparison,
| however.
|
| Edit: we use flutter to build an app which runs on iOS,
| Android, macOS, Windows and Linux -- the same code base with
| pretty minor adaptations to desktop vs mobile and different
| screen sizes.
|
| The experience has so far been fantastic. It's fast, it's
| relatively light weight, it's performant, it's a pleasure and
| we couldn't imagine doing it any other way.
| acmecorps wrote:
| We have worked with flutter since 2019; having built
| internal apps for our staff, public apps for our customers,
| small utility apps etc- this has been our experience as
| well. Not only flutter has been rock solid, easy and fast
| to develop, it has a wide array of libraries. Long may it
| continue.
| ko27 wrote:
| It's better in most ways, for example, just recently LG
| decided to rewrite its TV apps from RN to Flutter
|
| https://webostv.developer.lge.com/news/2024-07-15-new-and-
| su...
|
| > Most of our apps use React. When we first adopted React, we
| were pleased with the development productivity it provided,
| but sadly its initial performance was subpar in terms of
| start-up time, memory consumption, and responsiveness. After
| significant and complicated optimizations we reached
| performance benchmarks that were good enough, and yet we
| desired a new technology that was both fast and simple.
|
| > To our delight, our very first prototype with Flutter
| easily exceeded our target benchmarks! Without any
| optimization whatsoever, our Flutter rewrite launched twice
| as fast as our original app, consumed less runtime memory,
| and felt more responsive and playful to use
| JavierFlores09 wrote:
| I wonder how it compares now with the latest version of RN
| that brings out a lot of performance gains induced by the
| removal of their native bridge, and also faster startup by
| making lazy loading of modules the default option
| tomduncalf wrote:
| Sounds like it might be talking about web React, not RN,
| also
| veeti wrote:
| Not familiar with webOS, but are they talking about React
| Native specifically or just "web" stack React?
| hadad wrote:
| Misleading on the comment, LG WebOS is using EnactJS
| (Framework on top of ReactJS) + Chromium Embedded Browser,
| not native, just webapp on browser.
|
| But React Native is different , JS code compiled to native
| code using c/c++ compiler on target system. Flutter also do
| like this one.
|
| Embedded browser is slower than native app, because extra
| browser layer than native one.
| munificent wrote:
| _> But React Native is different , JS code compiled to
| native code using c /c++ compiler on target system.
| Flutter also do like this one._
|
| Sure, but you're compiling two radically different
| languages. JavaScript is dynamically typed (even with
| TypeScript) and Dart has a sound static type system.
|
| It's much easier to compile Dart to efficient native code
| than it is JavaScript.
| conradfr wrote:
| Ionic&Capacitor with Angular/React/Vue
|
| NativeScript
| atentaten wrote:
| I've been working with Flutter for a little over 2 years
| nonstop. Before I started this project, knowing enough react,
| I experimented with react native, Expo, also quasar,
| capacitor, nativescript, and other cross-platform mobile
| solutions. Flutter/Dart was just nicer to deal with than
| everything else. I needed to work with C code too, and
| Flutter made it straightforward with FFI.
|
| The developer experience was great and the Flutter team was
| very responsive with questions I asked.
| hadad wrote:
| For xplat is same concept, compile to native code on multiple
| target system.
|
| The other xplat framework same as Flutter:
|
| - React Native
|
| - Kotlin Multiplatform
|
| - NET MAUI
|
| - NativeScript
|
| - Slint
| politelemon wrote:
| Who is 'we'? I'm not familiar enough with this ecosystem to
| understand. Is this one person or a set of existing contributors,
| or something else?
| mihular wrote:
| Exactly my thoughts. How anybody would take it seriously if the
| people behind are not known, is beyond me. Anyway I left
| flutter a long time ago exactly because the mentioned problems
| - ridiculously slow response time fixing bugs, like auto fill
| want working.
| theLiminator wrote:
| Honestly makes sense to me. If Google has proven one thing is
| that it generally maintains a very tight grip on anything open-
| source that they ship. Ie. it's extremely hard to contribute
| upstream. This is fine when it's a package that's critical to
| good, so they invest a lot into it (for example, Jax). But for
| stuff that's not quite there, it means fixes will meander for
| months if not years.
| Topfi wrote:
| As someone reliant on Flutter, it is likely better to rip off the
| band-aid now than wait for a slow, prolonged decline. That being
| said, whilst I am at least somewhat comforted that the person
| taking charge is someone who was involved with the Flutter team
| at Google in the past, rather than a random, overenthusiastic
| person, I have a few crucial criticisms on this post that make me
| skeptical.
|
| For one, I'd recommend adding a newsletter field to the
| website/blog, simply so those who may not want to test or
| participate right away can stay in the loop. More importantly
| though, the two links asking for reviewers and leads just link to
| a private Eggs account, which, even before someone decided it was
| a good idea to just make content appear in an unsorted manner
| (random post from 2023, then 2021, then 2024, then 2020, ...),
| has never been an ideal approach for such projects in my opinion.
| I honestly thought I had clicked on the wrong links when two eggs
| profiles appeared in new tabs.
|
| Forcing potential devs to create a third-party account on a
| social media site, then send in DMs is likely not the best way to
| get such a major project of the ground and having public repos or
| at least a contact form set up would go a long way, especially
| since that also makes it easier to enforce some ruleset for
| applications.
|
| Additionally, consider listing what changes have been implemented
| in Flock at this stage. As it stands, it appears impossible to
| easily tell what one can expect without diving into the changes
| [0] one-by-one.
|
| Still, wishing you the best as Flutters development and approach
| to both what goes into which branch, as well as keeping up-to-
| date with UI elements in target OSs has been leaving a lot to be
| desired to say the least. I still feel that, despite all
| shortcomings, for certain applications and workflows,
| Flutter/Dart remains the best, and it would be a shame to see it
| unmaintained.
|
| [0]
| https://github.com/flutter/flutter/compare/master...Flutter-...
| eseidel wrote:
| Flutter Founder here. If you ever have any concerns re:
| Flutter, please don't ever hesitate to reach out.
| eric@shorebird.dev
| ignoramous wrote:
| > _Flutter Founder here._
|
| Flutter was a company acquired ala Firebase? Always thought
| it was a project (like Golang) incubated by/for/at Google.
| gman83 wrote:
| 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.
| ignoramous wrote:
| 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.
| bobthepanda wrote:
| founder is a word that exists outside the context of SV
| and has never exclusively been the domain of startups.
| ignoramous wrote:
| Guess you're right. Establishing a "Flutter org" counts.
| Though, I've never seen folks in this space (Bjarne
| Stroustrup or Anders Heljsberg for example) say they're
| the "Founder" of XYZ language / framework.
|
| https://dictionary.cambridge.org/dictionary/english/found
| er (n) someone who establishes an
| organization
| dekhn wrote:
| The canonical way to say this inside Google would be
| closer to "I created the Flutter project and launched it
| externally" instead of "founded"
| eseidel wrote:
| Correct.
| auggierose wrote:
| Are you by any chance also a famous poker player? ;-)
| evomassiny wrote:
| I've nothing to add to the conversation, but I jump on this
| oportinity to tell you that i like the content you've made
| with Adam Barth on yt very much, have a great day :)
| plorkyeran wrote:
| > 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.
|
| If "only" 50 people working on a project used by one million
| people was unworkably low then every single successful project
| out there would be doomed. I've certainly worked on things with
| much worse ratios than that.
|
| > one has to critically assess why a team that loves external
| contributions has only managed to merge contributions from 1,500
| developers over a span of nearly a decade.
|
| External contributions from 1500 developers over a decade is a
| lot. That is an unusually _high_ number, not a low one, and backs
| up Flutter 's claim to love external contributions.
|
| The fact that this person thinks that they can just magically
| conjure up _dozens_ of volunteer PR reviewers is wild. Everything
| about this post makes it pretty clear that they don 't have the
| slightest clue of the scope of what they're trying to do. This
| feels like one of the standard examples of an ex-bigco person
| setting off on their own with no understanding how just how much
| the bigco did in the background to facilitate their job.
| bsimpson wrote:
| It struck me that they estimate that the number of qualified
| contributors is 1000, but the number _so far_ is 1500.
|
| They're slightly different things (as the post notes, the
| bigger number includes copy editors), but still...
| kgeist wrote:
| Our user base is of a similar order of magnitude, with around
| 70 developers. It doesn't seem like a large number, indeed! A
| small minority frequently contacts support, suggests features,
| etc., while the majority simply uses the product.
| johnnyanmac wrote:
| these are also 50 google devs (that may or may not be at the
| company anymore) by this estimate. They could have just said
| there were critical tickets not addressed by Gooogle and their
| PR's ignored, and would have gotten a much more sympathetic
| response.
| adamc wrote:
| Even though they didn't say, that was my assumption. Why
| would they bother, otherwise? And that's not wrong.
| giancarlostoro wrote:
| WhatsApp had less than 50 engineers (or was it employees
| total?) when Facebook bought them out, and they had millions of
| users.
| droideqa wrote:
| The power of Erlang.
| zerr wrote:
| Modified Erlang. Genuine one didn't scale.
| mg74 wrote:
| How so? Is there anything on what changes they made to
| Erlang/BEAM?
| bhaney wrote:
| Process groups, some solid performance tweaks to ETS and
| Mnesia, etc. It all got upstreamed or became redundant
| eventually. Rick Reed gave a couple talks about it around
| a decade ago if you can track down recordings.
| mg74 wrote:
| Thank you
| toast0 wrote:
| The whole point of running an opensource
| OS/vm/runtime/etc is that you can tweak things here and
| there when you need them.
|
| Yeah, we had to make changes, some changes to FreeBSD
| too, but mostly little changes here and there. Erlang and
| FreeBSD were both lovely to work on.
|
| Re the sibling's question about what was changed, I don't
| remember everything, Rick Reed's presentations at Erlang
| Factory / Elixir describe most of them though (although
| those ended in 2014, I think). Many or most of the
| changes got into upstream one way or another. But most of
| it were things because AFAIK, we had much larger Erlang
| clusters than the rest of the community; I remember
| seeing advice about large clusters of 50 when we were
| running 300 nodes in a cluster, and I'm pretty sure we
| had dist clusters above 1000 later when we also had
| separate cross cluster messaging. We also had huge mnesia
| tables, other people said don't use mnesia over 2GB, and
| we had nodes with more than 512GB of data in mnesia. I
| don't really remember much that we had to do with dist,
| although pg2 needed help and our replacement became pg in
| OTP, mnesia did need some help to scale. We changed the
| ETS hash kernel to avoid everything hashing the same way,
| I don't know if that made it out.
|
| We also needed to do things like timer wheel
| improvements, but OTP also did timer wheel improvements
| and we dropped ours. Not so many people were running
| quite so many timers.
|
| Then there were things that I don't think are
| upstreamable. Adding a way to drop a process's message
| queue. Adding a way to add a message to the front of a
| process's message queue. Those two are very not in line
| with OTP, but handy for operations if you use them
| carefully.
| 1024core wrote:
| BSD too.
| criddell wrote:
| Since Instagram had only 13 employees when Facebook bought
| them for $1 billion, does that mean:
| power(Python) > power(Erlang)?
| izacus wrote:
| What a bizarre comparison, WhatsApp engineers didn't have to
| review code for millions of users.
| giancarlostoro wrote:
| How is it bizarre to compare the impact of a low number of
| engineers affecting millions of people. In the case of
| WhatsApp it was 35 engineers affecting 350 million people.
|
| https://news.ycombinator.com/item?id=39447564
| xmprt wrote:
| The support needs of developers is generally higher than
| those of a messaging user. How often have you had to
| contact the support of a messaging app you use? Now think
| about how often you create a Github issue or PR for an
| open source repo.
| chrisandchris wrote:
| What a bizarre statement. cURL is basically maintained by a
| single person, and nearly the whole world uses it.
| ignoramous wrote:
| > _cURL is basically maintained by a single person_
|
| Suppose Flutter may be an order or two magnitude more
| complex than cURL.
| brnt wrote:
| glib then?
| chrisandchris wrote:
| Absolutely, yes! Then make it two or three people, maybe
| 10 and there are still n-times too many people working on
| flutter compared to cURL.
|
| Which boils down to: Number of devs vs. people using
| something is a very bad metric. Even number of supported
| devices won't work good in this case (I assume cURL runs
| basically everywhere).
|
| I think it's very difficult to estimate complexity, and
| then make a statement about "how many people are enough"
| is even more difficult. Some environments are harder and
| more complex, some are just very heterogen and some are
| both. Sometimes it's the organizational overhead, maybe
| even something else.
| mplewis wrote:
| Two orders of magnitude would be 100, not 10.
| lesuorac wrote:
| I'm not sure that something being 100x more complex means
| you need 100x more people.
|
| plus they said an "order or two" which would be 10-100x
| so ...
| steve_adams_86 wrote:
| WhatsApp has a very narrow use case and feature set to
| support. Flutter is a multi-platform framework for developing
| apps like WhatsApp. It seems like a apples and oranges here.
| giancarlostoro wrote:
| I'm comparing the impact. Small tens of developers,
| affecting millions of people.
| siamese_puff wrote:
| Sure and 1 guy built flappy birds played by tens of
| millions. The complexity is a completely different ball
| game IMO.
| giancarlostoro wrote:
| Flappy Bird was taken off the store by its author, if you
| take WhatsApp off the app store, that would be a
| completely different reaction to Flappy Bird.
| Apocryphon wrote:
| Millions of people can be affected in different ways.
| kgeist wrote:
| 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
| sterlind wrote:
| 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?
| devjab wrote:
| I'm not sure what you mean by this but Python can be very
| performant when you want it to be. That is to say, when
| you build computation heavy parts in C (or Zig), and
| remember to avoid the various performance pitfalls like
| not using generators when you didn't want to load all
| those millions of elements into your memory.
|
| What sets professional Python aside from most other
| programming languages is that everyone who uses it knows
| that it's terrible and how to deal with that. Which will
| sometimes be replacing parts (or all) or it.
|
| To say that it's inherently less performant than JS is
| frankly silly though.
| jonas21 wrote:
| So, basically: Python is performant when you don't use
| Python?
| criddell wrote:
| Keep in mind _performant_ just means that it works in an
| effective or expected way. It doesn't necessarily say
| much about perform _ance_.
| kccqzy wrote:
| Yes. Python is performant when all the performance-
| sensitive code is written as extension code.
| devjab wrote:
| Yes. Is that so weird? JS is also performant when you
| don't use JS considering you're running it on C or Rust
| and are likely using the FFI if you're doing any form of
| computation heavy work.
| sterlind wrote:
| Here's one source on Python very obviously not matching
| Node.js's perf on a simple microbenchmark:
| https://jott.live/markdown/nodejs_vs_python_
|
| CPython really is inherently less performant than V8.
| CPython, until very recently, didn't have a JIT at all.
| It compiles scripts to bytecode, then runs the bytecode
| in a giant case statement. It doesn't have a tracing
| profiler-guided optimizer or an exotic garbage collector.
| CPython is way, way simpler than V8, but it's
| consequently slower. It's just the consequence of Google
| putting centuries of developer-years into an engine.
|
| You can't just claim Python is fast because Python's C
| libraries are fast. Those libraries are fast _despite_
| Python. Torch is extremely fast, but it 's fast from C
| and Lua too. There's valid reasons to want to _compute_
| in your programming language. Python is, ironically,
| probably popular _because_ its slow speed encouraged
| users to write blazing fast C libraries rather than even
| try writing native Python, vs. settling for middling
| performance as in Java or .NET.
|
| I shouldn't have to get out my hammer and tongs when
| NumPy doesn't implement the operator I need. Why can't
| Python be fast like Julia?
| devjab wrote:
| I fail to see how Python 3.8.2 could in anyway be
| relevant in 2024.
| pytness wrote:
| Relevant or not, python 3.13 shows the same thing:
|
| Python 3.13.0: 799.6559143066406 ms
|
| Node 18.20.4: 59.34080000221729 ms
| wiseowise wrote:
| V8 is a matter of investment of billions in expertise and
| time.
| slashdave wrote:
| As core languages, the scope of both Python and Go is
| fairly well defined.
| igorguerrero wrote:
| We got around 3m with seven guys, so yeah, and we don't even
| have on-call rotation / schedule, even though emergencies do
| happen from time to time. They think 1:1000 ratio is too big as
| well? That's crazy.
| mike_hearn wrote:
| Are you comparing a developer platform to consumer software
| there? Dev platforms have radically different support costs
| to regular SaaS or mobile apps. Developers are _really_
| support intense.
| mwcampbell wrote:
| > Developers are really support intense.
|
| Shouldn't developers be the most self-reliant users
| possible, especially when working with open-source tools?
| That is, shouldn't we expect that when a developer has a
| problem, they dive into the code and figure it out on their
| own?
| exe34 wrote:
| no, if I'm using your platform, it's because I really
| don't want to deal with the stinking pile of abstraction
| below that. so on the contrary, I would see it as a
| negative if the abstraction was that leaky.
| mike_hearn wrote:
| No, generally developers prefer to request help or work
| around an issue than dive in and fix it. The activation
| energy for contributing to an upstream project is high
| and very few do it.
|
| Developers are support intense because dev tools and
| platforms get used in a bazillion ways and combinations
| you can't predict. It's not like a nice consumer app
| where the user can only press a limited combination of
| buttons, and test coverage can be quite exhaustive. GUI
| toolkits are especially a bottomless pit of edge cases
| and bugs because they have tens of thousands of API
| methods, enormous numbers of features, they can all be
| used in combination, they have to run on multiple
| platforms usually and those platforms also have bugs etc.
| The support costs of a GUI toolkit are basically
| unbounded.
| mdhb wrote:
| Yeah, the person primarily behind this is a bit of an oddball
| in my experience who had a somewhat contentious relationship
| with the team which he himself was once a part of and it's not
| clear if he left or was asked to leave.
|
| But reading that post I couldn't help but shake the feeling
| that there might be other non disclosed reasons for the fork
| because some of the ones he did give as you pointed out didn't
| make a lot of sense to me either.
| LauraMedia wrote:
| I generally agree, the fact that the project relies on Google's
| internal steering is the much bigger factor in this to me.
|
| There is no guarantee these 50 devs can actually focus on
| Flutter, instead they might get looped in in the internal race
| to AI products.
| mdhb wrote:
| I mean we do actually have many years of real life experience
| at this point of how they perform in the real world.
|
| I've never actually come across a better maintained project
| personally. It is incredibly thoughtfully developed with a
| high level of attention to detail who have successfully
| shipped a huge number of major improvements in ways that made
| sense.
|
| There is a premise in the post that implies Flutter is poorly
| maintained and that's just not a commonly held belief by the
| community at all.
|
| As I hinted to in another comment the particular person
| behind this is a bit of an oddball and I think there may be
| other reasons that drove this decision in the first place in
| addition to the ones he gave in the post which for the record
| I'm sure there are some things he wishes were prioritised
| differently but this fork seems kind of very "him" rather
| than a popular position that people were begging for.
| fhdsgbbcaA wrote:
| 50 people is a pretty huge team at Google to start with,
| there's teams of <5 that support weird bits of core
| infrastructure that serve billions of users an hour.
| EGreg wrote:
| Exaggeration?
|
| Billions per HOUR seems quite a stretch there..
| fhdsgbbcaA wrote:
| Nope.
| EGreg wrote:
| Link to proof?
| fhdsgbbcaA wrote:
| Can't, but not sure why that's hard to believe?
| EGreg wrote:
| Because billions of people or their devices aren't even
| online every hour.
|
| Unless you're discussing background processes on google's
| side
| manquer wrote:
| Push notifications need to connect to that many devices
| every hour easily
|
| You may not get a notification every hour, but the phone
| still have to connect to Google APIs to check to know
| that.
|
| You can say same thing about say location services, every
| phone if powered and connected to the internet would ping
| more than one an hour, more than billion devices are
| definitely online at any give time, not just Android
| phones, also every android TV, tablet, watch, and the
| hundreds if not thousands of other devices running GMS on
| top of AOSP .
|
| There are probably few other APIs in GMS that would ping
| at least once an hour each device that is powered on,
| perhaps things like NTP for timing alerts or Emergency
| Alerts etc.
|
| You may consider them "Background Services" , most of
| them however have some foreground UI if they need to, and
| users will notice if they don't work
| fhdsgbbcaA wrote:
| There are roughly 5 billion smartphone users now, those
| devices are almost always on and sending background data
| somewhere. By volume, more of that data guess to Google
| than anybody else, on the order of hundreds of network
| requests per device, per hour.
| ziddoap wrote:
| Out of curiosity, what proof are you expecting to get? An
| internal Google usage report and a list of developer
| names that work on core infra?
| mvdtnz wrote:
| I don't find it hard to believe. I am not at Google but I
| work on a product with 200 million MAU, in a core team that
| serves requests to every single one of those users and
| there are 6 of us.
| toast0 wrote:
| I believe it. I've never worked at Google, but I was _the_
| engineer for SMS /Voice registration at WhatsApp,
| ocassionally with one other engineer (I believe the team
| was 3 when I left, not sure if it grew); I think there were
| two engineers doing my job for Facebook; although they had
| a little bit more scope, since there were more kinds of SMS
| they sent. That doesn't have a huge request rate, but it is
| super important.
|
| Something like DNS or BGP is going to have a tiny team and
| a huge impact. Load balancers probably has a bigger team,
| maybe 10-20 engineers, and almost everything goes through
| load balancers. And that's just the things that are easy to
| enumerate. I can think of lots of small teams when I was at
| Yahoo that worked on bits of software that are hard to
| explain, but were critical.
| fhdsgbbcaA wrote:
| Exactly, there's really like three dozen or so people
| globally who really should never be in the same room at
| the same time as the risk is too great they get hit by
| the same asteroid.
|
| I'd put "person who makes sure WhatsApp verification
| codes work" on that list.
| toast0 wrote:
| > I'd put "person who makes sure WhatsApp verification
| codes work" on that list.
|
| Thanks! That part of my job really wasn't too hard
| though, once I got things in order; but it was the
| easiest part of my job to describe. Just a lot of
| debugging from sparse data, and trying to get things to
| work a smidge better, because smidges here and there add
| up. It really helped to have a great customer service
| team that bubbled up usable information from users.
|
| Debugging things from sparse data gets you involved in a
| lot of different systems though... That and I told people
| I worked at an ISP in the before times, so guess who got
| to fight with sendmail, and guess who got to own our
| Domain accounts and DNS accounts and guess who got to get
| x.509 certificates, and who had to fight with Google Apps
| to make mandatory 2fa usable, etc. Basically everything
| without a person and server adjacent got me. :P
|
| Anyway, I've moved on (replaced by a team of three on the
| SMS stuff amyway, much better bus factor) and am semi-
| retired and no longer in any critical path, which is a
| lot less stress.
| munchler wrote:
| World population is 8.2 billion. Assume that 1/3 are asleep
| at any given time, leaving 5.5 billion awake. It's not a
| huge stretch to imagine 20% of them (1.1 billion) using
| core Google services during peak times.
| wg0 wrote:
| Common misconception is that you open source something and
| contributions will flock in. Doesn't happen that way.
|
| And even if happens - changes can't be merged without thorough
| and careful review. So who's do the reviews when supposedly
| there are too many contributors? Only someone who fully
| understands that particular subsystem.
|
| Which means we're back to square one because as per post there
| are only three subject matter experts available for the new
| fork.
| iamleppert wrote:
| It absolutely reads this way, and this person is in for a rude
| awakening. I thought all the Flutter team was laid off from
| Google anyways, effectively making this project dead in the
| water. Looks like there is a someone left over that can't let
| it go and just move on from the past.
| punduk wrote:
| The main problem in projects like flutter is to always focus on
| the "new". If you focus on the new without stabilizing the
| existing basic features, you will accumulate thousands of
| problems. If the same path is followed in this new project, I
| think the result will be the same. There is still no clear update
| on issues opened years ago. and most are pretty basic needs.
| markus_zhang wrote:
| I must be living under the rock. I thought Flutter is prosperous?
| I only dabbed into Android development as a learning experience
| so I probably missed something important.
|
| If everything the article says is true, should I switch to
| Kotlin?
| sgt wrote:
| 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.
| eseidel wrote:
| 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:
| irq-1 wrote:
| > ...the Flutter team is in maintenance mode for 3 of its 6
| supported platforms. Desktop is quite possibly the greatest
| untapped value for Flutter, but it's now mostly stagnant.
|
| Can you make any comment on this? Is it accurate?
| eseidel wrote:
| 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.
| loic-sharma wrote:
| Canonical gave an update on Flutter desktop last weekend
| at their Ubuntu Summit:
| https://events.canonical.com/event/51/contributions/533/
| wiseowise wrote:
| 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).
| sgt wrote:
| > :shrug:
|
| Is it time for HN to finally support Slack-style emojis?
| mdaniel wrote:
| I'd want them to fix this nonsense first
| https://news.ycombinator.com/formatdoc
|
| I'm almost positive you, personally, could implement
| support for those emoji short codes via Violentmonkey
| bsimpson wrote:
| > needs of the community
|
| The constant question of big tech OSS is who is it for/why does
| it exist? Did they make this because they think it's a useful
| tool internally, or are they trying to build a platform for
| external developers? If they built it because it's internally
| useful, then it's probably open-sourced for cultural reasons
| (the people working on it are used to being in open source
| communities and want to share what they're working on).
|
| Unless something is specifically being made as a platform for
| external developers (Android and Firebase come to mind), the
| level of support you'll get is at the whims of the team's
| current product leadership and budget. Both of those things
| change over time - a product manager can always say "let's
| focus on internal developers" and put the external community in
| maintenance mode. Based on the article's mention of desktop
| support being deprioritized, this might have happened on
| Flutter.
|
| Big tech funds things that would be really hard to pull off
| with just volunteers, but big tech projects can also be victims
| to the capriciousness of corporate politics and budgeting.
| skrebbel wrote:
| Agree, if it pans out this way in reality of course. That'd be
| splendid!
|
| NodeJS went through something similar. It was tightly
| controlled by a single company (Joyent) who were juggling too
| many balls, and progress went slowly. Community people did a
| fork (io.js) which shipped improvements faster, but they did so
| in a careful non-shitty way. This made lots of people switch to
| io.js, so that eventually NodeJS merged with io.js (iirc they
| just renamed the latest io.js "NodeJS").
|
| I don't know of any other instances of community forks of
| company-controlled OSS that did something similar though. If
| this is just one guy who made a blog post, like a sibling
| comment suggests it might be, then it might not pan out this
| way.
| croemer wrote:
| Wouldn't it be good to launch with at least a few bugs fixes?
| The launch is a bit thin, just mirroring, nothing to offer?
| maxrmk wrote:
| > 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.
|
| Back when I worked on .net we had fewer than 50 people
| maintaining a product that shipped to over a billion machines. If
| you opened an issue on github we'd usually reply that day.
|
| It's getting a bit long in the tooth, but I feel like 'the
| mythical man month' should still be required reading for software
| devs. More devs != better.
| hinkley wrote:
| 50 developers can do an awful lot - if they aren't trapped in a
| feature factory environment.
|
| The constant pressure to ship new features instead of only
| widely desired features overtaxes a team quickly.
| kgeist wrote:
| WhatsApp once had just 50 engineers with 900M users:
| https://www.wired.com/2015/09/whatsapp-serves-900-million-us...
| KeplerBoy wrote:
| What more do you need?
|
| That's still plenty of people if you got a few thousand
| people at AWS/Azure or in this case Meta's in-house cloud
| making sure your service is running and scaling as it should.
| maxrmk wrote:
| That ethos runs through everything the WA team does. I
| learned a bit about it when I was at fb and I was beyond
| impressed by how few servers WA used for its core
| infrastructure. It's a really well engineered product.
| l11r wrote:
| As far as I know Telegram has around the same number of
| engineers even today, handling around the same size userbase.
| redbell wrote:
| Today, Telegram serves around 1B users and is run by only
| 30 engineers: https://www.reddit.com/r/cscareerquestions/co
| mments/1djposn/...
| g-b-r wrote:
| And support is almost non-existent
| throw-the-towel wrote:
| On par with Google's, then.
| nostrademons wrote:
| Mythical Man Month applies to new product development, when you
| have a product you're trying to rush out the door that doesn't
| exist yet.
|
| Once the project already exists, is largely feature-complete,
| and is mostly in the "fixing bugs and small annoyances" phase,
| then Linus's Law [1] takes over. Debugging is very much
| parallelizable, because you can generally fix the bug without
| generating major impact elsewhere in the codebase, and if you
| have a good test suite you'll know if your fix has broken other
| invariants elsewhere.
|
| [1] https://en.wikipedia.org/wiki/Linus%27s_law
| munificent wrote:
| _> Once the project already exists, is largely feature-
| complete_
|
| That may be a reachable state for a command-line oriented
| operating system itself a clone of an older operating system,
| but is likely unrealizable in any sort of system that is
| trying to be actively more innovative.
|
| _> mostly in the "fixing bugs and small annoyances" phase_
|
| I don't know of any UI framework that has had the luxury of
| ever reaching that phase.
|
| _> then Linus 's Law [1] takes over._
|
| If you maintain a widely used framework, I think the more
| meaningful eponymous law is Hyrum's:
| https://www.hyrumslaw.com/
|
| This is probably the #1 source of friction for contributing
| to Flutter. It's not that the Flutter developers are
| overworked killjoys who don't value external contributors.
| It's that when, as the author of the blog post says, your
| codebase has a million users, it's _really hard_ for a
| contribution to not end up breaking _someone_.
|
| _> if you have a good test suite you 'll know if your fix
| has broken other invariants elsewhere._
|
| Sure, but the fix itself will still need tests. So now you've
| got to walk the contributor through the process of writing
| tests which is definitely not a skill that most software
| engineers have and is not particularly rewarding for an
| external contributor who already has a working fix and just
| wants their patch to be "done".
|
| Fundamentally, coordinating thousands of people to make a
| single codebase used by millions of people is hard. There is
| no silver bullet. It's a miracle it works at all.
| maxrmk wrote:
| I thought linus had lost it for a second there, until I saw
| it's just named after him and not something he created. I
| generally disagree - I think that having many developers with
| a shallow understanding of the whole codebase scales less-
| than-linearly with the number of devs.
|
| It's probably less actively harmful than new product
| development, but I'd still say a team of 50 is probably
| larger than is necessary for the amount of usage flutter
| gets.
| p1necone wrote:
| Having a large number of devs spot fixing issues as they come
| up without a deep understanding of the codebase is how you
| turn a maintainable project into a mess.
| com2kid wrote:
| > Back when I worked on .net we had fewer than 50 people
| maintaining a product that shipped to over a billion machines.
| If you opened an issue on github we'd usually reply that day.
|
| It depends on an org's priorities and what gets put on
| someone's reviews.
|
| During one of the years when I worked on Windows Mobile (before
| Windows Phone!) we had an objective handed down from on high
| that we were to spend so many hours a week on customer support
| forums helping people out.
|
| Well, for that year, customers all around the web got great
| support right from engineers! I got to paste lots of positive
| feedback from end users in to my yearly review, and I felt
| great about it!
|
| If Google cared about supporting Flutter as an Open Source
| project, they'd make the health of the open source project one
| of the measurements going into employee reviews at the end of
| the year.
| maxrmk wrote:
| Totally- This was in the early days of open source .net, when
| it was still called .net core. We had just moved onto GitHub
| and I don't think microsoft had quite figured out how to
| manage that organizationally. There is a point of time there
| where the fastest way to reach an engineer was not to go
| through a tier one contract that you pay microsoft millions
| of dollars for, but instead to just open an issue on the
| GitHub. I doubt that's the case anymore.
| com2kid wrote:
| > There is a point of time there where the fastest way to
| reach an engineer was not to go through a tier one contract
| that you pay microsoft millions of dollars for, but instead
| to just open an issue on the GitHub. I doubt that's the
| case anymore.
|
| Historically when MS was filled with software nerds, the
| fastest way was to post on an online forum!
|
| Sadly those days seem long gone. It doesn't feel like
| Microsoft empowers employees to really reach out and help
| customers anymore.
|
| I do remember responding to those Tier One support contract
| requests. IMHO that was a better system than what the large
| tech companies do now, which is basically just ignore
| customers no matter what.
| DaiPlusPlus wrote:
| > There is a point of time there where the fastest way to
| reach an engineer was not to go through a tier one contract
| that you pay microsoft millions of dollars for, but instead
| to just open an issue on the GitHub. I doubt that's the
| case anymore.
|
| That's still very much the case today, _BUT_ you absolutely
| need to do your legwork beforehand (e.g. include a
| copypastable program that reproduces the problem _and_ as
| thorough an analysis as you can do) otherwise your thread
| will go poorly... (and plenty of regulars in the dotnet
| repos aren't exactly the forgiving type). Compare that to
| what you get with a Support contract: you can be a non-
| technical person in Sales or the C-Suite or whatever and
| they'll hold-your-hand to guide you through the
| troubleshooting /diagnosis/repro process - and if the issue
| is an actual bug in MS' code then at least you get your
| ticket's fee/credits refunded.
|
| -------
|
| Unrelated-but-related: An LLM+multimodal "AI" would be
| fantastic for walking nontechnical users through the issue-
| reporting process. I'd wager the number-one problem in
| tech-support today is dealing with "It doesn't work"-type
| tickets which necessitates having to interrogate the
| user/customer/victim to get the details out - but if an AI
| agent (with screen-reading abilities) handles that (without
| a single audible sigh or facepalm) then that's a win for
| everyone.
|
| ...now if only StackOverflow had that.
| int_19h wrote:
| It really depends on the product. I don't know about .NET,
| but it's still the case for anything to do with VSCode, for
| example.
| justin66 wrote:
| The OP was talking about developers serving the needs of
| developers, and the ratio involved there. This is different
| than developers serving the needs of machines (fifty developers
| to some arbitrary number of machines is not automatically
| impressive) or developers serving the need of users. One would
| expect the ratios involved to be different for all three and
| highly context-specific.
| cbb330 wrote:
| Flutterfoundation.dev
|
| Was created for flock?
|
| This seems less of a fork and more of an attempted annex
| textlapse wrote:
| If someone could do the same with Xamarin/Maui that would be
| awesome!
|
| It's going down the same path unfortunately as Flutter did.
|
| Microsoft has de-staffed and deprioritized Xamarin/Maui to a
| point most of the folks are in Aspire-dotnet and related efforts?
| ClassyJacket wrote:
| It's such a shame mobile development with C# isn't more viable.
| I want to make some apps, and I _hate_ JavaScript, but from
| everything I 've read Maui just isn't practical.
| eseidel wrote:
| Flutter has seen a lot of Xamarin refugees. Even the founder
| of Xamarin himself is a big Flutter fan:
|
| https://twitter.com/migueldeicaza/status/1778759403451081159
| ivm wrote:
| The native approach is quite viable: my MvvmCross-based app
| has been on both stores since 2018 with almost zero
| MAUI/Xamarin-related issues, even with hundreds of thousands
| of installs.
|
| Not gonna lie though: building the UI twice for both iOS and
| Android feels somewhat masochistic. But in the end, it "just
| works" with shared View/ViewModel logic on both platforms.
| throwaway032023 wrote:
| Words are cheap.
|
| Seems like:
|
| - guy wants to add PR more aggressively to a code base than
| Flutter currently is
|
| - isn't clear if they have a concept of handling compatibility
| between fork and original
|
| - why not be a labor organizing entity and work with the flutter
| team?
|
| Some of the PR that I am aware of that are stale and could be
| good candidates - are difficult design decisions and stakes need
| to be put in the group.
|
| It seems ill advised. This is huge amount of work with limited
| upside and huge downside (adding uncertainty to outsiders looking
| in) and tons of effort (just in infrastructure maintenance).
|
| Edit: if I were conspiracy oriented I would think it's to harm
| community. I would pay this no mind.
| johnnyanmac wrote:
| Note that I know nothing of the Flutter team/culture and am
| only answering generally:
|
| >why not be a labor organizing entity and work with the flutter
| team?
|
| Depends on the maintainers/team. I've definitely seen many a
| bureaucracy that slows down FOSS to a crawl of bug fixes and
| feature progression. If you make enough PRs that are ignored
| for weeks or months, you'll realize this isn't really a team
| ready for nor interested in a proper FOSS environment and it's
| instead mostly "that teams code that happens to be readable".
|
| Their official answer seems to suggest as much:
|
| >But, 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.
|
| I guess we'll see. I'm way more of the mentality of "actions
| speak louder" so I'm not really one to announce my plans until
| I get something worthwhile off the ground (in this case, a few
| stale PR's that feel like game changers to the customers). But
| that's not a mentality modern social media rewards.
| throwaway032023 wrote:
| There is a comment above that shows the founding former
| didn't want to fix tests in his PR. Flutter is massive and
| it's critical infrastructure. The tests are critical to up-
| keep. The tests are probably a majority of the work. Which
| makes sense for something that has such a large surface area.
|
| I think this is an emotional reaction from someone has never
| managed a large project. Merging PRs and releasing them isn't
| the problem. I hope they understand that.
|
| Flutter is amazing. Web, desktop and mobile that actually
| work is nearly magical. Yes there are priorities. Yes the
| desktop isn't as high priority of web. It does work. Hell.
| Collect money and fund Hixie or others to prioritize patches
| community feel should go in. That is constructive and
| methodical/reproducible.
|
| Forking a massive code base, applying PR and not conforming
| to the source repo standards (tests whether that is golden or
| not) - just seems not well thought out.
|
| I think community could fund a well known developer to fix
| desktop issues and have PR adhere to Flutter standards. It's
| a ton of work. But seems like it's a money/dev/process issue.
| Not a PR merging exercise.
| concerndc1tizen wrote:
| Who's "We're" ?
|
| I only see a single name?
|
| Is this just some dude with a blog?
| snug wrote:
| 1 developer supporting 1 developer, better ratio than Google
| erichocean wrote:
| > That's 50 people serving the needs of 1,000,000.
|
| The SQLite developers must find this rationale hilarious.
| Vt71fcAqt7 wrote:
| >But, 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.
|
| I'd love to see some examples. I've had my pull request merged in
| a fairly quick amount of time - less than one release cycle,
| which is what matters here.
|
| Also frankly, nobody forking Flutter will be nearly skilled
| enough to work on the Flutter engine (Impeller). So it's hard to
| take this announcement seriously.
| pzo wrote:
| > Also frankly, nobody forking Flutter will be nearly skilled
| enough to work on the Flutter engine (Impeller).
|
| For me its so weird they ditched google/skia to develop
| Impeller in Dart from scratch in the first place. If skia was
| not ready they could move just 1-2 developers to Skia team to
| collaborate with them. Now they want to even write their own 3d
| rendering lib based on Impeller (flutter_gpu, flutter_scene)
| even thought google has already mature 3d engine in C++
| (google/filament). For me from the outside looks like "not
| envented in our team" syndrome. We are now in funny situation
| that react native has react-native-skia and react-native-
| filament and Flutter teams reinvents the wheels.
| xster wrote:
| https://github.com/flutter/engine/blob/main/impeller/docs/fa.
| .. discusses the reasoning a bit. There's more of a
| difference in the approach
| Vt71fcAqt7 wrote:
| Also related:
| https://github.com/flutter/flutter/issues/77412 - Hixie's
| issue that led to Impeller (or one of many issues)
|
| Some related iOS jank issues from that time:
| https://github.com/flutter/flutter/issues/32170
| https://github.com/flutter/flutter/issues/61450
| pzo wrote:
| Related https://groups.google.com/g/skia-
| discuss/c/Fzpne-f9gZ4/m/5_I...
|
| Seems like most issues could be solved with new Skia
| graphite backend
| irq-1 wrote:
| The build process for skia and its dependencies is huge.
| Flutter compiles (on windows) with CMake and Skia uses
| googles GN tool.
|
| https://skia.org/docs/user/build/
|
| https://gn.googlesource.com/gn
| pzo wrote:
| They been building it before and still building and
| releasing with flutter so it's not like they don't have
| pipeline for that. And it was distributed compiled so
| nothing to compile for 3rd party users.
| nmfisher wrote:
| As someone who has slowly been writing Dart/Flutter bindings
| for Filament[0] over the last couple of years, I agree the
| internal 3D engine was a bit of a strange choice of
| priorities.
|
| [0] https://github.com/nmfisher/thermion
| mannyv wrote:
| Hopefully this will turn into an EGCS-like situation.
| peppertree wrote:
| The fork is called "flock" and it's part of "flutter foundation"?
| It appears they forked Google's confusing branding strategy as
| well.
| pzo wrote:
| wait for similar WordPress drama if google owns 'flutter'
| trademark.
| zippergz wrote:
| They do.
| politelemon wrote:
| Yeah you are right. https://docs.flutter.dev/brand
|
| I expect there will be some communication from Google at
| some point and the foundation will have to be renamed. It
| reminds me of OpenTF being renamed to OpenTofu.
| pjmlp wrote:
| And so it slowly starts what everyone was expecting from Google
| projects that don't bring millions back home.
| pzo wrote:
| > 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.
|
| I doubt google have even 50 flutter devs in their team. You can
| easily estimate by checking github pulse:
|
| https://github.com/flutter/flutter/pulse/monthly
|
| https://github.com/flutter/engine/pulse/monthly
|
| Also take into account inflated commits by CI bots: engine-
| flutter-autoroll, skia-flutter-autoroll, auto-submit[bot],
| fluttergithubbot, flutter-pub-roller-bot
| xster wrote:
| https://ln.hixie.ch/?start=1714717681&count=1 is a sensible
| estimation
| pzo wrote:
| Actions (commits) speak better than words for me - flutter
| managers like (kevmoo) that are responsible for PR what gonna
| say? Probably you not gonna hear form them "Sorry we had
| layoffs and unfortunately our team is to small to handle all
| issues for now" Same with previous google employees that are
| still invested in flutter ecosystems by launching commercial
| products around it even if not at google anymore.
| throwaway032023 wrote:
| This sounds bitter and misinformed. Check automotive grade
| Linux and check GitHub for flutter embedders. Flutter being
| deployed all over the place. It's impressive. The tooling
| and DX is excellent.
| KTibow wrote:
| > Communication monoculture
|
| This point seems like a callout to a certain discussion and I
| kind of want to see it
| jonahx wrote:
| 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!
| skywhopper wrote:
| Weird, I'd never heard of Flutter (or at least it never
| registered), but then I'm an infra engineer, so why would I have?
| But particularly strange is that if you go to flutter.dev, you'll
| notice you can't find anything about who Flutter is. There's no
| about page with links to the people behind it, or any indication
| of what company sponsors it.
|
| Then this flutterfoundation.dev site... weirdly also doesn't say
| who's behind it. Presumably some outside folks? Maybe just the
| one person who wrote this blog post? But if it's called "Flutter
| Foundation" I would expect it to be more officially sanctioned?
|
| Were I in the market for a UI framework, none of this would make
| me feel very confident.
| munificent wrote:
| _> But particularly strange is that if you go to flutter.dev,
| you 'll notice you can't find anything about who Flutter is._
|
| It's on the front page: "A Global Open Source Community.
| Supported by Google, open to everyone."
| filleduchaos wrote:
| I had to scroll for fourteen whole seconds on my phone to
| reach that part of the landing page. Completely invisible if
| you ask me.
| skywhopper wrote:
| "Supported by Google" doesn't communicate "owned by Google",
| and anyway, marketing text in the middle of the page is not
| particularly telling. I expect a site about some technology
| to have an About page with some information about who is
| behind it and who funds it.
|
| Compare https://go.dev/project which explicitly mentions that
| Google runs the show. The front page makes it clear that
| Google runs the language's cloud infra. Plus there's the
| Google logo in the footer.
|
| The Flutter page never mentions who runs it. If it's
| independent but sponsored by Google, there ought to still be
| people involved. If it's owned by Google, it should be clear
| about it, and not just indirectly mention it.
| eseidel wrote:
| Well, myself and a few hundred other contributors are behind
| Flutter. Happy to answer questions.
|
| The flutter.dev page got rewritten to be more "marketing
| friendly" a few years back. docs.flutter.dev is still
| maintained by the engineers however.
|
| Regarding who exactly contributes to Flutter, it's all on
| GitHub, so you can see the actual committers, e.g.
| https://github.com/flutter/flutter/graphs/contributors
| https://github.com/flutter/engine/graphs/contributors
| https://github.com/dart-lang/sdk/graphs/contributors
|
| As for flutterfoundation.dev, it appears to be just Matt? Who
| used to be employed at Google and reported to me on the Flutter
| team but is no longer.
| chx wrote:
| > Imagine that you're the engineering director, or CTO of a
| company whose next release is blocked by some Flutter bug. What
| do you do if the team won't work on that bug for 2 years?
|
| Then you fix the bug? If your team can't then pay a consultant
| who can? Isn't it open source? What did I miss?
| skybrian wrote:
| 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 your own
| changes to work on that are more important to the team.
|
| We did something similar, by creating an external fork where
| changes could be tried out by the community, without necessarily
| being accepted into the internal version.
|
| I think a fork _could_ work if there was enough external
| momentum, but even 20 people working full time would actually be
| pretty good for an open source project. How many developers will
| this fork attract? The fork would need to attract other
| businesses who can put people on it.
|
| One downside is that the code isn't tested against google3.
| Sometimes you find actual bugs that way.
|
| Edit: reading more closely, the complaint doesn't seem to be that
| patches weren't reviewed, but rather that bug reports weren't
| investigated. That's definitely something outside developers
| could do more of, and seems a lot easier than forking?
| odo1242 wrote:
| What is google3?
| JoelEinbinder wrote:
| Google's monorepo of closed source code.
| gmoot wrote:
| Google's internal monorepo.
| yonran wrote:
| Here is a paper describing google3
| https://research.google/pubs/why-google-stores-billions-
| of-l..., which includes the policy that "To prevent
| dependency conflicts, as outlined earlier, it is important
| that only one version of an open source project be available
| at any given time." More documentation on The One Version
| Rule for third_party: https://opensource.google/documentation
| /reference/thirdparty.... This rule may make it more
| difficult to upgrade a third_party library frequently since
| the maintainer of the third_party library has to test all the
| uses of the library from all teams, rather than each team
| deciding when to upgrade.
| dekhn wrote:
| I used to maintain the internal (single) version of numpy
| and scipy and honestly I think the one-version rule was
| awesome. It greatly reduced noise and churn. It meant far
| less breakage, and it was easy to find and fix all the
| breaking tests when I was updating to a new version. I
| guess the only downside is sometimes an older version of
| numpy would prevent deepmind from making some sort of ML
| advance until I upgraded to get some new feature they
| wanted.
| hobofan wrote:
| Yeah, this seems to be a common theme with Google's open source
| projects. Bazel feels very similar in many points.
|
| It obviously wouldn't exist if not for Google putting resources
| towards it, but Google's (and google3's needs) are so
| significantly prioritized that it hurts the community. E.g. due
| to the low allocation of resources and extensive usage of
| rules_proto and bazel-skylib inside google3, they are
| completely ossified and the community has given up contributing
| to them and instead created either forks or contribution-
| friendly wrappers.
| Degorath wrote:
| Couldn't flutter work as public-first that then gets vendored
| into third_party? Or is that literally the fork strategy you
| are talking about that I'm too dense to understand?
| skybrian wrote:
| Yeah, that's what I meant. Public-first is good in some ways,
| but it means some bugs might be discovered rather late.
| xster wrote:
| 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
| EngVagabond wrote:
| Does that automatically run against every PR? What
| mitigations did you have to put in place for Google security
| to allow running untrusted code from PRs on internal CI?
| xster wrote:
| Semi-automatically. Googlers have to review it.
| serial_dev wrote:
| Also known as "manually".
| yencabulator wrote:
| > when you have your own changes to work on that are more
| important to the team.
|
| That part is the killer. Important to the Google Flutter team
| != important to the wider Flutter community.
| skybrian wrote:
| Or maybe it's not important to the community either?
| Sometimes, a bug is pretty obscure and only important to the
| person who filed it. People will get annoyed if they aren't
| investigated, though.
|
| It's good to be a little skeptical when people claim to speak
| for the community just because they're _part of_ the
| community. Often it's not so.
| 1oooqooq wrote:
| i avoid contributing to flutter because it feels like a google
| soon to be abandoned project.
|
| hacks like not accepting tabs in any tools and using space
| indentation wrong on top of it. tools ignore parameters like
| port numbers just so it works better for Android studio very
| specific use case while bringing pain to any ci pipeline, etc.
| jwildeboer wrote:
| How many people are the "we" this blog post talks about? 5
| people? 500?
| ckastner wrote:
| > flutterfoundation.dev
|
| It's not Flutter by own admission, it's very likely not backed by
| a foundation, and I highly doubt that Google consented to its
| "Flutter" trademark used for such a foundation.
| Apocryphon wrote:
| Should've gotten flockfoundation
| croemer wrote:
| Good chance that Google legal won't be happy and ask the
| website to be taken down. https://docs.flutter.dev/brand
| appveyor wrote:
| Is there any way to contact project owners besides X "formerly
| Twitter"?
| schnable wrote:
| What's the Flutter Foundation?
| dadrian wrote:
| Raise rates.
| macspoofing wrote:
| 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"?
| echoangle wrote:
| Google is the ,,owner" of flutter, why would they fork their
| own thing? The post is describing the problem the author has
| with google.
| ClassyJacket wrote:
| But they're using the Flutter trademark. It's a fair
| question. They appear to be using a trademark owned by
| someone else without permission.
| echoangle wrote:
| Right, give it a few days and the domain will change.
| macspoofing wrote:
| 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.
| swyx wrote:
| more context on flutter layoffs:
| https://www.theregister.com/2024/04/29/google_python_flutter...
| Alifatisk wrote:
| The layoffs wasn't Flutter specific, it happened across all
| orgs.
| coffeeaddict1 wrote:
| > What do you do if the team won't work on that bug for 2 years?
|
| This is reminiscent of how the Qt Company operates. Qt is super
| buggy and their bug tracker is full of unresolved bugs from years
| ago. However, the difference is that if you're a premium user you
| can pay for premium support to get someone to fix your bug.
| 1propionyl wrote:
| I really hate to be the big downer here but given Google's
| corporate culture is any of this really a surprise?
|
| Google and failure to support are at this point on par with
| peanut butter and jelly.
|
| I wouldn't ever trust anything Google cosigns as likely to have
| much longevity. At this point I just assume we all know better.
| divan wrote:
| > 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 replacement
| (just configuring FVM - Flutter Version Manager):
| Configure .fvmrc to use Flock: { "flutter":
| "master", "flutterUrl": "https://github.com/Flutter-
| Foundation/flutter.git" }
|
| 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. And the
| frustration described in the post is felt by many CTOs and
| developers. Especially those who use Flutter for desktop and web.
| Flutter provides an amazing experience for desktop apps, and
| precisely because of that, it feels so frustrating when you
| stumble upon some stupid bug that has been open for a year or two
| and never gets prioritized. Usually, it's nothing critical, but
| still requires workarounds and wasting time.
|
| I don't know, the idea of Flock sounds good, the main question is
| engaging the community. Hopefully, the author (who seem to be an
| ex-Flutter team member himself) have a good grasp on the state of
| the community.
|
| Wishing luck to the project and going to keep an eye on the
| progress.
| 1propionyl wrote:
| Flutter is really not some big revelation and it's always
| shocking to me how it's evangelists act like it's the game
| changer no one else has noticed.
|
| It's just not that good?
|
| Just build native UIs. I don't know why cross platform UI has
| been such a hobbyhorse for so many for so long: it's a stupid
| idea.
| divan wrote:
| > Just build native UIs
|
| Do you see any reasons why many companies/teams/devs don't
| want to "just build native UIs" and instead are looking for
| cross-platform solutions designed from ground apps for modern
| UI development needs?
| 1propionyl wrote:
| Yeah I do see why they don't want to do it and I see it as
| a critical failure of risk management.
|
| If you think pinning your entire product on a cross
| platform UI kit when every single one (except maybe QT) had
| proven a failure... then yeah I think maybe you should
| consider actually just eating the cost of building native
| UIs.
|
| The risk analysis of building against supposed cross
| platform "solutions" just doesn't work out. Why do we keep
| trying to do it?
|
| The idea of cross platform UI is frankly "f*cked from the
| jump" and should never have been a goal. I think it's only
| a goal because it's intellectually satisfying, not because
| it's really desirable.
| mdhb wrote:
| Back in the real world however you have canonical for
| years now who have made flutter the default for all
| native linux desktop development.
|
| I think your anecdotes are a bit out of date and
| irrelevant.
|
| People much better informed than you looked at this
| problem in a lot more detail in real life situations and
| came to very different conclusions.
| 1propionyl wrote:
| > you have canonical for years now who have made flutter
| the default for all native linux desktop development
|
| And yet, I can't think of a single app I depend on for
| anything on Linux that relies on it.
|
| How'd Snap go for Canonical?
| mdhb wrote:
| Cool, none of that is remotely relevant to what we are
| talking about here.
|
| Your anecdotes are dated and you should think about
| updating them so you don't talk so confidently on things
| you don't actually seem to know much about.
|
| I mean that sincerely not as some internet gotcha there's
| just no need to sit there defending a position that is
| based on old info just for the sake of it.
| divan wrote:
| > and I see it as a critical failure of risk management.
|
| I also want to live in the world where risk management is
| the only variable that determines how CTOs and devs
| choose the stack for the software.
| LordDragonfang wrote:
| 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.
| contextfree wrote:
| "WinUI3 hasn't even officially launched"
|
| ? It officially launched with version 1.0 and it's now on
| 1.6?
| c-hendricks wrote:
| 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/
| int_19h wrote:
| Hence why OP was specifically talking about WinUI 3
| (which is indeed at version 1.6.1 as of right now).
| poulpy123 wrote:
| 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
| :)
| LordDragonfang wrote:
| I suppose it was incorrect of me to say it hasn't
| "officially" launched then. But one would certainly seem
| to get that impression, considering it's missing major
| features (data table support?) isn't anywhere near
| feature parity with _either_ WPF or winforms, and doesn
| 't even have a visual editor (which should be table
| stakes for a modern 1.0 release from a company as large
| as Microsoft).
| jcelerier wrote:
| Qt either Widgets or Quick definitely does not use a web
| renderer
| epcoa wrote:
| 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 MacOS/iOS is pretty busted
| at this point. At best it just means something non-web.
| dotancohen wrote:
| I would consider both GTK and Qt native on Linux.
| epcoa wrote:
| So that means one has to target both GTK and Qt to be
| native on Linux. Fat chance of that on anything but yet
| another music player or other relatively trivial UI app.
|
| In any event, that still doesn't answer what it means to
| be "native"? And my point is I think most definitions are
| dumb or useless.
|
| If I'm running a GTK desktop, Qt apps are generally not
| "native" no matter how much theme fuckery one tries.
| Native can also speak to other common UI affordances and
| design guidelines, and there sure as hell is nothing like
| there is in the MacOS world for linux. Some core GNOME
| and KDE desktop apps maybe, but overall there isn't much
| adopted standardization in Linux world.
|
| 90% of the work I get done involving a GUI outside a
| browser on Linux usually involves Java, whether it be
| Intellij, ghidra, etc. Maybe I'll pick up blender from
| time to time. Audacity, there's a good one, targeting
| (for now) a cross-platform toolkit that pretends you can
| have your cake and eat it too - wxWidgets never fooled
| anyone - they sure as hell don't look native on MacOS,
| and they invariably look much closer to what they riffed
| off of, a 90s MFC app. (And wxWidgets wraps GTK and
| AppKit, so is it native? If so, native is meaningless
| IMHO. If not, why not?)
| einpoklum wrote:
| > So that means one has to target both GTK and Qt to be
| native on Linux.
|
| Doesn't it mean that you can target _either_ and be
| considered native?
|
| Also, I'm not sure I buy the claim that of "GTK and Qt
| are native" in the first place. I'd say either that there
| is no native UI, or if I must call something native, it's
| the toolkit the desktop environment uses. And yes, that
| does mean that there is no "Linux nativeness" like there
| is Windows nativeness, as every DE is different. And
| rightly so, because one could in principle write a
| different DE over the Windows kernel, whose UI would
| behave differently.
| epcoa wrote:
| > Doesn't it mean that you can target _either_ and be
| considered native?
|
| Well, no because I was agreeing with you, if you're going
| to grudgingly accept your definition for native, the
| toolkit the desktop environment uses, that means you
| would have to target both Qt and GTK unless you want to
| draw a line in the sand and say fuck it to one of GNOME
| or KDE as assume they don't exist. Sorry GNUStep. And
| this is nothing to say of GTK 2-4.
|
| I agree that just saying GTK or Qt are native in a vacuum
| outside of DE is a completely useless definition, and
| even taking DE into account is a tenuous one.
|
| As for Windows, what GUI toolkit does the desktop
| environment there use? That's a trick question.
| dotancohen wrote:
| > So that means one has to target both GTK and Qt to be
| native on Linux.
|
| Incorrect. Target one or the other, not both.
| epcoa wrote:
| How is Qt within a GNOME or Xfce environment any more
| "native" than Qt on Windows or Mac?
|
| You have reduced the definition of "native" to merely
| compatible with X11/Wayland (that's the only common
| denominator). Well now, Tk, FLTK, Swing, and even Wine
| are all native.
| notpushkin wrote:
| Both Qt and GTK have facilities for integrating into each
| other's desktop environments (see [1]). Sometimes they
| blend in nicely, sometimes they stand out a bit, but I
| think it works out pretty okay.
|
| [1]: https://wiki.archlinux.org/title/Uniform_look_for_Qt
| _and_GTK...
| epcoa wrote:
| > Both Qt and GTK have facilities for integrating into
| each other's desktop environments
|
| Neither Qt nor GTK are desktop environments and Qt
| certainly isn't defined by a dominant desktop environment
| - KDE isn't even what pays their bills.
|
| You're still proving my point. The common denominator
| here (on Linux) is just X11/Wayland. If it works out
| "pretty okay", then score one for a cross platform
| toolkit. Still no idea what uber alles "native" means.
|
| Let's go back to the original comment I responded to...
| why should I not just continue with the Qt "stupid"
| "hobbyhorse"
| account42 wrote:
| GTK doesn't much care about integrating into a Qt
| environment and doesn't really implement anything to make
| that work besides in some cases implementing the same
| Freedesktop standards. Even for basic things like the
| look of widgets you need a style that has implementations
| for GTK - there is no compatibility layer to use Qt
| styles. Gnomies in general don't care about anything
| outside their world.
|
| The other way around is a bit better, e.g. there is
| QGtkStyle but AFAIK it is stuck at GTK2 and does not
| support using GTK3 styles. Still, behavior between GTK
| and Qt applications is very noticeably different.
|
| It would be great if there was a shared ABI applications
| could use but GUI toolkits are too complicated for this
| to be feasible.
| jeremyjh wrote:
| 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 fragmentation for users on those platforms
| to realistically expect commercial software to support them
| natively? Yes, of course, but that doesn't mean there is
| any confusion about what it would mean to do so.
| int_19h wrote:
| 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.
| epcoa wrote:
| > Linux is a kernel project,
|
| Is that useful pedantry? From context, you really think
| that's my confusion here? I didn't include *BSD either,
| but it isn't any different for the relative handful of
| people using that for a desktop system.
|
| > Win32 is the native GUI toolkit on Windows. Winforms is
| a .NET wrapper to it. There isn't any debate to be had
| there.
|
| Except for Microsoft's numerous attempts to supplant it
| and the fact that the base OS doesn't even use it
| consistently for their own system. Microsoft's own File
| Explorer and Settings app that only had to live along
| with Control Panel for a decade, was that not native?
| They aren't "Win32". If you insist on pedantry, you
| should know Win32 isn't a GUI toolkit either, it's an
| anachronistic term for the Windows API. Nobody casually
| calls it USER though, and the bulk of people still
| targeting it do so through .NET these days via Winforms.
|
| If native just means provided by the vendors base system,
| ok, but then if there are 10 different forms of it, other
| than the distribution issue there isn't some great
| intrinsic benefit over just targeting Qt or Flutter.
| Especially when someone like Microsoft can't settle on a
| consistent design language through the years.
| jeremyjh wrote:
| >Is that useful pedantry? From context, you really think
| that's my confusion here?
|
| I don't know what could possibly confuse anyone about the
| role of GTK and QT in the Linux ecosystem.
| epcoa wrote:
| GTK 3 or 4? Xfce+MATE+Cinnamon are still popular enough
| options and I used the former for years. GTK itself isn't
| even a well defined target.
|
| And GTK3 apps of which there are plenty do not appear
| native in a modern GNOME desktop much more so than a
| decent Qt app does.
|
| The thing is that people in the real world talk about
| _Linux_ support for an app, as in Desktop Linux support,
| and the only common denominator there for years was
| basically X11. I have heard exactly no one ever ask, oh
| when is that app going to be available for KDE or GNOME.
| For example, to take something recent here, do the people
| writing the Zed editor promise a particular DE support -
| no it 's available for "Linux."
|
| As to earlier mentioning distros - for a GUI app, there's
| more pain from intra-distro variation than inter-distro,
| both across configurations and supported versions.
|
| Now the big thing, the even bigger thing is probably
| native Wayland vs X11, but no one says, oh vendor will
| you please bring your app to _KDE_ or GNOME,
| specifically. 99% of the time you are happy if you get
| anything at all. So the concept of native on Linux
| (Desktop Linux) just isn 't something usually worth
| discussing.
| skissane wrote:
| > If you insist on pedantry, you should know Win32 isn't
| a GUI toolkit either, it's an anachronistic term for the
| Windows API.
|
| I don't think it is "anachronistic" - as far as I am
| aware it is still the official name. And I don't think
| calling it the "Windows API" is right, since Win32 is
| just one of the APIs that Windows offers. If I'm calling
| CreateFile, I'm using the Win32 API, but if I'm calling
| NtCreateFile, I'm not using the Win32 API, I'm using the
| native NT API instead. If I set the subsystem as NT
| instead of Win32 in my executable's PE header, calls to
| native NT APIs such as NtCreateFile will still work fine,
| attempts to use Win32 subsystem APIs won't. And there are
| other APIs Windows has which aren't (strictly speaking)
| part of either the native NT API or the Win32 API - COM
| and the many APIs built on top of it, .Net, WinRT,
| DirectX, etc.
|
| But you are right that Win32 isn't a GUI toolkit. It
| contains a rather basic and old-fashioned GUI toolkit
| (USER), but it contains a lot of non-GUI APIs too. I'm
| reasonably familiar with those parts of the Win32 API
| used by services and console mode apps, but if you asked
| me to write a Win32 GUI event loop I'd be asking ChatGPT
| to remind me how, because while I've read tutorials I've
| never actually attempted it.
| epcoa wrote:
| The name itself is anachronistic, what does the 32 stand
| for? You call CreateFile with 64-bit pointers, it was
| still considered Win32 (until they officially changed
| it).
|
| But take it up with Microsoft:
| https://learn.microsoft.com/en-
| us/windows/win32/apiindex/win...
|
| "Using the Windows API, you can develop applications that
| run successfully on all versions of Windows while taking
| advantage of the features and capabilities unique to each
| version. (Note that this was formerly called the Win32
| API. The name Windows API more accurately reflects its
| roots in 16-bit Windows and its support on 64-bit
| Windows.)"
|
| The URL still has win32 in it, lol.
|
| Though this naming goes back nearly 2 decades
| https://learn.microsoft.com/en-us/previous-versions/tn-
| archi...
|
| The API provided by ntdll is semi-officially called the
| "Native" API and much of it is subsumed into the Windows
| API. The PE subsystem names you are referring to are
| IMAGE_SUBSYSTEM_NATIVE and
| IMAGE_SUBSYSTEM_WINDOWS_GUI/CUI, so it's somewhat
| consistent. Microsoft officially refers to that API as
| Native System Services in the documentation for the DDK.
|
| https://learn.microsoft.com/en-
| us/sysinternals/resources/ins...
| skissane wrote:
| Microsoft's docs are a self-contradictory tangled
| incomplete and sometimes even downright erroneous mess, I
| wouldn't put too much stock in what they say.
|
| If I say "CreateFile is the Win32 API analog of
| NtCreateFile in the NT native API", everyone experienced
| with low-level Windows development will know what I am
| talking about. If I started talking about "Native System
| Services", I'm not sure as many would.
|
| Similarly, the distinction between APIs which are easy to
| call from C code (and simpler FFI frameworks from
| scripting languages, e.g. libffi) and
| COM/Automation/.Net/WinRT APIs which are a lot more
| difficult to use from C (as opposed to C++), and which
| require more advanced FFI support, is still important in
| Windows development (or at least some parts of it.) And
| in practice the term "Win32 API" is often defined to
| exclude those higher-level harder-to-call-from-plain-
| old-C APIs.
|
| It goes back to the original design of Windows NT, where
| you had a primary environment subsystem (Win32),
| secondary environment subsystems (OS/2 and POSIX), and
| integral subsystems (local security authority, session
| manager, etc). The primary environment subsystem is still
| called Win32, and the Win32 API is its public API. (It
| also has private APIs, most notably the CSRSS LPC
| interface, but that's unstable from version to version.).
| As I said "Windows API" is insufficiently specific
| because (especially nowadays) Windows has lots of other
| APIs. WinRT and Win32 are both Windows APIs but very
| different. WinRT is largely built on top of Win32, but
| some documented WinRT APIs are built on undocumented
| Win32 APIs, leaving WinRT the only officially supported
| API to access certain functions.
|
| Microsoft intentionally didn't rename Win32 to Win64 when
| they added 64-bit support because it is 99% the same API
| just with some highly regular changes (mainly widening
| pointers). By contrast, Win32 was a much more radical
| change to Win16 - the Win16 API directly incorporates
| notions of segmented memory, which it uses to implement
| movable memory blocks (rather similar to Classic MacOS,
| albeit that did it in a 24/32-bit flat memory model
| rather than a 16-bit segmented one). Microsoft could have
| done a more straightforward port of Win16 to 32-bit x86,
| e.g. using a 32-bit segmented memory model instead of
| 32-bit flat memory, keeping movable memory; but
| (thankfully) they didn't. It would have made it a lot
| harder to move to 64-bit or non-x86 platforms.
| foresto wrote:
| > What is native on Linux? Gtk, Qt, Motif (lol)?
|
| Linux is not something that encompasses a GUI, so this is a
| misguided way to frame the underlying concern. One might as
| well ask what toolkit is native on smartphones, or what
| language is natively spoken by humans.
|
| We should instead ask what is native on Plasma, or on
| GNOME.
|
| "Oh, bother. That would mean I have to think of _four_
| things instead of three. "
|
| Well, yes, Pooh. But the things that make them different
| are the things that make them, them.
| epcoa wrote:
| Ok but this is in response to this:
|
| "Just build native UIs. I don't know why cross platform
| UI has been such a hobbyhorse for so many for so long:
| it's a stupid idea."
|
| The stupid idea is thinking that building native UIs is
| targeting a clean, non-moving target and implying it is
| not astronomically harder than doing something cross
| platform that is between mediocre and good enough for
| everybody _.
|
| Whenever someone says "just do native" it always turns
| out they have a cockamamie definition of native,
| otherwise they would realize the gravity and general
| unreasonableness of what they were asking.
|
| On a side note, what's a _major* reasonably complex app
| that isn't a music player or an IRC client, or something
| with a simple shell around a canvas like a browser, that
| targets both Plasma and GNOME natively.
|
| * And whether anyone likes it or not, few people care (as
| revealed by $$, not bitching on a forum). Blame electron,
| the web, but even Microsoft cannot even define and
| maintain a native LnF for their core operating system. As
| I alluded to, the only small community that cares are
| those on MacOS and iOS, where there is a HIG that more
| than 2 people have read and give a shit about, and there
| is a small market of people that value well integrated
| Mac apps that will actually spend money. Targeting Win
| USER32 +/- XAML, Qt, GTK, and AppKit is costly and
| thankless when you probably could have just used Qt,
| JavaFX, or Flutter, etc.
| dgellow wrote:
| WinUI3 doesn't kill WinForms... WPF, WinUI, WinForms all
| exist together
| epcoa wrote:
| You missed the sarcasm. If all can exist together, which
| one is the "native" one? If the answer is all of the
| above, then the consistency argument for native doesn't
| hold much water.
| wiseowise wrote:
| > I don't know why cross platform UI has been such a
| hobbyhorse for so many for so long: it's a stupid idea.
|
| You suggest to build and maintain same logic in at least
| C#/C++ + Swift + Kotlin + JS + C++ and you ask why
| crossplatform UI is a popular idea?
| kernal wrote:
| >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 agree with you that Flutter has been a boon for cross
| platform development, but to say it's impossible to tell you're
| using a Flutter app is a bit of an exaggeration. I have no
| problem identifying Flutter apps. Not that I care as they often
| have a genuinely nice UI and are performant.
| dotancohen wrote:
| Is the complete lack of accessibility still the giveaway?
| Last I looked Flutter was a complete nonstarter for
| accessibility.
| divan wrote:
| Can you elaborate? What's missing that makes you feel
| confident saying "complete lack of" despite well-documented
| accessibility functionality (including testing for
| accessibility)? [1]
|
| [1] https://docs.flutter.dev/ui/accessibility-and-
| internationali...
| hyperhopper wrote:
| I worked on the GPay flutter rewrite and our standard for
| accessibility was higher than almost any other app I've
| seen, and was a significant amount of effort spent on that.
| What accessibility shortcomings does flutter have?
| jonas21 wrote:
| This may be a silly question, but how do I install the
| Google Pay app on my iPhone?
|
| I'd like to try it out since it's the first app listed in
| the Flutter Showcase, people keep mentioning it in this
| thread, and it probably works as well as a Flutter app
| can, given that it's first-party from Google.
|
| But when I search for it on the App Store, it's nowhere
| to be found (or at least not in the first 20 results).
| satvikpendem wrote:
| It's only for the Indian market. As Google often does,
| they released Google Wallet for the US market. But that's
| not a failure of Flutter itself of course, only internal
| Google politics.
| onlyhumans wrote:
| Google pay was never able to fix the pre-compiled
| animation rendering issue on iOS where the first
| transition or animation is always janky and then it gets
| cached and no longer has jank.
|
| That is quite a non-starter imo
| ClassyJacket wrote:
| How do you know this isn't the toupee fallacy?
|
| You spotted a few correctly so you assume you always spot
| correctly - but there might be more you miss.
|
| https://rationalwiki.org/wiki/Toupee_fallacyhttps://rational.
| ..
| divan wrote:
| How do you do that? I just opened my phone, and the last app
| I used was a food delivery app. How can I figure out if it's
| a Flutter app or a native one?
| no_carrier wrote:
| I don't think people are able to tell a Flutter app from
| any other cross platform/web framework. They just think
| they can.
| jwells89 wrote:
| It's more difficult to distinguish if an app is Flutter
| or some other cross platform framework, but "native or
| not" is very easy on iOS. Even React Native, which is the
| least foreign, has tells.
|
| On Android it's more difficult, partially because it's
| kind of like Windows where Google/Microsoft uses 50
| separate reimplementations of Material/Fluent and there's
| no consistency to be found anywhere.
| knifie_spoonie wrote:
| I'm really curious what the specific tells are. Do you
| have any specific examples?
|
| When using the apps on my iPhone, I just don't see how I
| could tell the difference.
| jwells89 wrote:
| For React Native it's common for navigation to be weird
| compared to UIKit/SwiftUI apps. Also common for things
| like padding/margins to be off since standard layout
| facilities aren't being used, and devs of RN apps will
| often visually customize controls (web style) that native
| devs don't.
|
| For Flutter, the most visually obvious thing (aside from
| usually using Material Design) is that its animation
| curves are all totally different from those of
| UIKit/SwiftUI and interact with gestures differently. The
| Cupertino theme is a poor facsimile of UIKit and lands
| squarely in the uncanny valley, which is arguably worse
| than Material Design. Flutter on iOS also tends to hitch
| where UIKit/SwiftUI don't.
| xster wrote:
| There's likely things we missed but we'd love to find
| examples you might have. We try to be scientific as much
| as we can https://github.com/flutter/flutter/pull/122275
| [coincidentally a community contribution from someone who
| didn't have to fork :)]
|
| Disclaimer: used to work on some of these animations
| exusn wrote:
| Yep, same. For me the animations are a dead giveaway if
| an app is using flutter. That, and the scrolling just
| feels _off_ in a way I can't quite describe and is a
| little clunky.
|
| I had been building stuff with flutter for a while when
| GPay migrated to it and I could straightaway tell from
| the performance that it was flutter.
| divan wrote:
| Ah, so we talking about two different things here:
|
| a) with any given UI design, distinguishing if it's
| implemented using native UI framework or with Flutter
|
| b) Flutter app providing 100% indentical look&feel to
| Cupertino/MaterialDesign/WinForms/Cocoa/etc.
|
| I was talking about a). Assuming that the app developer
| wants to have a consistent app design across platforms,
| which probably came from a design department - there is
| virtually no way to distinguish. Ultimately, it's just a
| bunch of pixels spit out onto the framebuffer.
| deergomoo wrote:
| > 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 the Flutter showcase[0] and calling those apps up to
| look at screenshots on the App Store--none of them look like
| native iOS apps. They don't look _bad_ (mostly), but they don
| 't fit in.
|
| Don't get me wrong, I don't expect anyone else to care or even
| notice. But for those of us that do care, you can absolutely
| tell.
|
| [0] https://flutter.dev/showcase
| divan wrote:
| 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.
| pasc1878 wrote:
| The trouble with this is most users only use one platform
| and so don't care. They just see the app as badly
| implemented as it does not match other apps on the
| platform.
| justmarc wrote:
| Why would an app not looking like a native app
| automatically be seen as badly implemented?
| jwells89 wrote:
| Not all non-native-looking apps are badly implemented,
| but a huge number of apps that use cross-platform
| frameworks do so primarily as a means to cut costs
| because the goal is to make development as cheap as
| possible, and that shows in other aspects of these apps
| too. This creates an association between cheap/lazy apps
| and cross platform UI frameworks.
|
| It's kind of like the difference between VS Code and MS
| Teams. Same company, same underlying technology
| (Electron), but Code is good while Teams is awful because
| MS invests so much more in Code. Even so, Teams-type apps
| are what tends to come to mind when people think of
| Electron apps because those are so much more common.
| Anon1096 wrote:
| You could not be further from the truth regarding the
| size of the Teams vs VS Code teams. Teams has multiple
| times more developers, it's not a problem of funding that
| makes it suck.
| justmarc wrote:
| Sometimes the bigger the team, the messier it gets and
| quality suffers greatly.
| pasc1878 wrote:
| In my case there is another reason - if it looks cross
| platform it is probably taking up more resources than a
| native app.
| divan wrote:
| 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 built the understanding that users
| dislike non-native UIs?
| Eisenstein wrote:
| 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.
| divan wrote:
| I think it may be true only for the apps that are easily
| replaceable.
| satvikpendem wrote:
| 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.
| Eisenstein wrote:
| _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.
| satvikpendem wrote:
| It's more than there is no evidence of an issue, so why
| pretend that there is? The "right" way is entirely
| subjective, unless you can give me some objective
| criteria for what it should be.
| Eisenstein wrote:
| The issue in this case is pretty plainly that the
| application does not subscribe to the conventions of its
| host UI. I'm sure there is no objective reason why we
| need to conform to any convention, except that there is
| one.
| satvikpendem wrote:
| Then that is subjective too and not really worth caring
| about, because it comes down to a matter of taste. You
| like platform conventions, but most people we surveyed
| simply don't care, the fallacy of vocal minorities and
| all.
| myko wrote:
| I used to think this, now I think nobody cares except
| people "in the know"
|
| Every time I've ever mentioned it to anyone they really
| didn't seem to understand or care
| satvikpendem wrote:
| It really feels like an "HN bubble" type argument, I've
| literally never heard it outside of HN.
| deergomoo wrote:
| 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 people just don't care
| about platform idioms, and b. the choice is often a non-
| native app or no app at all.
| brewii wrote:
| 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.
| deergomoo wrote:
| You're completely right, but that doesn't change the fact
| that I think it's a bad idea. For a company that used to
| care _so_ much about user experience, Apple has been
| throwing a lot of it out the window in recent years.
| jwells89 wrote:
| The two things that stick out the most to me are
| navigation behavior and text fields. Cross platform
| frameworks seldom get either right, with react native
| being particularly bad on the navigation front.
|
| There are variances between Apple's apps but they're all
| using some combination of UIKit and SwiftUI regardless
| which limits how "wrong" they can be.
| dwaite wrote:
| "cupertino" is the name of a Flutter widget set, not of
| the native platform controls or L&F.
|
| Few Flutter apps are going to use cupertino because the
| whole goal of using Flutter is to create cross platform
| codebases to save development effort. To use an
| alternative widget set per platform is a huge amount of
| additional work, and having a cupertino app running on
| Android is even more of a sore thumb than a material app
| on iOS.
| seanw444 wrote:
| > and having a cupertino app running on Android is even
| more of a sore thumb than a material app on iOS.
|
| That is a bizarre fact.
| ToucanLoucan wrote:
| > 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, I can _smell_ a framework app.
| dwaite wrote:
| > I will Pepsi challenge this with anyone who asks, I can
| smell a framework app.
|
| The platforms ship with things like keyboard shortcuts
| for navigation and text entry, minimal accessibility
| features like screen reading of text and navigation,
| common idioms like drag and drop and the clipboard - none
| of which are typically handled by cross-platform widget
| frameworks by default.
|
| Only gigantic projects like Chrome and VS Code will take
| on the effort of (partially) reimplementing these in
| their codebases to match platform behavior.
| satvikpendem wrote:
| Do you only use Apple devices? That may be why, because
| statistically most of the world's population uses Windows
| and Android where there really isn't a concept of
| "native" because they each have a few different UI
| frameworks.
| stuaxo wrote:
| There was a time it looked like cross platform GUI
| toolkits would get us there, but things went in reverse.
| knifie_spoonie wrote:
| > 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.
| int_19h wrote:
| 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.
| knifie_spoonie wrote:
| I've not found this to be the case at all. They only seem
| to care whether the app does what they want or not.
|
| Granted this is my personal experience, I can't say this
| is the case for every single user out there.
| drdaeman wrote:
| 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 of
| reference (vendor-supplied native apps).
| satvikpendem wrote:
| Is there a concrete example of this? I still only hear
| this on HN where some mythical user gets annoyed about
| copying and pasting (most apps don't allow that, even,
| like TikTok or Instagram, which are the apps where most
| users spend the most time). Like the sibling commenter, I
| only have seen whether the app does what they want or it
| doesn't, most don't notice any annoyances unless they're
| really looking for them, which they're not.
| satvikpendem wrote:
| 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.
| pastage wrote:
| 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 technical reasons why, but
| when you talk about the annoyances it is easier.
| milch wrote:
| 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
| basilgohar wrote:
| It's not the end users that care about the uniformity but
| the fact the corporate design team wants there to be
| uniformity across all their platforms they support. This
| is part of branding and user experience. I'm not arguing
| for or against, just stating that is where the push for
| this comes from. It would make support, for example,
| easier, if all versions of your app user experience were
| similar.
| robertlagrant wrote:
| I'm not quite sure why this was downvoted. It's true.
| satvikpendem wrote:
| It's because while it's true on the company side, this
| comment is making it seem as if the company is doing this
| against their users' will, while in reality, most users
| genuinely want a unified experience across platforms for
| their apps, as seen by some of the comments here.
| robertlagrant wrote:
| It doesn't seem to mention it being done against anyone's
| will. It's definitely true that a company can save money
| by only needing to maintain one set of help instruction
| screenshots, for example.
| kelnos wrote:
| Right, but you continually conflate "unified experience"
| with "using custom UI controls".
| satvikpendem wrote:
| I never said they must be custom, merely that custom
| makes it easier to implement.
| zdragnar wrote:
| Hello! I use three platforms on a daily basis. I vastly
| prefer my apps to be reasonably consistent with
| themselves rather than trying too hard to adhere to the
| platform.
|
| My wife is on two. Most of my friends are on either two
| or three. In fact, I'm pretty sure my parents and a few
| coworkers are the only people I know who are exclusively
| on one platform.
|
| Many (most?) people don't have a clue as to what the
| particulars of any given platform even are. They know how
| to get around in each app they use, and maybe the web
| browser, and that's it. Lots of gestures go completely
| unused.
| maeil wrote:
| Ever since the release of the M1, the number of Android
| users who now use Macbooks as their laptop has sharply
| increased. Even moreso for work purposes.
| nl wrote:
| I use MacOS, iOS and desktop Linux regularly and much
| prefer apps that act the same on them all.
|
| Maybe 40% of the developers I know use MacOS + Android.
| satvikpendem wrote:
| 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 desktop and phone but not
| so for Windows and Android, so you have to make a choice
| at that point.
| Someone wrote:
| > 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.
| kibwen wrote:
| _> You shouldn't trust what users say they want._
|
| How should I interpret the following four paragraphs
| where you say what you want?
| satvikpendem wrote:
| If you have zero evidence against the mountains of
| evidence I do have, why should I be convinced of your
| argument. It seems like it is you who are talking
| subjectively about what you want and then applying that
| to everyone else.
| nuancebydefault wrote:
| I find it very hard to believe that majority of people
| prefer app consistency over platform consistency.
|
| One example, I'm pretty sure there are thousands more:
| Why does every UI detail, except the logo, of Spotify
| looks and feels different in Android, Android Auto and
| PC/laptop? Because Spotify did not study what the market
| wants?
| satvikpendem wrote:
| Spotify looks much similar between devices than it does
| to any specific platform. Does it use Material on Android
| and Fluent on Windows? No, it uses the same sort of
| styling on both. Don't mistake UI changes for screen size
| responsiveness, for actual platform specific nativity.
| kelnos wrote:
| > _The vast majority of people said they wanted apps to
| act consistently across devices_
|
| ... which you can absolutely do while using native UI
| controls. "Act consistently" (UI controls are in similar
| places and present themselves with similar UX) is not the
| same as "look consistently" (UI controls are drawn using
| whatever system theme or drawing style is in use).
|
| Certainly there is _some_ overlap between look & act: a
| platform-native "dropdown menu" looks and acts a little
| differently on Windows vs Android vs iOS. But I think
| these differences are not in the majority, and when users
| say they want apps to "act consistently" across
| platforms, you an absolutely achieve that with native UI
| controls, and it's not even that difficult.
|
| This is a big problem I've run into when doing user
| studies myself: you need to be very precise with your
| language when asking users questions, and even then you
| often need to dig in and ask for details about what they
| mean by their answer. And of course having visual
| examples and functional mockups for users to play with
| helps a ton.
|
| Another problem is the leading nature of questions you
| might ask during a user study: if you simply say "do you
| think it's better if the app acts consistently across
| platforms", _of course_ users are going to say "yes".
| Saying "no" to that question feels kinda stupid, TBH. But
| if you were to give a user an iPhone and Android phone,
| with the same app, using native controls on both
| platforms, and ask them if you believe that the apps "act
| consistently" with each other, users are probably going
| to say "yes", as long as the design and UX of the apps in
| general are consistent with each other.
|
| (And even that's a contrived test: very few people use
| both an iPhone and Android phone regularly!)
| naasking wrote:
| > 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.
|
| It's not even a single person that has them, but I think
| we have all had the experience of family or friends that
| need assistance with something but they have a different
| type of phone whose organization and workflow is
| completely different because it's native. You literally
| can't help in this scenario without having physical
| access to the device.
| satvikpendem wrote:
| I've genuinely never heard of such annoyances from actual
| users (at least not from most users, who aren't power
| users, and even then, not even from the power users), and
| most cross platform frameworks already hook into the
| native APIs like for the back button, so it'd work the
| same either way.
| CJefferson wrote:
| Out of interest, do you know many seriously vision-
| impared people?
|
| Windows, and Mac OS X in particular, have quite good
| support for accessibility if you use their built-in GUI
| systems, and unified UIs are often (not always, vscode
| and chrome are quite good, for example), very bad,
| sometimes just a black square as far as accessibility
| goes.
| satvikpendem wrote:
| Many cross platform frameworks have good accessibility
| support, not sure what that has to do with native
| platforms, as the cross platform solutions simply hook
| into the native platform accessibility APIs anyway.
|
| https://docs.flutter.dev/ui/accessibility-and-
| internationali...
| CJefferson wrote:
| I didn't know flutter had such good support, and I'm very
| happy to hear about it!
|
| Unfortunately, most cross-platform frameworks have awful
| accessibility support, I've looked at various in the past
| and just found failure after failure. I am now going to
| look harder at flutter.
| kelnos wrote:
| People have multiple devices, sure, but in my experience
| (among non-HN people) it's iPhone+iPad or iPhone+mac
| dominating, with a decent contingent of iPhone+Windows,
| and rarely Android+Windows. (This is of course US-
| centric; the iPhone is more popular as a mobile platform,
| and that often entices people to buy into other aspects
| of the Apple ecosystem.)
|
| It is _exceedingly_ rare for the multiple devices to span
| the UI toolkits of more than one or two company-platform.
| For people in the Apple ecosystem, they don 't want to
| see something that looks like it belongs on Android.
|
| Regardless, "unified UI" doesn't mean it can't use native
| controls. More important from a UX perspective is that
| controls are in the same places and behave similarly, and
| that the app is organized in a similar manner, plus or
| minus what might naturally change because of differences
| in screen size and input method. And that's another
| useful point to make too: mobile, tablet, and desktop
| experiences are often quite different, and that's normal
| and expected at this point.
|
| Another consideration: it's a lot more difficult to make
| an accessible app when you draw your own custom UI
| controls with your own custom behavior. If you use the
| native UI controls, you get a lot of the accessibility
| features for free, and have to do much less work to make
| sure everything works for people who are vision or
| mobility impaired. From what I understand after reading
| about blind people's experiences on various platforms,
| most companies that do custom UI don't bother, and the
| accessibility of their apps is atrocious.
| amelius wrote:
| Do you hear people complain that __websites__ have
| different aesthetics?
|
| I used to share your opinion but since the web I think it
| is great that designers can have original designs and I
| started to worry about more important things.
| fauigerzigerk wrote:
| I agree. What doesn't get enough attention in these often
| dogmatic debates is that there are some native
| conventions that are hugely important for usability while
| others are mostly irrelevant.
|
| E.g, I have to use a Java app on the Mac that uses Ctrl+V
| rather than Cmd+V for paste as well as other
| Windows/Linux keyboard conventions. This is extremely
| jarring.
|
| Web apps never do that. Browsers are pretty good at using
| native conventions where it matters by default. Of course
| web devs sometimes go out of their way to vandalise the
| browser's perfectly good defaults - e.g. by overriding
| scrolling behaviour.
|
| Surprisingly, some of Apple's own native apps (such as
| Numbers) break platform conventions in ways that makes
| the app extremely inconvenient to use.
| deergomoo wrote:
| The web is interesting because we never had rich
| components provided by the browser to begin with. Web
| applications have always had to draw everything but the
| most basic inputs themselves, and the design of web apps
| has evolved accordingly.
|
| In an alternate universe, where web apps were embraced by
| the platform from the start rather than something people
| had to shoehorn into a document sharing mechanism, and we
| had rich components built-in, then yes I would probably
| be annoyed if people insisted on rolling their own
| versions. After all, I am annoyed when people use a span
| with a click handler instead of a proper anchor tag,
| because it usually breaks middle clicking or opening a
| link in a new tab--a platform convention I have
| internalised and expect to work.
|
| Note this only applies to web apps, not sites. Much like
| how I do not have any problem that magazines don't share
| a common layout.
| dangus wrote:
| I think the problem with the same app following native
| app idioms is that now the support and instructions
| behind that app will have to be different on every
| platform.
|
| E.g., if you have Instagram on your iPhone, an Android
| user won't be able to tell you "just click on this, this,
| then this to change your XYZ setting" because it will be
| in a different place than the Android app if developers
| follow native conventions 100% of the time.
|
| The fact that Spotify or Instagram or any of those other
| platform-agnostic apps look and function the same on
| every platform is a huge benefit to practical usability.
|
| I think the only time when nativeness matters is when you
| have an app that's doing stuff that's closer to being
| "low level" to operating system features. For example, an
| app that performs file system management, I don't want
| that to have the exact same UI on Mac, Windows, and
| Linux, because those platforms have different conventions
| for where things go and how files are represented.
| oneplane wrote:
| In those cases, those app developers aren't doing cross-
| platform development, but are just trying to dump their app
| in as many places as possible. In such a case, why not just
| make a PWA and call it a day? Don't need an app if you
| aren't going to go native, especially with most apps being
| either content readers or CRUD apps anyway.
|
| In most cases, I personally rarely want an app, and I'll
| use a website unless they happen to have created a great
| native experience. And since most apps don't, I don't use
| them, and I don't have a lot of apps as a result.
| ascorbic wrote:
| Because most users have no idea what a pwa is or how to
| install it. They expect to be able to go to the app store
| and install an app.
| oneplane wrote:
| That is exactly the reply I was hoping for. Because that
| brings us straight back to the native issue; users also
| expect the app to work in a way that is comfortable and
| known to them.
| mirzap wrote:
| Developers who think that way have no clue what their users
| want. Most iOS users want a native experience, not
| something else. When I see an app that doesn't have that, I
| quickly lose interest. Having the app look the same on all
| platforms is a dumb idea to start with.
| amelius wrote:
| Are these the same users that prefer websites without
| CSS?
| kelnos wrote:
| Websites and apps aren't directly comparable when it
| comes to this metric.
| Kiro wrote:
| Funny how you are calling people clueless while being
| confidently incorrect. You're in absolute minority.
| kelnos wrote:
| As an on-again off-again (currently off-again) cross-
| platform app developer, I _always_ want my app to look like
| it fits in with the rest of the apps on whatever platform
| it 's deployed to.
|
| As a user, I _hate_ it when some app developer thinks they
| 're cute and wants to skin an app differently or draw their
| own ad-hoc widgets.
| divan wrote:
| Flutter showcase is a disgrace, to be honest. Doesn't
| represent the actual landscape even remotely.
| 8338550bff96 wrote:
| That is good to hear and hopefully gets fixed. It has been
| some years now, but I did use flutter for some toy projects
| and liked using it - I am used to using ReactJS I found
| there was a lot of transitive knowledge coming from that
| background.
|
| Ultimately what dissuaded me from pursuing it for any
| bigger projects is a lack of examples of great looking
| production apps with complex requirements. When I was
| looking, I was seeing a lot of CRUD apps - display a form,
| click an upload button, ect. This was probably 2018/2019
| when I was taking a serious look at it.
|
| All of that is to say: Quality app showcases do matter for
| whether or not devs will trust a solution enough to pull
| the trigger.
| divan wrote:
| I don't know how to fix the showcase problem. With web
| apps, it's easy - just scan HTML, deduce what framework
| is used, and add it to your showcase list. With Flutter
| mobile/desktop apps it's not possible. And there are zero
| incentives for developers to send their apps for
| screenshots. You just ship the release and move on to the
| next tasks.
|
| I also discovered Flutter in 2018, and it kind brought
| joy into UI programming for me. I rewrote all web apps I
| had with Flutter and published a bunch of mobile apps,
| but the coolest thing is that I routinely make apps for
| my own (or my team's) use.
|
| For me, Flutter lowered the costs of UI app development
| so much that I could just spend a weekend making some
| neat, small, practical tool for my own needs. I really
| love making these "private" apps - no need to care about
| all corner cases for all users, no need to polish design
| for all screen sizes/font sizes. Don't even need to be
| released (TestFlight at max, if doing it for a team).
| It's just fun, and I wish more developers could have the
| same experience.
| binoct wrote:
| > I don't know how to fix the showcase problem.
|
| This is trivial for any team that provides a
| framework/platform and spends any amount of time engaged
| with their customers - you know who your prestige
| customers are and you show off examples of the products
| they have built with it. The state of the showcase is
| just reinforcing the points made by the OP.
| nodamage wrote:
| > With web apps, it's easy - just scan HTML, deduce what
| framework is used, and add it to your showcase list. With
| Flutter mobile/desktop apps it's not possible.
|
| Seems like it is: https://play.google.com/store/apps/deta
| ils?id=com.fluttersha...
| ForHackernews wrote:
| I miss the days when applications had their own look and
| feel. If your idea of great design is identical rectangles to
| all the other apps, I guess Winforms solved that use case 20
| years go.
| deergomoo wrote:
| It's perfectly possible to still have a unique look and
| feel without completely forsaking all the platform
| affordances. You get a _lot_ of stuff for free or very
| cheap building using the platform toolkits: stuff that
| people internalise and expect to work without even
| realising it. I think it's a bad idea to throw that all
| away.
| ur-whale wrote:
| > but they don't fit in.
|
| You seem to say this like it's a bad thing?
| deergomoo wrote:
| I think it is, personally. Mostly because common UI
| appearance and paradigms makes software easier to use,
| especially for non-technical users.
|
| But in this specific instance I was referring to OP's claim
| that it's impossible to identify many Flutter apps, which I
| dispute.
| satvikpendem wrote:
| I think people might be talking past each other on this
| issue. If you are on one platform only, then yes having
| apps behave the same is nice for muscle memory. However,
| if you're using multiple devices and platforms, then I
| want Slack to work the same regardless of device, I don't
| want iOS native navigation on the iPhone and Windows
| native navigation on the laptop.
| lawgimenez wrote:
| On Android you can also tell the way the list scrolls.
| Especially on devices, 2-3 years older.
| deciplex wrote:
| If you're referring to the increased scroll speed with two
| fingers issue, that was patched within the last year.
| lawgimenez wrote:
| Unfortunately, not talking about that.
| Capricorn2481 wrote:
| Don't elaborate or anything.
| satvikpendem wrote:
| I think they're referring to the extra frame of latency
| when scrolling on Android. But then again, I've literally
| never heard anyone complain about that, I honestly don't
| think anyone notices, I believe the GitHub issue had to
| use a slow motion camera to even capture the issue.
| tjpnz wrote:
| You'll notice it on higher refresh rates.
| izacus wrote:
| Sorry, but do you really develop your software as a
| professional engineer based on "I heard X from few
| people"? With all the bias and filtering your brain does
| for this kind of "metric"?
| satvikpendem wrote:
| Do you not? Engineering is a tool for solving human
| problems. If humans don't have a problem, then there's
| nothing to solve. Engineering is not the end in itself
| but the means to an end.
| p_l wrote:
| Just like a lot of the "web application packaged as mobile
| app" frameworks did in the past, except with ugly iOS styling
| that also completely mismatched the expected navigational
| patterns.
|
| What's worse, there are new applications with custom look and
| feel that do the same navigational sins _today_
| dwaite wrote:
| > 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.
| nottorp wrote:
| > the underlying platform UX and draws to a canvas
|
| Frame buffer? Canvas is the javascript term.
| Nekit1234007 wrote:
| Flutter uses canvas when targeting the web. (At least it
| was the last time I looked at it years ago)
| nottorp wrote:
| Canvas is the javascript name for writing directly to a
| frame buffer :)
|
| There is a world outside the browser. For now.
| tauntz wrote:
| It's not specific nor limited to javascript. The term
| "canvas" in this context is much older and seems to be
| used across many platforms.
|
| Random examples from the (desktop) Java/Android/iOS world
| where the same semantics is used:
|
| https://docs.oracle.com/javase/8/docs/api/java/awt/Canvas
| .ht...
|
| https://developer.android.com/reference/android/graphics/
| Can...
|
| https://developer.apple.com/documentation/SwiftUI/Canvas
| satvikpendem wrote:
| Typically people just make the app look and work the same
| in all platforms, like how you might expect a responsive
| web app to be like; no one is implementing Notion with a
| platform specific UI, for example, using Apple stuff on
| Apple devices or Windows stuff on Windows devices.
| 946789987649 wrote:
| Sounds a bit like plastic surgery... you only notice the bad
| ones.
| zaphirplane wrote:
| Over time I have become convinced that the, fit in argument
| is not something that actual users care for.
|
| The sometime subjective aesthetic reasoning doesn't mean the
| application can't succeed. office ribbon is an example
| graemep wrote:
| I think you are correct, but I think your example is a bad
| one. Most people do not have a realistic (their employer
| will use it at work, it even occurs to them that they could
| use something else) alternative to MS Office so will use it
| whatever MS does.
| signal11 wrote:
| A lot of users _do_ care for fit and finish, but stick
| around with crappy UI because it's not worth rage-quitting
| over.
|
| They do move when better UI + same-ish functionality comes
| along.
|
| The one sort-of exception to this is Enterprise Sales,
| where the people buying the software don't always use it.
| But even there, corporate purchasers do get flak in annual
| reviews / feedback cycles for especially crappy enterprise
| software -- so even there, especially crappy UI will catch
| up with you.
| m3talsmith wrote:
| The developer could use the cupertino framework for iOS
| releases, but usually choose not to.
| jamil7 wrote:
| I noticed the SNCF Connect app for France's rail was using it
| in their showcase which explains why the scroll views are so
| weird and busted feeling. They still stutter on a new iPhone.
| As a native iOS developer I'm somewhat biased and a lot of
| people likely don't care but it still feels off to me even
| for apps that use a complete custom design. I hope they can
| optmise away those kind of issues more as it's IMO always
| better to have alternatives.
|
| Side note: Is anyone using Flutter just for Android? I'm kind
| of tempted to try this as dealing with the Android build
| system and packaging is bit of a pain, despite Kotlin and
| Compose being quite nice.
| insin wrote:
| You still have to deal with the Android build system,
| `flutter new` just generates initial config for it and all
| the other necessary metadata (and that config can change
| between versions - I ended up manually diffing the
| generated stuff against a new app every time I upgraded).
|
| At some point I made the mistake of not touching the code
| for too long and upgrading Android Studio when suggested,
| and I was never able to (find the time needed to) get that
| app working again.
| jamil7 wrote:
| Ah gotcha, I thought it was papered over a bit more with
| Flutter's tooling. Good to know.
| jklinger410 wrote:
| > You can't be serious.
|
| Please keep your comments civil
| eternityforest wrote:
| On non-mac platforms material is already everywhere so they
| mostly don't look too out of place.
| Onavo wrote:
| > _Most people don 't realize how many apps written in Flutter
| they use daily, simply because it's impossible to tell._
|
| Flutter implemented its "native" looking UI widgets by
| literally having teams of designers eyeball the native designs
| and reimplementing, starting from drawPixel. This can't be done
| on a volunteer basis alone. Many open source attempts have
| tried this route and failed because they don't have the sheer
| designer resources needed to get there.
|
| https://docs.flutter.dev/ui/widgets/cupertino
| skydhash wrote:
| I'd much prefer they've gone with their own design system.
| People are already used to bespoke ones (web), badly done
| ones just remind me of scammy sites.
| 1oooqooq wrote:
| this so much.
|
| but flutter was probably sold internally as a trojan into
| ios dev experience. the carrot was multiplatform... and to
| sell it they needed to at least market that it was "true
| multiplatform" with native look. which is ironic since they
| go out of their way to make it pain to build to both in the
| same app
| dwaite wrote:
| > Flutter implemented its "native" looking UI widgets by
| literally having teams of designers eyeball the native
| designs and reimplementing, starting from drawPixel.
|
| Those widgets are then stylized wrong on every subsequent
| platform release, such that your iOS 18 phone might seem like
| it is launching an iOS 7 app.
|
| IMHO if your goal is to have a cross-platform codebase act
| like the underlying platform, React Native is a much better
| approach. Flutter exists for people who don't intend to take
| on the effort of targeting platforms with specialized
| behaviors.
| faizmokh wrote:
| > having teams of designers eyeball the native designs
|
| No wonder it's not accurate.
| zachrip wrote:
| Which flutter apps do I likely use?
| reaperducer wrote:
| According to its web site, eBay, New York Times, Square,
| American Airlines.
| favorited wrote:
| Specifically eBay _Motors_ , which is a standalone app.
|
| https://flutter.dev/showcase/ebay
| zachrip wrote:
| I'm suspicious of those because it shows an ebay logo but
| then shows an app I've never heard of or used...is this the
| same for all the other logos? Where does NYT use flutter?
| orta wrote:
| Flutter web publicly launched with a NYT prototype
| https://verygood.ventures/success-stories/new-york-times
| mh- wrote:
| I recognize that as the NYT Games (formerly NYT
| Crossword) app.
|
| It has some very annoying non-native behavior, like
| bringing up the text selection/highlight menu in
| inappropriate places (in a word puzzle with no selectable
| text).
| milch wrote:
| Or the non-native keyboard ... honestly made me stop
| using it altogether
| mh- wrote:
| Yeah that's really annoying too.
|
| I've solved thousands of daily crossword puzzles in that
| app.
| timsneath wrote:
| I don't believe NYT has used Flutter for some years.
| nodamage wrote:
| Listing eBay and NYT seems pretty misleading when it's
| actually eBay _Motors_ and NYT _Games_ and not their
| primary apps.
|
| I can't tell if the same applies to Square or American
| Airlines but I would not be surprised.
| sureglymop wrote:
| 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.
| kevincox wrote:
| 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.
| kelvinjps10 wrote:
| Hacki a nice frontent for havkernews
| nox101 wrote:
| 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....
| wruza wrote:
| This. They can have all the deviations they want, but "input
| core" _must_ be native. If a framework ignores it, users will
| notice and frown upon it immediately.
|
| When flutter came out publicly, first I thought no way it can
| get away with custom everything. But it turned out some
| developers don't care about that at all.
| 1oooqooq wrote:
| you know that zero texting apps nowadays use native input
| anyway right? even native apps will implement their own
| input and it's always awful, but the pm needs those style
| previews... (you're still right thought)
| wruza wrote:
| Checked my whatsapp and tg, both use absolutely native
| inputs. The selection handles & menu, the hold-spacebar
| movement, the hold-to-magnify feature on ios is the same
| as everywhere else. If that's not native, they did a
| great job for nothing.
|
| Too lazy to check on android rn, but I recently worked
| with the apps/chats on it and entered text, it didn't
| feel different.
| saagarjha wrote:
| In fact the input field is one of the few native UI
| surfaces in the Telegram app.
| 1oooqooq wrote:
| it's not a native widget. you can type styles on whatsapp
| which is not possible on native input.
|
| whatsapp is the poster child of this technique btw.
| wruza wrote:
| Styles are possible with native text view, otherwise we
| couldn't have fonts and colors and contenteditable and
| selection within <p>. I think you mistake "input core"
| with "web input element" here. The core I'm talking about
| is a text cell with characters on it that has no concept
| of own border. Controls like NSTextField, Win32.TextBox,
| GtkEntry - they all have platform text input (and output)
| system underneath. In case of gtk it implements it
| itself, cause X has none. The thing that implements all
| the familiar behaviors of the text input that you know.
|
| So yes, compared to HTMLInputElement these are absolutely
| custom. But for a platform, absolutely native.
| throwaway19972 wrote:
| Do you have an example of a texting app that doesn't use
| native input? This just straight up doesn't seem
| accurate.
| divan wrote:
| I disagree with this so much for two reasons:
|
| 1. I shipped more than five Flutter web apps with actual
| users for a couple of years, and it's been a great
| experience so far.
|
| 2. "Native" web core should burn in hell, and I hope Wasm
| will finally contribute to it. Amount of developers who do
| not realize that "native web" is a typesetting engine from
| 80s with a pile of hacks on top of it, is too large to
| fight the opinion, of course. And yet, as a developer, I
| care about using the right tool for the right task, and no
| amount of browser engine optimization can change the fact
| that XML-based markup language is not the right tool for
| modern performant cross-platforms UIs.
| wruza wrote:
| Native doesn't mean web. I meant just an input as it
| works everywhere on a platform, input core.
|
| Partially agree on the web sentiment, it just lacks a
| proper model, both positioning and styling, for what we
| call apps.
| chrismorgan wrote:
| If you care about the web _at all_ as a target, you _must
| not_ use Flutter. It's awful. They _used_ to have a DOM
| renderer which you could use and everything would be fine,
| but apparently no one used it because it wasn't perfect, and
| they've recently deprecated it and will remove it sooner or
| later--they're doubling down on the pure-canvas direction
| where it's _completely impossible_ to produce a good result.
| And I do mean impossible, design limitations of the web
| platform that in some cases fundamentally cannot be relaxed
| and in others are very unlikely ever to be. With this
| direction, scrolling will _never_ be good, text rendering
| will _never_ be perfect, input and manipulation will _never_
| be acceptable, links will _never_ work properly.
| satvikpendem wrote:
| Flutter Web is for web apps, not web sites, so much of
| those concerns don't necessarily apply. And it's not
| "impossible" simply because Chrome itself runs on Skia
| which until recently Flutter did too, so clearly they were
| able to implement scrolling at least one time correctly.
| chrismorgan wrote:
| > _Flutter Web is for web apps, not web sites_
|
| When you want to draw this distinction: most web apps
| will still suffer heavily for many users if they use
| Flutter. To begin with, few web apps don't use text,
| scrolling, or form fields. Games are almost the only
| thing that may not suffer, or only _barely_ suffer. But
| beyond that: well, that's what they say its purpose is,
| but at least two of the three times I've encountered
| Flutter in the wild on the web, it was inappropriate, and
| frustrating; regular DOM should certainly have been used.
| (The third, I've forgotten what it was. It was probably
| similarly inappropriate.)
|
| Skia is not the bottleneck. The web platform is.
| Scrolling is limited on two counts: 1 what browsers
| expose in events is insufficient to match the native
| implementation (which varies by platform) in scrolling
| amounts, overscroll behaviour, and related things; and 2
| the browser is a compositor, and your code will never get
| access to that layer, because it's _way_ too deep in
| performance-, security- and implementation-detail-land,
| so you'll always be stuck at least _sometimes_ at least
| one frame behind "native", and janky.
| divan wrote:
| Not sure why it's downvoted, I think it's quite an
| important distinction to make. I've heard people saying
| "Flutter is bad for web because it's not indexable by
| Google". And reply "do you expect your app - like a food
| delivery app - to be indexable by Google" if it's run on
| the web?
| account42 wrote:
| Existing food delivery apps are not only indexable by
| google but actively make sure to spam the top google
| results for all possible food related searches. You
| couldn't have choosen a better example to disprove your
| argument if you tried.
| divan wrote:
| I think you're talking about AdWords contextual ads paid
| by the food delivery companies, not about Google indexing
| apps.
| account42 wrote:
| You may think that but that doesn't make it reality.
|
| I think you are grasping at straws because you know you
| are wrong.
| jwells89 wrote:
| I can't imagine using Flutter for desktop development if only
| because like most newer UI frameworks, it's mobile focused and
| doesn't come with important desktop widgets like
| tableviews/datagrids and treeviews.
| loic-sharma wrote:
| two_dimensional_scrollables is a first-party package by the
| Flutter team that implements table views and tree views:
| https://pub.dev/packages/two_dimensional_scrollables
| divan wrote:
| There are plenty, though, and they work amazingly well on
| desktop: https://pub.dev/packages/syncfusion_flutter_datagrid
| jwells89 wrote:
| Depending on widgets external to the toolkit is a no-go for
| me. It unnecessarily bloats dependencies and there's a high
| risk of the widget eventually being abandoned.
| divan wrote:
| I totally get your sentiment and also try to instill the
| culture of "add dependency only if it's absolutely not
| possible to avoid it". For small widgets, I often just
| copy the code into my tree. And I absolutely hate when
| library authors break API for no reason (something that
| the Dart ecosystem inherited from the web one).
|
| But limiting yourself only to standard widgets seems to
| be extreme.
| jwells89 wrote:
| It's not that I limit myself to standard widgets, it's
| more that the toolkits I use have a full enough
| complement of standard widgets that any custom needs are
| easily met by tweaking one of those.
|
| In UIKit for instance I typically build custom buttons by
| subclassing UIControl, which gives a nice "blank slate"
| control that has all the basics of interaction covered
| without the specifics of UIButton. It's easy to build a
| custom button that's as well-behaved as a standard
| UIButton that way.
| satvikpendem wrote:
| Canonical is contributing to desktop and is using Flutter for
| a lot of their desktop components now.
| account42 wrote:
| Given Canonical's record that is only further reason to
| stay far away from it.
| eternityforest wrote:
| Canonical is great when they're following established
| standards, the problem is when they invent in house tech.
| eternityforest wrote:
| Tableviews are pretty niche and tree views mostly get used
| for files, so I'm fine not having either in apps that aren't
| about managing lots of data.
|
| I like headers and sections more that tables for most things
| anyway.
| jwells89 wrote:
| Depends on what's being developed, I guess. No tables/trees
| is probably ok for a lot of lighter end-user sorts of apps
| but doing without them for many desktop-first apps and
| utilities would be rough. Desktop file managers, media
| library apps, and email apps for example would be quite a
| lot less useful without multi-column tables at the minimum.
| eternityforest wrote:
| I almost never use email on anything but my phone, and
| Gmail doesn't use a table. They do some tree stuff for
| the conversation threads, but conversation threads are
| obnoxious anyway and I have no idea why anyone likes
| them, they don't reflect face to face conversations well
| and always create mistakes where someone forgets to reply
| to all.
|
| I've replaced a lot of tables in my apps with modal
| dialog UIs, it's nice to have them behave exactly the
| same on mobile and web, to not have any risk of mistakes
| due to filling in a box on the wrong row because the
| label is too far from the box, and it's just generally
| more pleasant for us non-ADHDers without very good native
| multthreading support in our minds.
|
| Android style UI is all about encapsulation and reducing
| the mental context window to the bare minimum, and it
| really makes a lot of desktop stuff look pretty clunky
| and confusing by comparison.
|
| VS Code would definitely suffer a lot without the sidebar
| tree view though, and it does seem like a lot of people
| prefer the more open instant access to everything that a
| table provides, rather than clicking through dialogs.
| jwells89 wrote:
| This is something I have a difficult time agreeing on. I
| expect a certain level of information density and
| configurability in desktop UIs, which shoehorned mobile-
| style UIs don't do well to provide. Deep modality is also
| a peeve; on desktop there's often no benefit to burying
| things in mulitple layers of modals -- within reason, the
| most important things should never be more than one click
| away and great consideration should be put into putting
| upwards of 2 clicks between the user and their
| destination.
|
| That said, I do think it's fine to have a simplified
| mobile-ish UI as an _option_ , but it shouldn't come at
| the cost of more classical desktop style layouts for
| those who can leverage them well.
|
| As a sidenote, this is part of why apps like the mac
| version of Apple Mail and Thunderbird have a considerable
| number of hardcore adherents, particularly among power
| users.
| crossroadsguy wrote:
| 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)
| 1oooqooq wrote:
| the responsiveness and consistency is fine. ente just have
| weird design choices but that's a matter of taste
| divan wrote:
| Do you just assume that Flutter is the same as typical other
| "hybrid/non-native" crap?
| heavyset_go wrote:
| > _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.
| lopatin wrote:
| > 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.
| kevincox wrote:
| > can squash by putting more resources into Flutter
|
| So success?
| okwhateverdude wrote:
| > nice little coup attempt that Google can squash
|
| I mean, Google could also punt and let Flutter die. They've
| killed greater investments for less.
| madeofpalk wrote:
| What are some examples of good 'impossible to tell' UIs built
| with flutter on desktop or web?
| flawn wrote:
| Google Wallet & Google Classroom
| chrismorgan wrote:
| > _Google Wallet_
|
| Do you mean https://wallet.google/, which says "only
| available on Android"?
|
| Your parent comment asked for "on desktop or web".
| divan wrote:
| 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 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.
| ForHackernews wrote:
| > 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, just make that. Stop
| trying to break the web.
| divan wrote:
| > 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.
| ForHackernews wrote:
| It didn't "just happen" the early architects of the web
| designed a system to make it easy to share and remix
| content and subsequent generations of companies and their
| UX designers have so far failed to fully claw back user
| freedoms.
| satvikpendem wrote:
| Content as in significant text and media content, not
| selecting the text off a button element. I agree, seems
| like this is just a post facto rationalization of a
| mistake from a system that was originally designed for
| content, not application functionality.
| ForHackernews wrote:
| Maybe I need to copy-paste the text from the buttons so I
| can accurately ask which one I should click. Maybe I have
| a screen reader that needs to access that text to read it
| out loud. Maybe I want to copy-paste the UI elements into
| a translation program so I can understand them in my own
| language. Maybe I want to copy the UI text so I can make
| a better re-implementation of your site...
| satvikpendem wrote:
| Those are some of the most niche use cases I've ever
| heard, and that is stretching it even on HN, much less
| anyone in the non HN bubble. Things like screen readers
| work just fine on non browser apps that don't have
| selectable text, for example.
| madeofpalk wrote:
| What are some examples of good 'impossible to tell' UIs
| built with flutter on mobile?
| divan wrote:
| Bolt [1] and Bolt Food [2], for example. One of the apps
| is built with Flutter, another one is native. Can you
| tell which one and explain how you noticed it?
|
| https://www.youtube.com/watch?v=3X8COSnscbQ [1]
|
| https://www.youtube.com/watch?v=VOgrdt5WQcI [2]
| kbcool wrote:
| LOL Bolt is a React Native shop.
|
| Just Google "bolt react native" they have jobs and
| articles about their usage but also any library inspector
| will tell you that.
| divan wrote:
| Nope, one of them is Flutter (I know team PM personally).
| Which one?
| kbcool wrote:
| Dude. They're even on the React Native showcase page.
|
| I don't know what to say but you're massively mistaken.
|
| Uber use React Native too BTW. Lots of other big tech
| companies also, I don't know of any that use Flutter in a
| big way. Just some toe dipping
| satvikpendem wrote:
| Bolt Food is on the showcase page, not Bolt itself, which
| would be odd not to add both if indeed they were both RN,
| so seems like one is RN and the other is not, which is
| basically what the above commenter was saying initially.
| None of what you said really invalidates their point,
| because again if you search for RN jobs for Bolt, why
| would you not also assume it's for the one on the
| showcase, ie, Bolt Food? Bolt is the company name after
| all, not just the app name.
| account42 wrote:
| Selecting everything is what every UI toolkit should
| support. In the 90s it may have been acceptable to show an
| error MessageBox with a non-selectable message but it
| shouldn't be acceptable today. What needs to be selectable
| is defined by users not developers and the union set of
| those requirements is "everything".
|
| Browser zoom also only ever breaks if you are fighting the
| Browser's layout engine instead of embracing that. Just
| don't do that and it works fine.
|
| Of course most web "apps" shouldn't be apps in the first
| place but if they must be "apps" at least stop
| reimplementing a crappier version fo the native browser
| functionality.
| awinter-py wrote:
| it's possible to tell
| chipdart wrote:
| > 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.
|
| Electron-based apps are also everywhere and they are through
| and through bad and a step backward. I would take caution to
| not do appeals to authority. I would extend this assertion over
| any javascript-on-a-webview-based GUI framework. Awful concept
| from start to finish.
|
| The fact that you failed to give any specifics to support your
| superlatives leads to suspect that the comparison with Electron
| is well suited.
| divan wrote:
| You are right, sheer popularity is not the argument for the
| quality of the framework. I wrote those two sentences
| separately for different purposes (the second was more of a
| reflection of other comments in the thread. I should've put
| it in a separate paragraph or elaborated more.
| zigzag312 wrote:
| Not OP, but what makes Flutter good IMO is drawing directly
| to native canvas, a very good hot reload implementation and
| AOT compilation.
|
| There are three ways cross-platform UI frameworks draw UI. 1)
| wrap platform controls, 2) use webview or 3) use low-level
| graphics API.
|
| Option 1 has to design controls to cater for the lowest
| common denominator. And there is a higher chance that an OS
| update might break things that in options 2 or 3. Being based
| on wildly different APIs (for each platform) increases
| complexity of creating and maintaining custom controls.
|
| Option 2 has to render UI through a high-level declarative
| language made for documents.
|
| Option 3 uses same APIs as native UI frameworks use. It's
| basically alternative implementation of an UI framework.
| Downside is that it has it's own look and feel, which is
| mostly an issue, if native UI framework is more polished.
|
| Flutter, being option 3, is more similar to a game engine,
| than to Electron. Low-level graphic APIs maintain good
| backwards compatibility, so OS updates don't affect the
| framework much. Less maintenance is needed.
|
| Good hot reload makes use of XML unnecessary and allows to
| declare UI in an actual, more powerful programming language.
| Overall, this removes another layer of complexity. (MS take a
| hint)
|
| AOT compilation enables fast startup times and less pauses.
| Which is good as end users are opening and closing
| applications all the time.
| poulpy123 wrote:
| > Flutter is the best thing that happened to UI development
| since Qt.
|
| Which programming languages have a good developer experience
| with flutter beside dart ?
| rdsnsca wrote:
| None, Flutter is dart only.
| thiht wrote:
| > 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.
| dominicrose wrote:
| After using Typescript and React, building a front-end with
| Flutter is boring, as are other Google frameworks (Angular,
| GWT).
|
| Maybe if you've never worked with TS/React and more generally
| HTML/JS/CSS, then it may be OK for some use-cases.
| palata wrote:
| > That's 50 people serving the needs of 1,000,000. [...] 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.
|
| Ever heard of e.g. curl? Because a billion users use your
| software does not mean that you have to talk to a billion users.
| IshKebab wrote:
| Curl is easily 1000x simpler than Flutter and has existed for
| many times longer. Not really comparable.
| palata wrote:
| Exactly: the number of users is just not a good way to
| measure this.
| kreetx wrote:
| IMO, the entire number counting argument is beside the
| point. Workable dev count/user count ratio varies depending
| on circumstances. A better way would have been that the
| "in-house Flutter team is slow to accept outside
| contributions so I'm forking it".
|
| EDIT: minor wording
| eviks wrote:
| Does curl have any semblance of customer support?
| ibero wrote:
| | How many Flutter developers exist in the world, today? My guess
| is that it's on the order of 1,000,000 developers. The real
| number is probably higher, but one million should be reasonably
| conservative.
|
| one million flutter developers? that does not make sense to me at
| all (by orders of magnitude). does anyone know any metric to
| validate this? i am shocked if it's true.
| britannio wrote:
| The data is supposedly there:
| https://news.ycombinator.com/item?id=41975320
| munchler wrote:
| > The team can't fix the bug without information from me, and
| it's been too long for me to provide information to the team.
|
| Ugh. I feel like developers should already know this, but I guess
| not: If at all possible, please, please, please include a solid
| reproduction case when reporting bugs. That way you don't have to
| remember anything about it. (This is also pretty much the only
| way you can be certain that the problem isn't actually due to
| your own error/misunderstanding.)
| briandear wrote:
| Really not a fan of the flutter concept. "One codebase?" Ok, so
| how does that make a great iOS app that takes advantage of the
| full device? Basically coding to the least common denominator.
|
| Hire a Swift person. Hire an Android person, and build things in
| a way that gets the most of of the device. Otherwise, what's the
| point of an "app" in the first place. Can use a website if "one
| codebase" is a goal.
| transitivebs wrote:
| Where's the actual repo for the fork?
|
| It's not linked to anywhere and not listed under the flutter
| github org...
| brunorsini wrote:
| Anyone else experiencing deja vu from the days of transitioning
| from Angular to Angular 2?
| divan wrote:
| No. Angular 2 wasn't a drop-in fork for Angular 1.
| corytheboyd wrote:
| I like Flutter, and Dart for that matter, but I lost inspiration
| to keep going because it felt like I was learning something
| deeply that will be dead in a few years. Why not just learn Swift
| instead? Or if it must be cross-platform, Qt?
|
| Is this the right stance to take? I just want to pick a desktop
| app development stack that has some staying power, and isn't
| riddled with quirks.
| mardifoufs wrote:
| I guess flutter web is the "hook" because it promises a "true"
| cross platform stack, even though imo it is still very lacking.
| On the other hand, QT on mobile (iOS, android) is also a bit
| weird, and comes with lots of restrictions and gotchas. And it
| basically does not have any support for web apps (except for
| some super recent, very experimental wasm platform support,
| that would probably be even worse than the "app on canvas"
| experience that flutter web offers)
| guluarte wrote:
| I highly doubt there are 1,000,000 flutter developers
| synergy20 wrote:
| This is a welcome fork. Still for me, flutter is not web platform
| friendly by design(e.g. javascript) and that's the reason I
| stopped using it and switched to react-native +
| electronjs(react), they seem more reliable and production ready,
| plus this approach is totally web friendly.
| gavindean90 wrote:
| I had the same thought and ended up learning swift and out had
| been great.
| stux wrote:
| 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.c
| om/flutter/flutter/pull/128910#issuecomment-...)
|
| - 40+ PRs from 2019
|
| So, disgruntled ex-employee?
| deskr wrote:
| 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.
| DaiPlusPlus wrote:
| If existing tests are failing then how are they accepting any
| PRs at all?
| bmitc wrote:
| 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.
| hersheyhersh wrote:
| 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.
| stux wrote:
| > Flutter founder here.
|
| Given that the literal founder of Flutter is in this thread
| using this introduction multiple times, it's kinda hard to give
| you the benefit of the doubt that you honestly just meant "a
| founder using Flutter".
| concerndc1tizen wrote:
| I remember the name 'hersheyhersh' in some Flutter context.
| But the account has zero activity, so it's questionable that
| this is a Flutter founder.
| hersheyhersh wrote:
| I am not the Founder of Flutter. Sorry. I am a founder
| using Flutter. Just skimmed the comments and saw the phrase
| used multiple times and thought those were founders using
| Flutter, and thought to use the same term.
| wstrange wrote:
| I believe he means "a founder who uses Flutter". Poor
| wording, but I don't think it was intentional.
| hersheyhersh wrote:
| Thank you.
| lopatin wrote:
| What was that phrase about not assuming malice when you could
| assume something else?
|
| Most likely GP saw the actual Flutter founder announcing
| themselves as "flutter founder" and assumed it was a common
| phrase for founders who use Flutter lol.
| hersheyhersh wrote:
| That is seriously what happened. I didn't realize the
| actual Flutter authors were here using that phrase. Because
| it sounds odd to say founder for author of a software
| package. I genuinely thought those were Founders using
| Flutter.
|
| Anyway, my bad.
| hersheyhersh wrote:
| I meant to say, "Founder using Flutter here".
| nprateem wrote:
| Nice. Tesla founder here BTW.
| flakes wrote:
| Who is "we" in all of this?
|
| Not even visible on the github org https://github.com/Flutter-
| Foundation
|
| > This organization has no public members. You must be a member
| to see who's a part of this organization.
| yellow_postit wrote:
| Guess Flock is free to use now that Google abandoned their other
| project named "FLoC"
| mdaniel wrote:
| 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/rele
| ases/stable/macos/flutter_macos_3.24.4-stable.zip <
| content-length: 1575089988 (nod)
| eseidel wrote:
| Would you recommend a different distribution mechanism? The
| Apple binaries are all signed (in accordance with Apple
| policies), and the team has historically invested significantly
| in supply chain security. e.g. (a now 2 year old article)
|
| https://opensource.googleblog.com/2022/09/flutter-slsa-progr...
| mdaniel wrote:
| I'm in the camp of "if I can't build it, then it's not open
| source" so https://github.com/Homebrew/homebrew-
| core/blob/d314f3ebba9e7... is a good start, but there is no
| .../f/flutter.rb although there is https://aur.archlinux.org/
| cgit/aur.git/tree/PKGBUILD?h=flutt... but I haven't been
| soaking in the AUR ecosystem long enough to be able to port
| it to Homebrew
|
| All those words to say that if there was a
| .github/workflow/release.yml showing the steps required to
| cook a release artifact that would be the best(?)
| documentation since it is kind of like a Dockerfile in that
| it's computer executable but mostly human readable
|
| I don't mean to poo-poo all the "supply chain security"
| effort, but you have to recognize that right now it's "trust
| me, bro" since https://github.com/Homebrew/homebrew-
| cask/blob/27c351ccb59fb... does check the sha256, and good
| for them, but gives me no way to trace back to any file in
| https://github.com/flutter/flutter/tree/3.24.4
| cageface wrote:
| 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.
| throwaway032023 wrote:
| Absolutely true. It's so much easier to upgrade dependencies
| and if it works / most likely works. We had a small UI
| regression in a very large app and that hadn't been touched
| in 1 year.
| iml7 wrote:
| 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,
| BlursedTarot wrote:
| "Fear not little Flork..."
| delduca wrote:
| My bank uses flutter (nubank in Brazil) it have a lot of issues
| and never it worked fine on iPhone mirroring, which is a pain.
| 1st1 wrote:
| > 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 weird exercise. Python, for example, is a #1/#2
| language in the world and there's only 50 active core devs, 90%
| of which don't even work on Python full time. Somehow we make
| that work.
| malkia wrote:
| Python is an engine, flutter is the whole car.
| wruza wrote:
| I doubt that complexity of a language is comparable to that
| of a widget library. After the text input cell and scrolling
| window it's basically dumb geometry/drawing code all along.
| vineyardmike wrote:
| Flutter has its own language (Dart) which I suspect is
| included in these stats.
| brabel wrote:
| The Dart team is separate from the Flutter team, though
| they do interact as Flutter is now the primary use of
| Dart and as such, influences what is worked on in the
| Dart team.
| DeathArrow wrote:
| It's much harder to to implement a language in a proper way
| than writing a widget library.
|
| But that hardness comes from the level of knowledge one
| must have in different fields such as compiler theory,
| cathegory theory, hardware, beside classical computer
| science and coding.
|
| To write a widget library you just have to know how to code
| and have some experience.
|
| That being said, the amount of work for implementing a
| widget library might be higher, but is less qualified work
| being done.
|
| I dabbled in computer language theory and compilers and
| it's hard. I have no issues reading source code for widget
| and GUI libraries.
| FpUser wrote:
| The code behind "intelligent", performant and scalable
| Tree/Greed widget can be quite big and complex and include
| concurrent/parallel code.
| lolinder wrote:
| If Flutter is a car, Python is at least four different models
| of car, plus three models of light truck and one airplane.
|
| The scope of Python's standard library is just enormous.
| malkia wrote:
| true, but still - these libraries can be updated
| independently, one from each other - with a framework,
| things have to be orchestrated.
| lolinder wrote:
| In general in PLs this is not true--the standard library
| is usually very carefully designed and all of its
| interactions are well-considered--but Python's libraries
| do seem to be more independently-updated than most.
|
| Even so, isn't that an argument for a smaller, integrated
| team for the framework, rather than a large one made of
| ~1000 volunteers? A tightly-knit framework is much more
| likely to suffer from too many chefs than a disparate
| collection of library functions.
|
| Between the parallelization problems inherent in a tight
| framework and the fact that its total surface area is
| _also_ smaller than a PL that 's maintained by about the
| same number of people, it sure doesn't sound like
| Flutter's problem lies in developer headcount.
| DeathArrow wrote:
| And Python is written in C, unlike Flutter which is written
| in Dart.
| zigzag312 wrote:
| Flutter engine is mostly written in C++.
|
| Other parts are written in Dart like you said.
| joezydeco wrote:
| Like a Fisker Ocean?
|
| Launched, abandoned. Scammed again.
|
| When are you all gonna learn?
| malkia wrote:
| Heh, as long as the ocean does not cause them to burn -
| https://jalopnik.com/more-than-a-dozen-fisker-karma-
| hybrids-...
| DeathArrow wrote:
| Then Django or Pytorch are cars, too.
| rvnx wrote:
| "Flutter team members don't actually use Flutter." (as per the
| website).
|
| This could explain a lot.
| kllrnohj wrote:
| Very rarely do the people working full time on a
| framework/tool also use that framework/tool in a non-toy
| setting. They aren't working two full time jobs after all.
| emptysongglass wrote:
| Always, always, dogfood what you produce. The number one
| way devs cease making products people care to use is by not
| using what they make.
| deadmutex wrote:
| I think there should be a distinction here. E.g. if you
| work on a browser, possibly implementing parts of image
| loading, or javascript parser, etc.
|
| Are you consider a dogfooder if you use the browser? or
| do you need to lots of write Javascript yourself, etc. to
| be considered "a user of your product"?
|
| Typically, these are two different sets of people.
|
| So, I don't buy the "always, always" part
| wink wrote:
| I suppose this problem is timeless, back when I was
| active in the PHP community it was a long-running joke
| that people who "graduated" to committing to the actual
| php source (in C) were not doing web development work
| anymore. And I suppose it was actually true for the
| majority. On the other hand, designing language features
| wasn't really related to using it for web work.
| robertlagrant wrote:
| I'm a man who once made medical software for pregnant
| women. There's no point being dogmatic.
| Ragnarork wrote:
| I'm sure all those devs working on fighter jet's software
| would love to but alas...
| kllrnohj wrote:
| Dogfooding doesn't mean you know how to build it. Take
| for example the graphics engineers on Unreal Engine. They
| almost certainly know how to fly around test zones or
| make stress scenarios, but they aren't going to be
| building large, detailed, open world maps like will be
| seen in the next Cyberpunk or whatever. And it's not
| reasonable to expect that of them, either.
|
| Nor are the people doing UI work in Blender going to be
| able to make Big Bunny.
|
| Nor are the people working on fusion360's parametric
| system going to build complex mechanical-fluid simulation
| scenarios.
|
| Flutter is simpler than those, sure, but even in that
| world you have people that do nothing but fonts & text
| for their entire careers. They'll know how to do text
| stuff in flutter, but they'd be lost if you demanded they
| make a tiktok clone.
| chipdart wrote:
| > 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.
| beautron wrote:
| I think the experience of building something atop a
| framework should absolutely have bearing on how to build
| the underlying framework.
| szundi wrote:
| Commenters point is that this is normal
| ZiiS wrote:
| But not necessarily optimal.
| chipdart wrote:
| > I think the experience of building something atop a
| framework should absolutely have bearing on how to build
| the underlying framework.
|
| You'd be wrong. If your job is maintaining a framework
| then your focus is on internal details, and how the
| framework is used would be limited to your concerns in
| putting up test sets.
|
| Believing that working on a framework gives you
| equivalent or even similar experience to using said
| framework in professional settings is a kin to believing
| that all mechanics are excellent drivers just because
| they work on cars.
| JodieBenitez wrote:
| Django comes to my mind here. The people behind the
| framwork had real experience and needs in web
| publication.
| swiftcoder wrote:
| 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
| dietr1ch wrote:
| Seems to me that as projects mature they require less effort
| too. It's hard to account for that since
|
| Python started in 1989, it's older than Linux and it has a more
| narrow scope.
| brainless wrote:
| Python doesn't have a narrow scope. At least compared to
| Flutter. It's in so many places, from Linux installers, to
| medical, aerospace, math,... and finally the web (which is
| probably what we hear about the most).
| FredPret wrote:
| But those are modules added on by developers other than the
| 50 core devs.
| lolinder wrote:
| The standard library alone has a huge scope which
| _includes_ a (mediocre) GUI toolkit.
| dietr1ch wrote:
| I did not meant to start a pissing contest, I thought the
| biggest idea was that Flutter isn't 35yo and because of
| it, it's more likely to drastically change, and in a fast
| way too.
| kevin_thibedeau wrote:
| It includes another scripting language with a GUI
| toolkit. The Python part is just a shallow wrapper over
| third party code.
| pjmlp wrote:
| If only some homegrown GUI toolkits were half as good as
| Tcl/Tk.
| WD-42 wrote:
| Have you seen the python standard library? It ain't
| JavaScript kiddo
| zX41ZdbW wrote:
| I have statistics about real team size behind open-source
| repositories, and it is exceedingly rare to be larger than 50:
| https://play.clickhouse.com/play?user=play#U0VMRUNUIHJlcG9fb...
|
| For comparison, my open-source product has around 20..30
| according to the monthly stats (I want these numbers to be
| higher, though):
| https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvU3Rhc...
| eskibars wrote:
| This is significantly undercounting in at least several cases
| I know of. e.g. I was employed by Elastic and Kong and in
| both cases, the number of developers employed by the company
| to work on these projects was several multiples the size
| reported here
| eskibars wrote:
| Ah, I now see why: I hadn't really looked at the query, but
| now that I have, here are some of the problems:
|
| 1. Using median is a problem for many projects because many
| often start off (sometimes for years) with only a few
| developers before they really take off. The median() number
| for Elasticsearch was 28, but the max() is 49, which I
| suspect is closer to the current number.
|
| 2. Not everybody uses a pull request flow, and not everyone
| working on a project is a developer. You could have product
| managers, technical writers, engineering managers, etc, all
| working on a project and not opening PRs and you can have
| users just directly adding commits, especially when a
| project is young. The original query here for the kong/kong
| project shows a team size of 6, but if you remove
| event_type = 'PullRequestEvent' and switch to max(), you
| get 33.
|
| 3. Sometimes, parts of the project are kind of "elsewhere."
| e.g. Elastic employed a number of Lucene committers to help
| move Lucene along, Kong employed a number of folks that
| would e.g. commit/maintain OpenResty plugins which got
| incorporated in the build system, the docs live in separate
| repos in both cases, etc.
| alberth wrote:
| Rails has 12 core developers + 5 committers.
|
| https://rubyonrails.org/community
| DeathArrow wrote:
| And 17 users.
| kyriakos wrote:
| PHP Foundation has 10 developers and runs a substantial part of
| the web. 50 developers are definitely the wrong reason to fork
| flutter.
| rurban wrote:
| 50 developers would be definitely a good reason to fork. It's
| way too much. 1, max 2 would be the perfect size.
| pzo wrote:
| 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.
| wink wrote:
| Not sure this is a good comparison because the PHP Foundation
| is "relatively" new and afaik there's no strong correlation
| to "the php development team" besides these people being paid
| and also work on it. PHP had a 20y history before this
| foundation, and the main difference is that it was never
| steered directly by one big company. Zend, yeah, but they had
| influence, they had neither started the project, nor ever had
| a long-stretching majority of people in the important
| positions. (Disclaimer: have not been an active part of the
| project for a couple years)
| billmcneale wrote:
| Yeah... no. The team was recently transferred from the US to
| Germany, the numbers were estimated around 10 engineers.
| dd_xplore wrote:
| Even whatsapp had about 50 members when they were handling
| billion users
| chipdart wrote:
| > Even whatsapp had about 50 members when they were handling
| billion users
|
| I would add that running a service deployed to N regions is
| considerably more demanding and work-intensive than working
| on a releasable software package.
|
| No one working on Flutter is woken up in the middle of the
| night by a pager because a user was not able to install a
| package, to then create a call to pull in half a dozen of
| Flutter engineers.
| wg0 wrote:
| Python's standard library rarely changes except deprecating
| features or new additions.
|
| Underneath - POSIX + handful of Windows APIs for porting it to
| Windows. Cross platform aspect is mostly for the compilers to
| produce the binaries.
|
| Flutter is not Python, PHP or Whatsapp. It has to emulate UI of
| six platforms (Web, Mac, Windows, Linux, Android, iOS) with
| easily 50+ widgets.
|
| Flutter unfortunately is not comparable to a language
| interpreter. The surface area is altogether different.
| DeathArrow wrote:
| > This is a weird exercise. Python, for example, is a #1/#2
| language in the world and there's only 50 active core devs, 90%
| of which don't even work on Python full time. Somehow we make
| that work.
|
| But that leaves Python slow and single threaded.
| broodbucket wrote:
| https://docs.python.org/3/howto/free-threading-python.html
| nottorp wrote:
| But does python use protobufs and monorepos and <insert google
| induced fetish here>?
|
| Maybe they have more time to work on the software because of
| less overhead...
| anonzzzies wrote:
| Python is really not the same as Flutter. Compare Python to
| Dart instead.
| vishnugupta wrote:
| I know this isn't a Apples-to-Apples comparison but antirez was
| the sole maintainer (after creating it) of Redis for more than
| decade[1]
|
| [1] https://redis.io/blog/thank-you-salvatore-sanfilippo/
| agilob wrote:
| I think author put incorrect words into the statement you are
| quoting. Flutter has much less mature environment, UI packages
| look good, but most are hot garbage without even unit tests.
| You can't trust even a single one if it doesn't have at least 5
| active developers. They are drying like flies, no one maintains
| them, updates on time and Dart package manager doesn't help at
| all, makes things worse by having that system of requirements,
| versions. I used to work on a side project in Dart and Flutter
| and quickly fall in love, because i was able to write UI and
| backend code super quickly, but about 18 months later, I was
| spending more time maintaining packages that were dropped by
| original authors, updating, fixing conflicts between versions,
| and this was the reason I simply rewrote everything back to
| Java, even frontend to PrimeFaces (: Nothing broke by itself
| since early 2021.
|
| Even Google dropped 3 packages I used in my projects. Including
| Dart Angular, they archived it 7 months after promising in AMA
| they will maintain it for a decade ahead (: They also abandoned
| their flutter charts library, it stopped working in newer
| versions of Dart and community had to fork it, they made like
| 80 forks in a week.
|
| I think this is the problem author is trying to say, not
| Flutter as the framework, but as the general ecosystem that's
| consistent and provides at least somewhat positive experience
| using it. Google is neglecting it.
| crossroadsguy wrote:
| I wish it was just native platforms. Someone needs a faster
| development and reaching the customers, just use web-views and
| then bring on native when you have the money, developers, and
| users. Interacting with non-native apps has consistently been a
| subpar experience without fail.
|
| I'd rather put my money behind KMP by JetBrains. It has a more
| streamlines, practical, and consistent future than flutter, react
| native et al.
| polemic wrote:
| > We're forking Flutter. This is why.
|
| Cripes I wish people would explain who "we" is. "Flutter
| Foundation"? Which is "Flock" but not "Flutter"?
| owens99 wrote:
| I invested quite a bit of time working in Flutter years ago. The
| team overpromised and underdelivered. Felt like it was all
| marketing fluff and I'd been duped.
| yas_hmaheshwari wrote:
| A tangential question: For someone looking to start using React
| Native (targeting both Android and iOS), is Flutter a viable
| alternative in 2024 ?
| owaislone wrote:
| Sounds like Flutter core teams hold contributors to a high
| standard and the Javascript bros can't deal with real Software
| Engineering so they're having a party of their own.
|
| In all honesty, good luck. It might be useful if it never breaks
| compatibility with Flutter.
| nnurmanov wrote:
| Instead of forking popular libs, someone should think how to
| improve OSS model. I think it is wrong when projects with 1mln
| users are not self sustained
| DeathArrow wrote:
| This is a kind of a strange argument:
|
| >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!
|
| It's like claiming that the inventor of penicillin, was
| responsible for billions of people who took pennicilin.
| __rito__ wrote:
| Wrong analogy.
|
| It's claiming that people who _produce_ penicillin, are
| responsible for billions of people who take penicillin.
|
| That's a fair claim.
| DeathArrow wrote:
| I would love Swift to be forked so it becomes more usable outside
| of Apple's ecosystem.
| cellularmitosis wrote:
| What would you change at the language level?
| rererereferred wrote:
| Isn't swift already cross platform?
| https://git.aparoksha.dev/aparoksha/adwaita-swift
|
| Or do you mean the UI Apple uses on top of swift?
| DeathArrow wrote:
| 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.
| cryptos wrote:
| 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.
| skrebbel wrote:
| 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.
| kreetx wrote:
| Ruby has plenty of other applications written in it, it
| definitely doesn't belong to the "one app" language list.
| Alifatisk wrote:
| 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.
| zigzag312 wrote:
| C# port of Flutter would be a dream.
| mdaniel wrote:
| Well, I hear that there's a foundation for it, so: new
| leadership, new rules. I can't tell from the outside how much
| of Flutter/Flock is _deeply tied_ to Dart versus it just
| happens to be a bespoke language because 20% Time exists
| munificent wrote:
| I work on Dart.
|
| Programming language popularity is hard. The network effects
| are absolutely massive. 99% of all programming languages are a
| rounding error away from having zero users. To start to compete
| with any of the big entrenched languages seems to require
| either:
|
| 1. An extremely easy migration story so the language can
| leverage ("parasitize"?) the existing ecosystem of another
| alread popular language. That's C++ for C, Kotlin for Java,
| TypeScript for JS, etc. This is definitely the easiest path to
| success.
|
| But it means your language is significantly hampered in its
| design because of the need to be compatible with the language
| it's building on. This is why C++ is still failing to be a safe
| language and is a sprawling mess. It's why Kotlin has type
| erasure. It's why TypeScript, despite having a fantastically
| complex type system, is still unsound and can't use types to
| compile more efficient code.
|
| 2. A compelling platform or framework that developers want to
| be on so bad they'll learn a new language. Rails for Ruby, iOS
| for Objective-C and Swift. This is the harder path but it means
| the new language is less shackled to a previous one and can be
| more innovative.
|
| Dart took the second path. I agree it would be nice if Dart had
| more pillars shoring up its success than just Flutter and I
| hope we get there one day. But _one_ successful framework is
| more than most newer languages have and you have to start
| somewhere.
|
| I'm obviously biased, but I think Dart is a good general
| purpose language and would work well for many different
| domains. But fighting against the network effects is hard and
| growth takes time.
| wg0 wrote:
| 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.
| jillesvangurp wrote:
| > 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.
| pritambarhate wrote:
| A lot of people here are comparing Flutter with programming
| languages like Python, PHP, etc. It shows how under appreciated
| UI development is and the amount of complexity UI developers need
| to handle. Also UI framework developers are always at the mercy
| of someone else when it comes to their destiny, unlike
| programming language creators which "almost" control it fully.
| Apple, Google, MS all keep changing their OS and browser
| behaviours all the time and cross platform devs need to adapt to
| those things continuously.
| monooso wrote:
| > 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!
|
| Given that you could probably make a similar assertion about any
| popular framework, this doesn't strike me as particularly
| relevant.
| openrisk wrote:
| how are Ubuntu's Flutter integration plans evolving these days?
|
| https://discourse.ubuntu.com/t/refreshing-the-ubuntu-desktop...
| Alifatisk wrote:
| The most important thing I wish this doesn't cause is to divide
| the community, but the article addresses this.
|
| I enjoy Flutter a lot, it would be very sad if it got
| discontinued. An previous employee at Flutter just showcased how
| powerful the framework can be outside it's main usage.
| https://www.youtube.com/watch?v=fU6d81MurTQ
| thiht wrote:
| > How many Flutter developers exist in the world, today? My guess
| is that it's on the order of 1,000,000 developers.
|
| I have a hard time taking this number seriously, that sounds
| grossly exaggerated.
|
| Are there parts of the world where people actually use Flutter?
| Even their showcase is pretty light and a bit deceptive.
| pritambarhate wrote:
| In India Flutter is quite popular. But I also doubt there will
| be professional 1M flutter devs our there. However if we
| include students and hobbyists, then definitely there could be
| a 1M Flutter devs out there.
| lukepighetti wrote:
| Flutter is weak in North America but extremely strong in LatAm
| / Europe / India / Africa
| kbcool wrote:
| It's probably within an order of magnitude but it's really just
| hobbyists, casuals and indies using it.
|
| If you compare it to React Native there probably are more
| Flutter apps published but if you drill down into the top 1000
| on each app store you would be lucky to find more than a few in
| most countries using Flutter whereas React Native definitely
| makes up more than 10%, maybe as high as 30% of non-game apps.
| I know on my phone I have zero Flutter based apps installed and
| almost 20% use React Native in some way.
|
| Source: I'm an app developer so I keep an eye on these things.
| troelsbjerre wrote:
| There are 27.4k forks of the flutter repo. This is just yet
| another one.
| ototot wrote:
| I believe this kind of issues happen in Google everywhere. Not
| sure who to blame for, but it's definitely a severe crisis Google
| is facing. Google should spend time fixing it.
| jmull wrote:
| I think a big problem is that Flutter's approach is very labor
| intensive.
|
| It takes over responsibility for the UI, which is tough when you
| want to be cross-platform. You need to keep up with the native UI
| across all the platforms. (Or, of course, you don't, in which
| case there are gaps, bugs, inconsistency, jank, etc.)
|
| Beyond the UI, it needs to offer integration with platform
| services and conventions, which is another perpetual treadmill.
|
| Not to mention it includes a dedicated language, which takes
| significant effort in its own right.
|
| Add to that, that as a project gets larger and more complicated,
| it becomes harder to change and tech debt builds up.
|
| It's not surprising to me issues are building up. I've got to
| wonder if a fork, while it can move forward in one respect, may
| just be adding more complexity in a project that already has too
| much.
|
| It wouldn't surprise me if Flutter's unmanaged complexity is
| exponential, in which case quadrupling the number of dedicated
| engineers won't move the needle a lot.
| CharlesW wrote:
| > _You need to keep up with the native UI across all the
| platforms. (Or, of course, you don 't, in which case there are
| gaps, bugs, inconsistency, jank, etc.)_
|
| And for the latter, the result is something that mostly does
| what web-based solutions do (with well-understood downsides),
| only with virtually no ecosystem in comparison.
|
| I _do_ think there are opportunities for cross-platform native
| development solutions like https://skip.tools/, which offer an
| alternative to React Native.
| firemelt wrote:
| so we cant sent a pr to flutter or what? I always thought flutter
| is open source
| phplovesong wrote:
| With SwiftUI the gains Flutter had (on ios) are diminished.
| Flutter was way better than ObjC and the nasty layout thing ios
| apps had before, but today swiftui is really good.
| nprateem wrote:
| > If every capable Flutter framework contributor in the world
| regularly contributed to Flutter, that ratio of 1:20,000 would
| drop to 1:1,000.
|
| LOL. That's how to get any investor to stop taking you seriously.
| "The global market for x is $$$bn. If we can just get 5% then..."
|
| How do they plan to get anywhere near 100% of potential
| developers working on it? Most of us here could work on any
| number of projects, but we don't.
| sillyboi wrote:
| It would be great to make good flutter support for embedded
| devices
___________________________________________________________________
(page generated 2024-10-29 23:01 UTC)