How are you measuring this? Like, I would expect someone to want to ship e.g. WPF or something into the browser as their UI toolkit. Why would this fit in 5 MB?
Was pretty surprising to me seeing you embrace the Flutter/CanvasKit plan, take it as a good prototype & support furthering this. The web has always seemed so rich in virtue & principle, gives us so much, and I always would have assumed you saw & got some of that, some of the worth & dignity of the web endeavour. This feels reaching for something so utterly & different & opposed to that shared medium we have, and I cant comprehend how dark one's perception must be to walk the path of abandoning a shared medium for structure-less freeform running code.
I just wish I saw any hope for an standard or interoperability, saw this as a starting point for better or more inter-networking of systems, which has been one of the most brilliant & faith-building-in-humanity things I've been so fortunate to experience the rise of, has been so inspirational. The web has been so obviously & clearly better than everything else in computing by being a medium, has so many virtues by being just self-modylifying documents. It has been stunningly inspirational.
By compare, this feels like walking into the dark. There is no medium of exchange here; just a screen with bitmaps. I want to have some at least vague sense that someone other than developers would be enhanced by a supplantative would-be-media like what is proposed here, want to imagine some real core connective substance that is at least as good as what we have.
I dont see any cognizance or respect from very good long standing web folk like yourself that this kind of effort has huge downsides and risk to users. Rather than everyone sharing a same web kernel, any developer can build their own app kernel & reinvent everything... it's bold & powerful an idea, and I struggle enormously to say (so very conservatively): no, this is a frontier we should not explore. I cherish exploration so much. But this doesnt seem like a medium to me, it doesnt seem like it's anything aside from giving everything we have & share up completely, to embrace a path of starting from nothing, and this time having no common interchange to work forward together with. Users having not a rich document, but just having a shitty low grade unintelligible illegible mess: having only running code. The idea of that, to me, resembles an attack, against the web, against the idea of inter-networking, and against people.
I think my attitude to this stuff evolved after seeing that even with all the work we did with HTML, virtually nobody actually benefits from it.
In theory, HTML is device independent. In practice, we can't even get web apps to work on desktop and mobile, to the point where even sites like Wikipedia, the simplest and most obvious place where HTML should Just Work across devices, has a whole fricking separate subdomain for mobile.
In theory, HTML gives users ultimate control over presentation. In practice, after _years_ of trying to make alternate style sheets a reality, not a single browser in common use even has a UI for them. Nobody cares. A few people with extensions might occasionally make some minor tweak, but that's about it.
In theory, HTML is accessible. In practice, despite decades of advocacy, basic sites fail utterly to be accessible even for basic things because people ignore all of HTML's semantics, they just bolt things together to work for the common sighted able-bodied user and then, _if they are paid enough_, they _might_ just slap on some ARIA attributes to make it vaguely work for people with accessibility tools.
If HTML was all the things we wanted it to be, we designed it to be, if reality actually matched the fantasies we tell ourselves in working group meetings, then mobile apps wouldn't be written once for iOS and once for Android and then once again for desktop web, they'd be written once, in HTML, and that's what everyone would use. You wouldn't have an app store, you'd have the web. You wouldn't follow a link on your phone only to have it redirect to a locally-installed non-web application, it would just stay in your browser. Developers are scrambling to get out of the web and into the mobile app stores.
The reality is that for all of the work that we've put into HTML, and CSS, and the DOM, it has fundamentally utterly failed to deliver on its promise.
It's even worse than that, actually, because all of the things we've built aren't just not doing what we want, they're holding developers back. People build their applications on frameworks that _abstract out_ all the APIs we build for browsers, and _even with those frameworks_ developers are hamstrung by weird limitations of the web.
The parts of the web that have actually delivered are the ephemerality and the security model, the indexability (but only for content, not apps), deep linkability, and the platform-independence. We can keep all those, and throw out the decades of legacy that's holding us back, and we will lose nothing, we will only gain as we unleash the kinds of amazing interfaces that developers can build when you give them the raw bedrock APIs that other platforms already give their developers.
Ultimately, HTML/CSS are too low level tools for most people. We should have had Flutter/AMP like features (sans specific company dependency), right in the browser.
It'd been amazing if people can write <appBar></appBar> and get a consistent appBar that works in different display sizes and comes with accessibility built in; in all browsers. We have done so, in flutter, in iOS, in Android. But why did the browsers never bother? I remember HTML4 feeling dumb and HTML made more sense when I learned about HTML5 proposal. It finally made sense how HTML should progress but then suddenly, after years, everything is still the same?
As for your last paragraph, you mention how web actually delivered in terms of indexability and I'm really disappointed that Flutter (your primary focus right now I assume) is not prioritizing this. Flutter is amazing but it really needs to deliver what web delivered and them some.
Thank you for all of your work, but kindly, you just built the wrong things. No one needed <section> and <aside> they needed <tabs> and <accordion>. The story goes that you grepped the whole web and discovered folks needed section and aside. Why didn't I see them anywhere in my work as a developer? And why didn't they do anything?
Also, the quality wasn't there on what you shipped. The form controls are ugly and non-functional. They needed to be designed, *by designers*! Not everything is an engineering problem.
You only kind of achieved the first part of the extensible web manifesto, and never even tried the second part (paving the cow paths with higher level solutions).
And now the WhatWG is as stuck as HTML/XHTML ever was at the W3C. Maybe even more so. You got so much done, but by force of personality instead of systems that encourage contributions from lots of diverse people. Dictatorships are never going to work without the benevolent dictator. They are inherently unstable systems.
The focus on web components was a decade+ long distraction that didn't take into account the needs of framework authors but instead saw them as a competitor. It was a solution looking for a problem. I interviewed around 30 developers and almost all of them said they either tried WC and didn't like it or hadn't tried it and didn't want to.
* One dev said, "web components only kind of fixes a problem I had 10 years ago."
* Another, at a co that uses WC extensively, said, "web components are a solution to big company problems but know using them will add a year and a half to any development timeline." (paraphrasing, but you get the idea)
* Even a company built around web components said that it wou ld really be better as separate technologies rather then bundled, "give me style scoping separate from templating and slots".
You didn't solve the problems devs find challenging. Frameworks do. The existence of frameworks on the web is a feature, not a bug. And the reasons people use frameworks are diverse, but range from: team dynamics (having one right way to do things, documentation, easier to TL) to literally making it possible for devs to ship the features they are asked to ship. You can't really argue with, "I couldn't build these complex features without frameworks". These devs don't want even lower level solutions.
Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic. When we see frameworks as a core customer/partner for web APIs, things turn out a lot better.
And, now for my childish moment, I told you back then about design systems and the need to support them properly. I told you it was the way folks were going to be building UI soon. You didn't listen. And that set the web back 10-15 years. I literally had to get a job as PM of Web UI at Chrome to correct this mistake. That is happening now. We're shipping container queries, scope, nesting, style queries, state queries and a host of other features devs tell us they need to architect component systems. I know "people are going to be building pages made out of 100s or 1000s of components" probably sounded wild at the time, but that is the thing about listening to your developers, they know what they need. They understand the biggest problems they face. As a PM, every day I assume I don't know what devs need, so I ask them.
HTML is an incredibly accessible technology for nearly any new developer, designer, or content creator to learn in a basic way. That is a strength that should weigh in heavily. We don't need to throw out HTML and CSS... we just need to fix mistakes that were made.
> the kinds of amazing interfaces that developers can build when you give them the raw bedrock APIs that other platforms already give their developers.
They don't provide just the "raw bedrock APIs". They also provide a plethora of high-level APIs, including controls, layouts etc.
This is exactly the same thoughts I had before, having a new sort of framework on top of WASM instead of using the HTML/CSS/JS framework, specifically for building new applications. Glad to see this is on your mind as well.
Unfortunately most of the lack of transparency is not under the Flutter team's control, but I'll see what I can do.
> How is Flutter funded?
A number of companies (Google, Bytedance, and Canonical are three that I know have publicly stated so; there are others but it's up to them to make such statements) employ people to work on Flutter. Hardware costs (CI, source control, bug database, etc) are paid for by Google and Microsoft.
These companies don't typically share more detailed information about how they account for this funding or how much they pay exactly; it's considered proprietary, and often there are legal implications to making detailed statements about this kind of thing.
> It was said a few years ago the budget came from internal projects like ads, fuchsia, pay, and stadia
(I'm assuming you are referring to Google's portion of the funding.) That's not really how Google accounts for things internally. Broadly speaking, the more usage (internal and external) that a product gets, and the more revenue can be assigned to a product, the more Google is likely to fund it. In the case of Flutter, Google is apparently quite happy and has been increasing funding over time as a result, as have other companies (as you can tell by looking at the number of people employed to work on it).
> does stadia being killed effect the Flutter budget?
No, that's not how things work at Google. (I assume you mean Google's investment in Flutter when you say "Flutter budget". Flutter itself, as an open source project, doesn't have a budget currently. Maybe one day we'll have a foundation but right now the additional management overhead doesn't seem worth it.)
> There was an implication at that time that if they all died or left Flutter then it would be killed via budget cuts, is that true?
I think when there were far fewer apps using Flutter, and fewer other companies using and contributing to Flutter, that if Google had stopped using it internally, after a while, it would have become difficult to justify continued investment (since in that scenario, very few people are using it at all, so what's in it for Google? Google isn't a charity). However, at this point Flutter is used a great deal outside Google, as Tim discusses in his comment above, and even if Google itself were to stop using it (which seems highly unlikely) there would still be plenty of justification to continue funding it as a developer product (many of Google's APIs and developer products aren't used internally at all).
That said, this is not intended to be a forward-looking statement (https://en.wikipedia.org/wiki/Forward-looking_statement). If you want to ask Google about its future funding plans I suspect the best place to do so is a stockholders conference call.
> Why is Flutter not being adopted by Google for more outward facing apps?
With some exceptions that involve negotiations with the relevant teams, Google doesn't generally talk about what technologies it uses for its own applications. Tim listed quite a few apps whose teams have agreed to publicly state they use Flutter, though. I'm not sure what else to tell you. It's not like Google is making new apps all the time, and rewriting an app in Flutter only makes sense if the app's team benefits from the rewrite in some way.
> Is it seen internally as at risk of abandonment?
No. (But then, why would you take my word for it.)
> "600,000 apps in the Play Store alone", how many of these are commercial vs hobby projects
I don't think this is an axis along which apps are categorized, so I've no idea how to answer that. (What is a "hobby project"? Does it count as commercial if someone charges for their hobby?)
> does Google really care about these if enterprise adoption is minimal?
Yes? We care about all apps.
> Delving into game dev when iOS is not polished seemed like a decision made because there was a need to show potential value via expansion upward in the org, I was concerned this was a hail mary when announced, and with Stadia now gone the timing seems more suspect.
I'm not sure what you're suggesting here. Our work on iOS is entirely orthogonal to the work on the Casual Games Toolkit, it's not like the people who worked on one could work on the other. The Casual Games Toolkit is intended to help people who are interested in writing games with Flutter but don't know where to start; we regularly do surveys of our developer base and this was an area that people indicated an interest in. I'm not really sure what the supposed link to Stadia would even be. Work on iOS continues, and we have significantly grown the team there in the past year.
> "It has a developer base of several million", how many of these are again hobby users
We occasionally post the data from our quarterly surveys to our blog on Medium, the latest post I could find that separates the data by "what is your primary purpose" was the Q3 2021 survey's report and it had this graph: https://miro.medium.com/max/1400/0*_GNHkk5TLOI7wQYc
Looks like it's <50% are "hobby" users and the number is shrinking. That said, we explicitly want to be a project that people use to learn programming, providing a seamless path from "learning" to "hobby" to "professional" so I would hope this number never gets very low.
> how many use it weekly / monthly?
That's very hard to say for a variety of reasons (e.g. many people turn off analytics, analytics are extremely unreliable in general, many people use Flutter via means that wouldn't trigger our analytics in the first place, etc) but my understanding is that as best we can tell, Flutter has well over 500,000 MAUs. I don't think we track weekly numbers.
> Flutter has a large DevRel push, how many of these projects / users are students who just spin it up once and hit star on GH when asked and never touch it again?
I've no idea how to measure that.
> Your team was asked approximately this question by a MSFT employee looking at publishing info on cross platform framework adoption vs native and could not get a straight answer I was told.
I mean, there's some questions we just don't have the answer to. I'm not sure what to tell you. We do share quite a lot of our data, e.g. from the quarterly surveys, as noted above; for most of your answers the numbers I just gave you can be found by Googling.
I would personally love to share more (e.g. I'd love for the analytics to be public) but there are significant privacy constraints around this. Even within the team, most people don't have access to the analytics data, and we're actually making an effort to limit that even more as part of our extensive efforts around tightening security.
I hope one day we can anonymize and aggregate the data to a level that satisfies Google's privacy team and then we'll be able to share the numbers in real time, but that won't be for some time (if ever, this stuff is hard).
> Multiple Flutter related posts by agencies and evangelists point to a google trends page or GH stars saying Flutter is blowing up in popularity compared to other frameworks
I would point to things like numbers of users or apps rather than vanity metrics like GitHub stars, but there we go.
> but when you start looking at core packages searched for and starred for each framework the Flutter trend reverses, is this because the words Flutter and Dart are too common and in actuality the popularity is not what is being projected in trends?
I would posit that it is because Google Trends data is a terrible way to measure popularity of an SDK.
> Is this because DevRels directly ask people to star the core project?
GitHub stars are purely a vanity metric. I would ignore them.
> I ask Flutter GDE's these questions and they come off like they can't be trusted to be honest on these topics for fear of losing status.
Feel free to tell them to reach out to me if they ever have a question about what they can or can't say.
> I have also heard a certain outspoken Flutter GDE mention on stream other frameworks have much larger communities, how can this jive with these purported trends?
Flutter is big and growing, but there are plenty of much bigger SDKs, certainly. I don't think that's a big secret. :-)
> It seems as though the community size and growth of Flutter is projected to be greater than it is, that's subjectively how it feels as a dev as well I will note as someone who is using packages / repos, and that is worrisome.
There are plenty of SDKs with much smaller communities that are very healthy and have been around for decades. I think it's reasonable to be concerned about ecosystem health, but I must say that personally I am quite happy with Flutter's ecosystem and community size and growth.
> I worry that the first time we hear solid numbers will be in a blog post about the Flutter project ending with an explanation that low enterprise adoption and direct or indirect revenue could not support the scale of this ambitious a project.
Well good news, the numbers you asked for have largely already been discussed publicly, so you need not have that specific worry.
> It would be great to hear some hard facts that give people confidence in adoption and that Flutter has long term backing higher in the company. If this is not the case, honesty would be nice as well.
I can't promise long-term backing from Google, because I'm not the CEO and ultimately it has to be his call. I can point to all the reasons Tim gave above for why there's no reason to expect Google to abandon Flutter any time soon, and I can point to the numbers I gave above as the "hard facts" you are looking for, or at least the closest things to them that one can have. Unfortunately with squishy things such as ecosystem size and how people use products and so on there is so much noise in the data, such big error bars, that anyone giving you precise numbers is selling you snake oil.
> @a14n seems to have tailed off on his work on Flutter quite a bit, which worries me if he is the core example of users who would pick this up in an OSS abandonment situation.
I think Tim just pointed to a14n because he's contributed so much over the years. No one person could take over the project and I certainly wouldn't put that on a14n's shoulders!! You can look at our GitHub and Discord activity to see how the project is doing in terms of non-Google contributors.
> Even now it feels as though if major OSS package maintainers like Remi Rousselet walked away the community would be hit hard.
We are a long way past there being any single person who is keeping the project afloat.
> I can't imagine the project continuing without Google, especially with Dart needing the same treatment if Flutter was killed. Dart issues with notes saying the team lacks bandwidth exist now, I just can't see it working even with some other companies interested, Flutter/Dart need full enterprise backing at this stage.
You never know. FreePascal is an example I love to point to; it's an open source project with minimal (if any) corporate/enterprise funding and yet they have been delivering reliably for decades now. I don't see why a dedicated team couldn't pick up Dart in the same way, if the interest was there.
> BUT, it still has the biggest complaint I hear about Flutter apps on iOS, feel.
The biggest complaint we hear is definitely jank, FWIW. :-)
> On iOS is does not feel native, the scrolling and gestures feel off.
If you have specific reproducible cases of this, please file bugs with test cases demonstrating it. The more concrete and specific you can be (e.g. high speed video showing the difference) the better.
We actually have built tools to verify that we are matching iOS physics to the pixel, so if there are cases where we're not, we would love to learn about them and fix them. (Unfortunately until recently we were mostly focused on lower-level issues on iOS, like performance and plugins, and have not had as much time to spend on widgets and physics. That's changing, though.)
> This is part of what I was referring to regarding ignoring polish on iOS in favor of expansion earlier, iOS still feels second class on Flutter.
We've made huge strides here in the past year, but yeah, we still have work to do.
> My final thought is the same as my first, be more transparent, show the community with tangible honest numbers and backing Flutter is not in jeopardy, otherwise the track record (and imho vague mushy pumped up stats) makes it appear it is.
As far as I can tell, we've been transparent, with most of the numbers you say you'd like us to share being numbers we have in fact shared already. The numbers are not made up, but yes, they are mushy. If you have any idea how to get less mushy numbers, join our Discord, help us out (the link to the Discord is in the contributor docs on GitHub).
Hey, want to start by saying I appreciate the full reply, this is much more reassuring. Obviously trust in Google is what it is...
On the budget / funding side I understand not all details can be shared, I think the general gist is just the broad question of what can effect flutter funding. It sounds like Stadia shut down won't, but I see that question was also raised on Reddit, so clarity on that was appreciated beyond myself I am sure, and any more would be appreciated as well.
On internal apps, I know Flutter is being used, this sort of leaks into PRs, comments, etc, but I think the question I was getting at is if that has enough value to google. On the outward facing apps this is definitely a matter of perception, I don't think I need to expand there.
The hobby projects, I think this is hard to define but is a classic you know it when you see it. The result of a single Udemy course, something that serves 0 to few users (most of whom are the devs friends), something not actively being developed, something where the code base is quite small, etc. Projects done and published for the sake of learning more than their use to others is likely where I would draw the line. I think there is another line at profitable / paid dev, but I would say the lesser line is appropriate. I think the wider question is how many people are getting enough value out of Flutter that it truly translates into value for Google that is worth sustaining, definitely not an easy question to answer.
> I'm not sure what you're suggesting here. Our work on iOS is entirely orthogonal to the work on the Casual Games Toolkit, it's not like the people who worked on one could work on the other.
This is still hard for me to swallow. Codegen for json deserialization, data types, general slowdown in the analysis server at scale, the list feels long, I would have to dive into the current issues to get them all. But coming from other languages / frameworks there is an incompleteness that feels more important to address than games no matter what a survey says. Saying they are orthogonal is denying resources/funds could be used differently for different goals. The Stadia link was simply it seems growing Flutter user base has a priority over polish, and with an internal app shutting down it seemed growth could itself grow in importance over polish.
> <50% are "hobby"
> 500,000 MAUs
Thank you! This!! This gives some idea of how many devs are truly working on Flutter worldwide. These numbers make much more sense to me and what I see!"It has a developer base of several million", I felt like this was gaslighting me as I could not see where all these devs existed, how were stackoverflow issues that seemed like they should be semi-common with 0 to 1 replies!? This did not jive with millions of dev, even a small percent working at enterprise scale, and did not fit with my experience working on other frameworks that claim similar scales.
> I would point to things like numbers of users or apps rather than vanity metrics like GitHub stars, but there we go.
> I would posit that it is because Google Trends data is a terrible way to measure popularity of an SDK.
> Flutter is big and growing, but there are plenty of much bigger SDKs, certainly. I don't think that's a big secret. :-)
Combine the use of these two stats being heavily pushed in blogs etc with the, "It has a developer base of several million", quote, mix in first hand observations that they feel off, and the feeling the team is hiding something starts to manifest. Especially when blog posts turn these stats into proof through twisting that Flutter is for lack of a better term, "the biggest". Thank you for noting these are vanity numbers, imho pushing them does a disservice. I will also submit that at 5 years old continuing to push the narrative that Flutter is "new" and the nearest competitor only has any gains do that that gap starts to get some side eyes.
> We are a long way past there being any single person who is keeping the project afloat.
Agreed, but still it feels like there are a few big hitters, it does not go unnoticed where he works and I am guessing is sorta paid by proxy by Google.
> I don't see why a dedicated team couldn't pick up Dart in the same way, if the interest was there.
Agreed on Dart, I think Flutter is another matter though.
> The biggest complaint we hear is definitely jank, FWIW. :-)
>If you have specific reproducible cases of this, please file bugs with test cases demonstrating it. The more concrete and specific you can be (e.g. high speed video showing the difference) the better.
These feel tied together, I mean this in a honest way and not to offend the team, but does anyone on the team use iOS full time and run Flutter apps on device in prod regularly (just cruise ebay motors?)? I talk to other iOS users and this is a well known issue, scroll acceleration is off (scroll fast and it's WAY off), there is an issue already posted for Flutter with scroll being a full frame behind native so the location / perceptions feels off at first touch, and pull to refresh is a bit janky at times. "We actually have built tools to verify that we are matching iOS physics to the pixel" I mean no offense, but is something code wise wrong in the tooling? As a full time iOS user it's VERY obvious, you feel it and see it, my friend literally deleted an app due to it after using it for seconds, it's not just a vague complaint, it's highly perceivable.
> We've made huge strides here in the past year, but yeah, we still have work to do.
TY
> As far as I can tell, we've been transparent, with most of the numbers you say you'd like us to share being numbers we have in fact shared already.
I have gotten more info from this post than anything else I have read on the state of Flutter, appreciate it.
> I think the general gist is just the broad question of what can effect flutter funding
I mean, I hate to be flippant about it, but honestly the biggest factors in Google's funding of Flutter in the last 5 years have been COVID-19 and Russia attacking Ukraine, along with the subsequent market instability and inflation.
> The hobby projects, I think this is hard to define but is a classic you know it when you see it.
Well that's fine but I can't afford to have someone comb through 600,000 apps and make a call for each one on whether it's a hobby or not. :-)
> The result of a single Udemy course
We don't know how people wrote their apps. Also, someone can do a single Udemy course and then develop a killer app that makes millions of dollars. Is that a hobby?
> something that serves 0 to few users (most of whom are the devs friends)
I assure you plenty of commercial projects fail in exactly this way. ~90% of startups fail.
> something not actively being developed
Plenty of commercial projects have no active development. Probably most, frankly. For example my bank's app hasn't changed in years.
> something where the code base is quite small, etc.
Is Wordle commercial or hobby? Would a Wordle-style app written in Flutter count as a hobby app or a commercial app? What if it sells for millions of dollars the day after we decide it's a hobby app?
I just don't think this is a useful metric.
> I think the wider question is how many people are getting enough value out of Flutter that it truly translates into value for Google that is worth sustaining, definitely not an easy question to answer.
The value Google wants is ad dollars, Android users, and reduced internal development costs. Google isn't willing to report any of these numbers, and they are material so I would get in legal trouble for revealing them. My job is working on Flutter, and I am not concerned for my job. If that's not enough, there's not much more I can tell you.
> I would have to dive into the current issues to get them all.
I'm happy to discuss whatever issues you'd like if you're curious about current status on things. I recommend reaching out to me on our Discord (link in the contributing docs on GitHub, I'm @Hixie there). In general all our issues are public on GitHub and for Flutter I try to give regular updates on the top-voted issues (see also https://github.com/flutter/flutter/wiki/Popular-issues for a summary of the top 10).
> But coming from other languages / frameworks there is an incompleteness that feels more important to address than games no matter what a survey says.
I'm not sure what to say to that. Dart has one of the most comprehensive standard libraries out there. We have some holes, e.g. we don't yet have a good story for HTTP2, which we're working on. But compared to most languages, the core standard library is way more comprehensive than average, IMHO.
But again, the people who would work on, say, HTTP2, and the people who would work on the Game Toolkit, are entirely different people and the skills aren't interchangeable. Engineers aren't commodities you can just move around at will. People specialize, have interests, commitments are made, etc.
I would also say that "no matter what a survey says" is a very subjective way to run things. I actually strongly appreciate our data-driven approach. I think that's the right way to develop a product. You're never going to be able to address everyone's needs, but addressing the needs of the most people first seems like the better choice. We drive almost all our efforts from hard data collected in surveys, UX research, voting on issues, etc.
> Saying they are orthogonal is denying resources/funds could be used differently for different goals.
The paltry funds we spent on the Game Toolkit work literally could not have been used for iOS work. That's just not how things work.
> growing Flutter user base has a priority over polish
The two are not mutually exclusive. The Google team working on Flutter is currently focusing on growing the user base _by_ improving the polish (specifically around developer experience).
> Thank you! This!! This gives some idea of how many devs are truly working on Flutter worldwide. These numbers make much more sense to me and what I see!
These numbers have been public for some time, for what it's worth. We're pretty transparent, more or less as transparent as we can be about this stuff given constraints like privacy on analytics and given the very dubious nature of analytics in general. We tend to share these numbers on our blog and developer events regularly.
> "It has a developer base of several million", I felt like this was gaslighting me as I could not see where all these devs existed
The total Flutter developer base is much bigger than MAUs. As best we can tell from data collected by third parties, there are several million developers who use Flutter. They might not all do so within the same month, though. (For the same reason, if we had weekly active user numbers, they'd be smaller than the monthly active user numbers.)
I would be very careful about interpreting absolute numbers here. You cannot compare numbers from different sources because collection methodology is such a huge factor in determining the result (literally by orders of magnitude). In my experience the only way to use metrics like this is comparing them over time to metrics collected in the exact same manner.
> it does not go unnoticed where [Remy] works and I am guessing is sorta paid by proxy by Google.
I actually have no idea where Remy works, where is it?
> These feel tied together, I mean this in a honest way and not to offend the team, but does anyone on the team use iOS full time and run Flutter apps on device in prod regularly (just cruise ebay motors?)?
Yes, of course.
> I talk to other iOS users and this is a well known issue, scroll acceleration is off (scroll fast and it's WAY off), there is an issue already posted for Flutter with scroll being a full frame behind native so the location / perceptions feels off at first touch, and pull to refresh is a bit janky at times.
Do you have the issue #? I can see if we should be prioritizing it higher.
> "We actually have built tools to verify that we are matching iOS physics to the pixel" I mean no offense, but is something code wise wrong in the tooling?
Maybe? I don't know. My experience on iOS is that we do pretty well, but maybe I'm just not sensitive to the same issues, or maybe it affects different hardware, or maybe we have changed the settings, who knows. Concrete data filed in actual GitHub issues is the way to resolve this.
> I mean, I hate to be flippant about it, but honestly the biggest factors in Google's funding of Flutter in the last 5 years have been COVID-19 and Russia attacking Ukraine, along with the subsequent market instability and inflation.
Very fair
> Well that's fine but I can't afford to have someone comb through 600,000 apps and make a call for each one on whether it's a hobby or not. :-)
> We don't know how people wrote their apps. Also, someone can do a single Udemy course and then develop a killer app that makes millions of dollars. Is that a hobby?
> I assure you plenty of commercial projects fail in exactly this way. ~90% of startups fail.
Here I what I was getting at was todo examples being submitted, or some single tutorial chat client, someone can come out and make flappy birds of course, I taught kids in the past and some went on to publish their apps as encouragement from their parent. Nothing wrong with it, just don't see it paying the bills was my point. That was the totality of my point I think....
> The value Google wants is ad dollars, Android users, and reduced internal development costs.
I was trying to get at if a billion "hobby" devs don't drive any of this it's all a zero, thus my interest in that number.
> My job is working on Flutter, and I am not concerned for my job. If that's not enough, there's not much more I can tell you.
This is the best answer yet
> But again, the people who would work on, say, HTTP2, and the people who would work on the Game Toolkit, are entirely different people and the skills aren't interchangeable. Engineers aren't commodities you can just move around at will. People specialize, have interests, commitments are made, etc.
Totally agree, it seemed more to me people were hired for this vs expanding elsewhere.
> The paltry funds we spent on the Game Toolkit work literally could not have been used for iOS work. That's just not how things work.
Seems like it didn't matter though so fair enough
> I would also say that "no matter what a survey says" is a very subjective way to run things.
> The two are not mutually exclusive. The Google team working on Flutter is currently focusing on growing the user base _by_ improving the polish (specifically around developer experience).
I could be 100% wrong but perception is real, after I wrote this I was sent links to other people on twitter lamenting the same growth into other sectors while mobile was not polished. I know in the yearly survey it asked about professional use, not sure if that gets more weight?
> These numbers have been public for some time, for what it's worth.
I tried googling this so many times, SEO of dev shops and blogs obscure whatever is out there on this subject.
> The total Flutter developer base is much bigger than MAUs
This is a deeper convo, if I have to update some wordpress php once every 6 months am I really part of the php/wordpress developer base? Idk, it's semantics I suppose, I have my opinion that the base is people who deal with the language / framework on a nearly weekly basis. My point in being interested in this number related to "Google wants is ad dollars", and the assumption they connect.
> I actually have no idea where Remy works, where is it?
Remmy works for Invertase who make all the Firebase packages, he and they do a great job imho.
The last pieces were on iOS, here is the issue that was filed: https://github.com/flutter/flutter/issues/110431 but honestly if you have full time iOS users ask them, they have to know, it's impossible to miss, this is not the only issue, but it requires more quantifying. To be totally frank as a dev with many iOS and Android test phones, Flutter scrolling feels like Android scrolling on an iPhone.
>Codegen for json deserialization, data types, general slowdown in the analysis server at scale, the list feels long,
Those are clearly Dart critiques, sure Dart is not a perfect language, but I can tell you coming from Java and Kotlin that they have plenty of warts of their own, as does ObjC and Swift. On the other hand, Dart is still being very actively developed and improved so I have no doubt that in the future, it will be better than today, just as its sound null-safety now out classes Kotlin's NS implementation.
>but does anyone on the team use iOS full time
Not sure why you keep focusing on iOS and Flutters focus on Material. Sure you might feel the need to use iOS styled widgets but there are plenty of commercial apps built with Flutter that very happily base off of Material and you should note that the new rendering engine has been developed on iOS first to specifically address many of the valid perf issues that skia based engine has had on iOS and Metal.
>. On the outward facing apps this is definitely a matter of perception, I don't think I need to expand there.
After reading all your preceding posts and now this, you seem to want to imply something but not come out and say it. I know that Google have publicly announced Flutters use by Google Pay (https://flutter.dev/showcase/google-pay), if that's not a big enough app for you I'm not sure what would convince you.
>As a full time iOS user it's VERY obvious, you feel it and see it, my friend >literally deleted an app due to it after using it for seconds, it's not just a >vague complaint, it's highly perceivable.
This is my biggest pet peeve, anecdotally I hear a fair bit of this coming from mobile devs, especially with iOS devs who seem fixate on this, but guess who I've never heard this from in over decade in mobile dev: iOS users (and Android users) who are not devs. Literally never. Not a single non-dev person has ever mentioned it to me. Sure the complain about a million others things to do with phones, apps, you name it, it's amazing all the things people want to talk to you about when they find out you're a mobile app dev, but literally it's never about scroll physics being too fast or off.
Sure I'm very involved in the Flutter community and do it for my day job, so I can quite rightly be labelled as biased, but trying to be as objective as possible, on all measures I can think of, Flutter is a very successful open source project and simultaneously a very successful "commercial product" which is quite a rare feat to this day.
Finally on the topic of open source, I'd point out that unlike for instance AOSP (another huge Google project/product) Flutter is not developed in "throw it over the wall once a year" fashion but completely in the open, all work is done in the public repo, on public issue trackers, public design documents, roadmaps, etc. Its really quite exceptional in this regard and is really one of the big reasons why its really close to foundation/consortium style projects (think Apache, Eclipse, Linux, Rust) than a single-corp sponsored one.
Every language has spots of pain, of course, but the sticky points in Dart at scale don't feel like rough edges, they significantly effect workflow.
> you seem to want to imply something but not come out and say it
I have said multiple times not eating the dog food makes me weary, Google uses Angular a lot, why not Flutter? ...I think you need to read back I am well aware of Pay, this thread is about Stadia, the largest commercial Flutter project at google afaik, being killed. Pay is USA and India only.
> Not sure why you keep focusing on iOS and Flutters focus on Material
> This is my biggest pet peeve, anecdotally I hear a fair bit of this coming from mobile devs
> Not a single non-dev person has ever mentioned it to me.
I think you may be too deep in the Android space, I have heard this a ton. TBH I think many times the apps are wrapped webviews so scrolling works but other interactions feel off, but 100% non devs notice when iOS apps don't feel native.
Oh I'm sure plenty of that happens, but that's true of all SDKs. Plenty of people do that with Android Views, plenty of people do that with Swift UI, etc. I have no reason to believe that Flutter is particularly different from the others in terms of the proportion of apps of this kind.
> Totally agree, it seemed more to me people were hired for this vs expanding elsewhere.
Ah, no. We've hired more engineers for iOS work in the past few months, but the games toolkit was mostly devrel and a contractor, if I recall correctly. Similarly for things like the pinball demo or the Wonderous app, those are primarily done by contracting an agency rather than people on the Flutter team, with the agency's feedback directly feeding into the engineering team's priorities. So for example, Wonderous was great because during its development it helped us find a whole bunch of issues we needed to fix.
> after I wrote this I was sent links to other people on twitter lamenting the same growth into other sectors while mobile was not polished
Again, the various areas aren't comparable or exchangeable. For example, Canonical is contributing to the Linux port, but it's not like Canonical would ever contribute to the iOS port, after all, their interest is in using Flutter on Ubuntu. Similarly, people Google hires to work on the iOS port are typically not the kind of people who want to work on Android or Windows, and so on. There's lots of areas of specialization, and if you task people to work on areas they're not experts on and not interested in, you're just going to burn them out and get low-quality work.
Even if people were commodities and interchangeable, though, I don't think it makes sense to focus on one area at the exclusion of another. There is more value in Flutter being able to target seven platforms (Android, iOS, Windows, macOS, Linux, web, and Fuchsia) well, than there would be in targeting just one platform completely perfectly. Especially because the effort to get from zero to excellent is much less than the effort required to get from excellent to perfect. Flutter is not unique in this. Kotlin isn't perfect on Android, but that doesn't mean JetBrains should avoid working on web support. C++ isn't perfect on AT&T Unix, but that doesn't mean people shouldn't implement it on other platforms. HTML isn't perfect for documents, but that doesn't mean we should not have extended it to applications. My house's kitchen isn't perfect, but I still want a bedroom.
> I have my opinion that the base is people who deal with the language / framework on a nearly weekly basis
By that definition, I am not a programmer, because there's literally no language that I use every week. Indeed, there are entire weeks where I don't write any code at all!
Looks like Chris is working on that one. (By the way, that issue was filed by a Flutter team member, so presumably that answers your question about whether the Flutter team notices iOS issues.) (Also, that issue is a good example of the tools that we use to test this stuff.)
> I have no reason to believe that Flutter is particularly different from the others in terms of the proportion of apps of this kind
I was just trying to understand adoption rate which I believe correlates to longevity
> Again, the various areas aren't comparable or exchangeable.
> My house's kitchen isn't perfect, but I still want a bedroom.
I totally get this viewpoint, I think perception can be different from the outside.
> By that definition, I am not a programmer, because there's literally no language that I use every week.
Head back to IC ;)
> By the way, that issue was filed by a Flutter team member, so presumably that answers your question about whether the Flutter team notices iOS issues.
Need to take issue here, this was talked exhaustively about in a thread on reddit where a dev was leaving Flutter because of user complaints on this issue, the thread was seen by a team member then and taken up.
(I was previous editor of the HTML standard for ~10 years, now I'm the Flutter TL)
I mean... you're not wrong. But let's be honest, we never managed to really deliver on the web's promise here. It was <table> and <font> in the 90s, it's WebGL+Wasm now, but the reality is we've never succeeded at true portability (ever tried going to a non-trivial site in lynx? or a web app on your phone?) or accessibility (just ask anyone who uses a screen reader how accessible the web truly is) or customisability (have you _tried_ creating a user style sheet?) or interoperability (I spent a literal decade just trying to clean up the mess around HTML parsing and that was the success story!).
I just typed this comment using a plugin that gives me vi bindings
inside the editor, on a page where I have increased the font size to 110%
because I personally find it nicer that way.
All done without the permission of ycombinator and yet working perfectly
with their web page. And this is not just because ycombinator has very
basic HTML ... this works with at least 90% of web sites I go to.
It may not have achieved its loftiest aims, but I think the open web is an
absolutely amazing achievement and success if you compare to what we would
have had without it.
HackerNews uses tables for layout, inline styles, and still forces browsers into quirks mode. Yeah, it can handle slightly bumping up the font size. I can also bump up my font size on Windows, macOS, and Android, and that works for 90% of apps there too.
I agree that the open web is an amazing achievement. I don't think Wasm and WebGL take away from that at all. It's just the next logical step to make the web possible for an even greater set of applications.
Exactly. This is something which will most likely be lost by adoption of canvas webapps :( It will solely be on the webapp developer to implement/allow any kind of scaling. And generally such creators don't care. Webapps today are already pretty hostile - for example their embedded video players are often terrible but it is difficult or even impossible to play in an external dedicated players because of various chunk/blob/mediaSourceExtension/DRM stufof.
OK, but the Flutter gallery has zero selectable text, as far as I can see. Seems like a great case of where developer decided "doesn't need selection, let's let the user drag to scroll with their mouse instead".
Why even make it a 50/50 choice? I hate apps without selectable text and they're everywhere. Translating something becomes a nightmare and that hurts useability.
It's like if you made spoiler 50/50. Do you want to see this without clicking?
I think we really overlook the thought that had gone into making js, and other open tech.
Exactly. And I didn't even realize how often I subconsciously select text while I read until I saw the relevant xkcd. [1]
I truly think my random clicking on paragraphs that I'm approaching isn't just ADHD but a way of helping my eyes stay on track. It's very disconcerting when the text doesn't select. (As, clearly, all these comments noticed as well -- why were we all trying to select the text? To check if it's Flash-ish, of course, but also we just like things to grab onto while we read.)
Try putting their demo website in Google Translate or even try to select the text on an email in their demo webmail app to copy paste it in google translate ....
Could any Android dev veterans chime in and comment on JetPack? This is the first time I'm hearing about it and I'm not sure I like it. It looks like a weird blend of HTML, CSS and JavaScript event handlers and I'm starting to wonder: Why not use web technologies from the get-go then and make use of the lessons learnt there?
This reminds me, I'm getting the impression that with every new UI framework that gets released, we're just recycling ideas learnt on the web and re-living its paradigm shifts:
1. First, in the early days of the web, we defined UIs declaratively but mixed structure and looks (`<h1><font face="Comic Sans MS">Hello, world!</font></h1>`).
2. Then we separated content structure (HTML) and styles (CSS) (or even XML and XSLT)
3. Later on we added dynamics and discovered event handlers (JS)
4. Then we realized we could use JS for everything (content, styles, dynamics) and imperatively create & manipulate UIs by manipulating the DOM (document.createElement, jQuery, d3).
5. Finally it dawned on us: That's not a good idea, either, because 1) we're mixing business logic and styling and 2) the DOM is global state. So we switched back to the now classic separation of using HTML for content, CSS for styles and JS for dynamics. But this time we try to keep individual components (their state, their DOM and their business logic) neatly encapsulated (React, Angular, Web Components).
> Could any Android dev veterans chime in and comment on JetPack?
Small nit but Jetpack is the name of the entire suite of libraries that Google offers for Android. The thing formally known as "support lib", a name that stopped making sense when it had random useful stuff not just compat stuff.
You're talking about Compose here (or Jetpack Compose).
The step 6 is to integrate graalVM into web browsers in order to allow seamless interoperability between any language (e.g Kotlin) and any other language, especially javascript and the web apis.
Unfortunately because of harmful politics from mozilla pushing the NIH webassembly, it's not going to happen before a proponent come (maybe Microsoft someday)
