51. Todd Volkert
20:34 Share

Hi, thanks for listening. This is the It's a Widget's Flutter podcast. My name is Hillel Korn. Each episode, you get a chance to speak with another amazing member of the Flutter community. This episode, we're extremely lucky to be speaking with Todd. Welcome. Thank you. Happy to be here. Thanks for being on. So to start, can you share a bit about your background? Yeah. So I'm Todd Volker. I lead the Flutter engineering team. I've been at Google about, geez, what's it been? 14 and a half, coming on 15 years now. Yeah.

I've been off Flutter the majority of that time, I think since maybe early 2015. So I don't know, about nine years or so. And that's because throughout my career, I have a history of gravitating towards developer frameworks, towards UI frameworks and towards open source. So when I found the Flutter team, it kind of checked all the boxes and I've been here since.

Before Google, I worked at a number of companies, but one thing that I kept on finding myself doing was building various frameworks. And I really enjoyed when I hit UI. One of the things I did in the past is I started my own company doing photo management software.

And as part of that, I did a lot of the various engineering efforts. And this is circa 2003 or so and discovered, you know, the budding Ajax and, you know, dynamic web pages stuff and ended up building kind of a rich UI framework as part of that. And then from there, I went to VMware and, you know, worked on their client software for their server line of products.

And in the process of building their front end UI for that, we kind of ended up building a generic UI framework that then evolved into what became Apache Pivot, which is the UI framework that nobody's heard of, but was an attempt at the time to be kind of a modern replacement for Java Swing and for Adobe Flex. And it came out right around the time the iPhone came out and mobile kind of shook the whole world. So it ended up not going anywhere.

But that experience, you know, came back to bear when I had found the Flutter team. That's really interesting. A life of UI frameworks. So can you explain, you said you're engineering at Google for Flutter. I'm not familiar with Google's structure. How does, what does that mean? Yeah. So my, my official title is director of engineering, leading the Flutter team. And Google has an interesting structure. So they usually separate out the engineering reporting chain from the product management.

on purpose so that the product manager lead and the engineering leader kind of partners. So at Flutter, we have, you know, Flutter and Dart have worked very, very closely together. So, you know, I'm the director of engineering for Flutter. Vijay Menon is kind of my partner in crime on the Dart side. And then Michael Thompson is the product manager lead for Flutter and Dart. So

The three of us kind of are the three-headed beasts that lead the strategy for Flutter and Dart. That is extremely helpful. Thank you. I never realized that.

And I've been following Flutter for a while, not as early as you, but for a few years now. I have to say, as a community member, it's been a bit sad seeing some of the early faces leave the team, particularly people like Eric, Ian, Tim, and I'm sure many others I'm not thinking of. Why do you think that is? Is there something, I think Ian's blog posts seem like the most revealing about the culture. Do you have any perspective or information to share? Yeah.

Yeah, it's funny you say that. So you asked about the management structure, right? So, you know, Eric used to be the director of engineering for Flutter and then for Flutter Endart. Tim was the product lead. So you can kind of see the parallels there. So when Eric left, you know, I've been on the team, you know, for a very, very long time. But when Eric left, I kind of took over as the new engineering lead. Yeah, from my perspective, to be honest, let me back up a step. We have this funny joke on the Flutter team.

that anyone who ever leaves the team always comes back. I could run through a list of names that aren't necessarily in the public eye, but we have a lot, a lot of people that have left the team over the years only to come back six months, a year, two years, sometimes five years later. In fact, the current head TL of Flutter used to work on the Dart team way back in the day. It was the inventor of Hot Reload and went to work on server-side stuff at Google and then came back after like seven years.

But anyway, so from my perspective, I actually think a lot of the people have we have a way lower attrition rate on the team, like significantly lower than most Google teams. So I start with that premise. I think we actually have a very good keep rate on the team when it comes to the leads, you know, such as Eric and Tim and Ian. Two thirds of those still work on Flutter.

So, you know, I consider the Flutter team broader than just those people that work at Google. And, you know, Eric went to start his own Flutter based company at Shorebird is doing great things there. Ian is doing private consulting around Flutter and still contributes to Flutter.

So both of them I still consider basically part of the Flutter team as much as they don't work for Google. Tim's a different beast. Tim and I are still friends. We just had dinner last week. I think he viewed it as he came to do a certain task. He took this thing, which he saw a ton of potential in in Flutter when it was still not 1.0, it was still beta, and take it from...

from its early, you know, incubation stages from a product perspective and really kind of bring it to the world and take it to the next level. And I think he, he viewed himself as successful in that mission and kind of culminated in, you know, the Flutter events, uh, in Africa. Um, and now he kind of said, Hey, you know, I've got, I've got maybe one more, uh, one more rodeo, but before I, before I hang my hat up and retire and wanted to go kind of try a new challenge. So, um,

He still very much roots for Flutter. Like I said, I meet with him frequently and he's still rooting for us, which is a little odd for those who follow Tim. He's working over at Apple, so there's ostensibly working for the competitor, but he truly does still believe in Flutter and is rooting for us on the sidelines. That's great to hear. I have tremendous respect for Tim. He did an incredible job. I'm sure he's tough back to follow. And all the team, you're absolutely right. The fact that Eric's still involved with Flutter says a lot.

I still joke with people that, you know, said Eric and Ian and Tim too. I say, you'll be back. Like, even if you're still working on Flutter only, I would not be surprised if we end up working directly together again on Flutter. I mean, it is a great project.

That's awesome. I'll tell you on that topic, it was nice seeing Seth Ladd rejoin the team. He's someone who's post and stack overflow have helped me endlessly for years and years. Yeah, Seth is the OG product manager. He was the original product manager on Flutter. So he's one in literally like 15 people that have decided to come back to the team because it really is an incredible community.

Nice. So after the recent Google IO, I think developers were curious or concerned seeing that Google were recommending Kotlin multi-platform alongside Flutter. Can you speak to that? Maybe help clarify a bit? Yeah, I think it's a tough message. We worked hand in hand with the Android team.

Because, you know, organizationally, we're two different teams, but we work very closely with them. We were trying to craft that messaging, but it's a tough message. So the gist is that I can start with kind of what the message is and try to say it in plain English. And they kind of give some color around that is that Kotlin multi-platform is for shared business logic. It is not attempting to solve shared UI issues.

There's a separate project I'll talk about in a second called Compose Multiplatform, which is a whole separate thing. But Kotlin Multiplatform, KMP, is just about shared business logic. And Google, since around 2017-ish, is investing in Kotlin and believes that it helps the Android ecosystem. And I think there's a lot of data to show that. So Kotlin Multiplatform is around how do we get people to share business logic across Android and iOS?

And in so doing, you know, Google's strategy there is to try to, you know, draw people from iOS to Android, right? It's a competitive marketplace. So the shared messaging there is that if you want to do shared UI, Flutter is the recommended solution from Google. If you want to do shared business logic and gain the advantage of, you know, importing all the JVM code and having direct JVM interop, then Kotlin multiplies the answer.

Separate than that, there is a Jetpack Compose, which is a framework that was actually inspired by Flutter. We kind of

in the early days, worked with a team that was to become the Jetpack Compose team. And they helped learn a lot of the lessons that Flutter learned along the way to educate their next-gen framework. And it's a Kotlin-based UI framework that's reactive, and I'm sure people are very familiar with it. That, again, is if you're in the Kotlin ecosystem, you want to write your UIs in Kotlin, that is a modern framework, more modern than the Android views that we see.

But separate than that, now there's this, it gets really confusing real fast because then there's also composed multi-platform, right? Composed multi-platform is a much earlier, much more nascent effort that is actually not worked on directly by Google. It is worked on by JetBrains. So you'll notice if you go back and read the shared messaging that Kotlin multi-platform for shared business logic is Google's suggested solution for shared business logic when you stay in the JVM and Kotlin-based ecosystem.

Flutter is the recommended solution for shared UI. Nowhere in there is it talk about composed multi-platform, and that's because that is distinctly a JetBrains effort. Thanks. That's helpful. I think that definitely clarifies what the messaging is. I think, just speaking about the development of Flutter in general, I was recently reviewing the 2024 roadmap. I think we're towards the end of the year. How do you think the team's done progress-wise? I think they're doing fantastic. Yeah.

I'm trying to remember what's directly on the roadmap, but obviously we always care about performance and fidelity. So there's been a lot of work on Impeller. I'm sure everyone's super interested in Impeller. So right now it is on by default on the main channel. We expect it to be on by default later this year on the stable channel for Android.

It's been on by default for a while on iOS, and we are pretty close, I don't know exactly when, but pretty close to be able to remove the opt-out for iOS because we've ironed out all the kinks to the point where there should be no reason to opt-out of Impella for iOS. So that effort's going very, very well, and we're seeing really good performance numbers. I think we're

We've kind of outperformed the kind of best case performance that we started at while also not getting the shader compilation jank and stuff. So performance is going really, really well. We have efforts around memory. We have efforts around interop that are a little bit earlier phase, but looking really, really promising. We want to get to the point where right now, if you want to do a plugin, you want to connect to native functionality, you have to go through message channels. It's kind of clunky, kind of fast.

We want to radically simplify that to where you can just directly call out to Kotlin code, Java code, Swift code, what have you. We're doing some really good work on the framework with material. Material is just an ongoing journey, right? Because it's always evolving. But with some material work, and we're doing a lot of work on Cupertino to make sure that our iOS fidelity is really up to snuff.

And the Dart side of things, doing some really good work there too. I think in the roadmap it talks about macros and exploring with macros. They got really positive reception at I.O. They're early, so it's still kind of pre-alpha, but really excited about some of the work we're doing with macros. I think one of the things that's happened is Flutter was invented

uh, the state of the art then was, I mean, React Native exists, but the state of the art on Android and iOS was still, you know, imperative frameworks and old UI kit and Android views and whatnot. Um, so Flutter seemed really, really modern at the time. But I think one thing that's happened is partly driven by Flutter's success. You know, those toolkits have really been competing, um, and Swift UI and Jetpack Compose are really, really great frameworks. And one of the things is that Flutter is starting to look a little long in the two,

So I think one of the things that we can do with macros is use that to get some, you know, brevity and some sexiness back into the language and back into Flutter in a way that, you know, we need to keep pressing our advantage. So a little bit of long winded answer, but I think the roadmap is, you know, I've been happy with our success thus far.

I'm curious in general, how do you guys prioritize the work on mobile and web versus desktop? I find personally for our own use cases, Flutter desktop to just be amazing. I feel it's underappreciated. If I was building a desktop app, I can't think of a better solution for cross-platform. Yet in the world of Flutter, it seems like everything is very much mobile focused. And then Waz and my web is also very exciting. So thoughts on resource sharing between those three platforms?

Yeah, it's a really good question. I myself am a huge desktop user. I literally in my spare time when I, you know, don't have a bunch of housework to do and taking care of kids and whatnot, and building a Flutter desktop app for doing, you know, photo and video geo tagging. And I think it's just a great experience when you want to quickly debug your Flutter stuff without having to fire up an emulator or plug in a phone. So.

Yeah, I completely wholeheartedly agree. As you identify, it's a resourcing issue. So, you know, we're always kind of working on the highest priority things we can at the same time. One really nice benefit here is we have our community as well. So, you know, I can manage the priority of what Google employees work on.

But we've got a great community out there that's always contributing as well. We have some freelance developers that are contributing for desktop. We have Canonical and Ubuntu are doing a lot of work around desktop. We've got Microsoft to work around desktop. So luckily, we can lean in our community somewhat there. But at the end of the day, it's about what is the highest priority for our roadmap today and this year. So we do continue to work on desktop. But as you identified, there's a lot of work to be done on mobile as well. And mobile is not done yet.

So it's kind of a quarter by quarter, year by year, you know, what do we have to deliver this quarter?

Right, that makes sense. I definitely understand that. The recent Google I.O., AI was mentioned countless times. I think they actually counted how many times it was mentioned. I'm curious, your perspective, leading the Flutter team, are you using it yourselves? Does the Flutter team use AI to build Flutter? Do you have thoughts in general about how AI will affect Flutter? Yeah, were you playing the AI drinking game during the conference? Yeah, exactly. Yeah, I think the truth here is that there's a few things that are

I think pretty well accepted. And one of those is that nobody really knows exactly how AI, you know, the low level specifics of how AI is going to affect development. But I'd say roughly approximately everyone is confident that it will affect development.

So there's a lot of it's kind of like a gold rush happening right now where there's a lot of people out chasing various initiatives. And I think you look back historically at these types of events, we're going to look back in some number of years and there will be some people that thought that was going to be successful and it's not. And there's other parts that people are going to say, oh, I didn't think that was going to be as big as it is. So we're all kind of figuring that out.

So Flutter is investing in AI, you know, on a few different fronts. We obviously it's kind of table stakes to say, hey, if there's AI toolkits out there, we should have, you know, Dart APIs for them. You should be able to call them Dart. So, you know, that's basic. We're doing some work around, you know, in a future where let's imagine that AI gets, you know, orders of magnitude more capable than it is now, which is already very capable.

uh you could envision cases where you have kind of bespoke dynamic apps being created on the fly so we're doing some interesting work there very early experimental work around how you can use ai to do kind of like generative ui experiences which has a lot of potential if that really comes to fruition you know you could envision a world where uh on the web you have

You have experiences that are entirely crafted by AIs and Flutter becomes kind of the preferred UI language of AIs. So we're doing some early experimental work there. The Flutter team doesn't use AI to like, you know, do assistive coding right now. But it's also one of the things we're looking into is AI.

How to do assistive coding in AI. One of the things that I like to do from a strategy perspective is think about ways we can innovate and not just copy. So the assistive coding, you might notice I gave a little bit of hesitation to because there's a lot of already great work being done on like GitHub Copilot and that type of stuff. So I want to make sure that whatever we do is actually lending something new to the space and not just copying.

That's really interesting. And the idea I like with AI is that currently users need to figure out how to use their apps, whereas in the future, apps will need to figure out how to enable their users, or kind of reverses. Yeah, exactly. Which is which is exciting, but also I think changes can make developers a bit nervous.

Yeah, I mean, there's a lot of people out there that are saying, you know, are we in writing AI tools? Are we helping eliminate our own jobs? And maybe, you know, we'll see. We'll find out. Can you talk about, you know, you talked about with the roadmap, but the future of Flutter, where you see long term, maybe five years from now, where you'd like it to be? Yeah, I think our goal has always been and remains AI.

to make Dart the best general-purpose programming language and Flutter the best way to paint pixels, period. Because what we don't want to do is fall into the trap of saying, hey, since we're multi-platform, there's going to be huge trade-offs and you're not going to be as good as the native toolkit on iOS, the native toolkit on Android, or the hot framework of the day in JavaScript for the web.

And we've always kind of rejected that premise and said, no, we want to be multi-platform, but we want to be the best way to write for any one of those platforms. And we continue to chase that goal. So, you know, if I look out five or even 10 years, I see a world, you know, if we execute correctly and we leverage our community and whatnot, where Flutter is ubiquitous, right? I mean, it's still silly to think about, you know, building something twice or three times or four times, you're going to think about all the different platforms.

So why would you do that? Why wouldn't you embrace a multi-platform framework? And the answer historically has been the trade-offs just aren't worth it. So we're trying to make those trade-offs zero and say, look, you don't have to give up anything to get multi-platform. And in a world where platforms proliferate, I mean, we've got the LG Embedder and Toyota is doing it for all their in-dash UIs. You can envision new platforms spawning up.

And people say, oh, well, you know, crap, do I now have to hire a new development team or learn a new framework to build for this new platform? Like, no, no, you should be able to use Flutter. So as I look out, I think the future is bright for Flutter and Dart to just be ubiquitous. Sounds like a very nice future. Just to wrap up, is there anything else you'd like to add or promote? No, I think you covered all the rain topics. I, yeah, I mean, we just touched upon it, but I really think that the future is really bright here. And I really love, I continue, I mean,

Take a step back and say, you know, as we talked about my background that I've been on the Flutter team for, you know, whatever it is, nine years now. One of the things I like about Google is that it lets you switch teams, right? There's a built-in infrastructure at Google for switching teams every now and then. And that's common, right? Like you work on a team for a while, you want to try something new, like, and obviously it happens on the Flutter team. But for me personally, I

The fact that I'm still here is because I love, love working on this. It is a phenomenal team that works at Google. It's a phenomenal community and team of, you know, open source contributors and other partners. So I just think that this is the place to be. It's still hot and I'm looking forward to it. This is a great episode. Todd, thank you so much for your time, being on the podcast. And thank you for listening. Thank you so much, Alil. Thank you.