[HN Gopher] We're forking Flutter
___________________________________________________________________
We're forking Flutter
Author : alexzeitler
Score : 374 points
Date : 2024-10-28 19:24 UTC (3 hours 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.)
| 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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.
| 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.
| blinding-streak wrote:
| Other anecdotal apps: Google Analytics mobile app.
| BetRivers online sportsbook (one of the largest in the US).
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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/...
| 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.
| 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.
| 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.
| 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
| 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.
| 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.
| KTibow wrote:
| > Communication monoculture
|
| This point seems like a callout to a certain discussion and I
| kind of want to see it
| 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.
| punduk wrote:
| You are proof that dinosaurs are still alive.
| 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.
| 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
| 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
| 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.
| swyx wrote:
| more context on flutter layoffs:
| https://www.theregister.com/2024/04/29/google_python_flutter...
| 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?
| 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.
| 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...
| 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.
| 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?
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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....
| 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.
| 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?
| 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.
| 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"
___________________________________________________________________
(page generated 2024-10-28 23:00 UTC)