50. Eric Seidel
22:54 Share

Hi, thanks for listening. This is the It's So Wicked Flutter podcast. My name is Philip Korn. Each episode, you get a chance to speak with another amazing member of the Flutter community. Hard to believe this is the 50th episode of the podcast. I'm hoping to find a special guest, and I think we succeeded. It is my great pleasure to welcome Eric, one of the original creators of Flutter. Welcome. Hey, hello.

Hi, Eric. Thank you so much for your time, for being on this podcast. I also just thank you for helping create Flutter. I just want to start by, at least on behalf of myself and the community, just thanking you with a massive impact on my life and I'm sure thousands, hundreds of thousands, potentially millions in the future developers. It's awesome. I think Flutter will succeed just simply because it's fun. So thank you. To start, can you share your background before you joined Google? Sure. Yeah, so I started in tech

as a professional career a little over 20 years ago. Um, I ended up out at Apple as an intern, um, before I thought I was going to go off and do a PhD in cryptography. Um, but it ended up liking, uh, you know, Silicon Valley and the Apple internship a lot and, uh, managed to finagle my way into a full-time job in the fall. Uh, and I bounced around Apple for a few years, uh, did several different teams. Um, but I think where was most impactful to him for me, at least was my time on Safari. Um, and,

I worked on Safari doing, I brought SVG to Safari. I helped bring Safari to Windows. Got to work on performance and all sorts of stuff there. And then I left and ended a Y Combinator startup for a while. We were the second, third class at Y Combinator. We tried to sell clothing on the internet, which I cannot recommend. And then when that, when I burned out after about 15 months of that, I went and

I hiked the Appalachian Trail for a while and then came back to Techland. I got recruited into Google and did Crow. That's sort of my pre-Google time. Wow, very cool. I have to say, I'm a bit of a YC junkie. I'd love to know more about the business idea and why you think it didn't succeed. I mean, the biggest reason why our YC business didn't succeed is that we didn't

I think YC has really gotten good at this messaging since, but remember, we were so early. We were learning so much from YC, but YC was also just learning so much from us and our failures or successes in some cases. But I think that the big thing we didn't do that they're very good about telling you to do these days is we didn't build something people want. We didn't even build something we want. We imagined a customer and built a whole bunch of cool tech

Uh, but you know, without somebody actually wanting what we were building, it just didn't, uh, we never talked to our customers. And, uh, so in the end, you know, we just, we hustled for a long time and then flamed out. Um, or at least I did, I left the company. I know my, my co-founder continued on for a little while after, um, but I, I, I needed a reset after, uh, working nonstop for 15 months. It's hard. It's easy to burn out and it's a great lessons learned.

So you come to Google and I guess you didn't start with Flutter originally. I don't know if Flutter even existed then. Yeah. So I got recruited in to join the Chrome team. I remember the VP who recruited me told me that he couldn't tell me what I was going to work on, but that if I didn't like it, he would find me a job inside Google that I did.

Um, and, uh, I took him up on his offer. And, uh, then I, I heard about Chrome when, when I started my first day that that was the project I was going to work on. Um, and, uh, it was fun. You know, I, I was the first WebKit reviewer at Google. Um, so I helped, you know, boot Google's WebKit team.

And, yeah, just worked on trying to make the web amazing, which I had been doing when I worked on WebKit, you know, on Safari back when I was at Apple. But we just tried to make the web amazing. And I think, you know, maybe we'll get into this more later, but we eventually just realized we couldn't, at least under the structures of how we were doing web development in WebKit. And so we ended up forking WebKit to make Blink.

which was a project that I was, you know, deeply involved in, you know, planning and executing thereof. And then we ended up forking Blink again a couple of years later to make Flutter, which I can go into.

That would be amazing. I'll just say quickly, while preparing for this podcast, you shared a great video with me. I think it was the 100th episode of your podcast. We went into so much more detail about the history. I'm sure we won't get into all the details on this episode, but I'll put a link in the show notes. And I highly recommend watching it. It just gave a lot of greater insights into the development process, in particular why certain things were introduced and what problems they were solving. Yeah, so Flutter came out of...

In many ways, the same quest that I've been on for almost two decades now, which is I just want the world to stop writing the darn thing twice. And Flutter was the vehicle we ended up with. It was not the vehicle I had originally intended for that. I thought the web was going to win. And I tried real hard to make the web the best way possible.

To build application experiences for users for a very, very long time. And so when I was working on Chrome, there were many like-minded individuals nearby. But when we were working on Chrome, we had the belief that all of the apps on your phone should just be web apps, or almost all of them should be.

And one of the things we worked on was just trying to remove blocker after blocker after blocker to make that true. One of the things that we ran into time and time again as we did these experiments was performance.

It was really hard to get a web app that felt as smooth, had perfect animations, perfect pixels, was reliable in startup, et cetera, compared to a native app, at least at that time. Maybe the web is all better about this now. I've been away from the web for over 10 years now. But we tried on performance. It was also on fidelity. One of the projects that we did that led to Flutter

There were many, and as you said, we talked about the Summon in that old podcast episode. But one of the projects that led to it was that we tried to replicate pixel for pixel, gesture for gesture, animation for animation, Google Calendar at the time, and the Android calculator. So these were two Android apps, and we just tried to make perfect replicas on the web. And we found it just wasn't possible.

You couldn't get the animations exactly right. You couldn't have the perfect ink splash, etc. And it taught us that we eventually were going to need to build a different thing. And again, this was over many years, but it was that thinking and that pattern that led us to eventually Blink, to create this fork of WebKit that Google was to use for Chrome. And then again,

to fork Blink to make Flutter. And Flutter was not intended to be a separate thing. It was intended to be a... Originally, when the project started, it was called Razor.

And the intention of Razor was to literally take a razor to Chrome and cut away all the old parts of the web that were slowing it down. Because remember I said one of the problems with making these good apps was performance and getting a consistent good performance from your web app. And so we took a razor to Chrome and we cut it to pieces and we deleted all the old slow stuff, you know, that hadn't been used in 20 years, but was making the

the web super slow. And we moved our benchmarks 20 times. Or rather, I should say, we made our benchmarks 20 times faster. And that was enough to prove to management at Google that there was some there there. And we went off for a while exploring if you could just make a doc type fast. If you could sprinkle some little bit into your HTML page, and that would just turn off all the slow parts of the web.

and give you a fast mode. We explored that for a while. That was what the Razor project was. And eventually we found that we had to delete some parts that then we needed to add something back. I think text editing was the main culprit of this. And as soon as we had to add something back, we knew we were no longer working on the web, or at least we weren't working on something that could be the web for many years. You have to go through the standards process whenever you add something.

And that caused a fissure in the team. And about half the team went back to work on Chrome. And the other half of us stayed on to build a new thing that was no longer the web, but could do real high quality multi-platform experiences for building apps. It's a pretty incredible story. So what was the experience like managing the Flutter team? I assume at the beginning it was a very small team of people. Over time, it grew to hundreds of developers.

Yeah, so Flutter started out, initially we were about six of us, I think, who left Chrome to do Razor. And then again, about half the team left, we were down to three or so. And then there was a raft of, you know, babies born and paternity leaves that happened. So there was a time when it was only a couple of us in the office or one of us in the office for a while. Yeah.

But, uh, so yeah, we started out as a very small team and then we grew, uh, into well over a hundred people between, uh, dart and flutter. Um, and yeah, it was a lot of learning how to manage for me. Um, yeah, I, I had done a lot of technical leadership, but I'd not done a lot of people leadership and you know, you, you read a lot of books, you go to a bunch of classes, you, um, you just, you just figure it out. Um,

But yeah, that's a Flutter. Flutter's taught me a lot of things, but that is one of them is how to take care of people. Uh, even when there are lots of people to take care of. Nice. And then how long were you with the team for? Uh, Flutter started October 2014, I think I should know this date, but it's September or October 2014 was the very first commit. You can find it publicly on GitHub. And then I left the team, um, about the same time, 2022, uh,

And then I started my current company, Shorebird, in about January of 2023. So I have to say, it was sad to see you leave the Flutter team, but at the same time, seeing that you're staying within the Flutter community, it's very reassuring. So I'd love to hear more about Shorebird. Do you want to take time and discuss it? Yeah, so Shorebird is an answer to many of the questions that I couldn't answer when I was leading the Flutter team.

Uh, so first of all, I should say, what is it that we do? So Shorebird right now builds code push for Flutter. Code push is a way of updating your application, pushing an update to your application in the field. So all your users have it immediately, uh, without having to wait for them to press an update button, et cetera. Uh, this is a technology or a vein of technologies that, that all the large apps use, you know, the TikToks, the Facebooks, the YouTubes, et cetera, of the world, um,

And exists for other languages and platforms. Obviously, the web works this way, but did not exist prior to us making it for Flutter. As I said, ShortBridge is an answer to many of the questions I couldn't answer when at Google. CodePush was one of them, actually. We regularly would get questions for CodePush. There were actually several questions.

Our implementations, our variations on CodePush, different technological bases, but same idea that we had made at Google, but then never shipped or only shipped for internal Google apps. Another big question that kept coming up for me when I was leading Flutter was that I would constantly get called into these sort of cloud sales meetings.

which was, I think, the only vehicle effectively for a business to have a meeting with Google that they wanted to buy something was to have a cloud sales meeting. And very often in these conversations, the person on the other side of the table wanted to sign a contract with me, as in they wanted to sign a contract with the Flutter team, which was just not something Google does. And those are decisions way above my pay grade. But I wanted to build an answer for those businesses who wanted to have

a business relationship with Flutter. When you're a business and you use Linux, one of the ways that you do that is you buy Linux. You go to Red Hat and say, I want to use Linux and I want you to support me in that endeavor. And the same is true for lots of other technologies. But that doesn't exist for Flutter.

And people kept asking me for that. And so I'm here building the Flutter company. And I say that not to be exclusive, but like a company that hopefully ends up synonymous with Flutter and trusted as a way for you as a business to use and consume Flutter and get the products and support that you need to be successful.

That's great. I'll tell you, while doing research for the episode, I googled Flutter CodePush and Sherbert as first result. Definitely have dominance on that feature and maybe other features in the future. Other plans for the future you can share for development? Are you thinking about desktop support?

Yeah. So a funny thing, we ran Flutter almost entirely in the open, or as much as we could at Google. And we run Shorebird entirely in the open. So if you ever want to see what we're working on, or what we're planning to do, you can just hop into our Discord and you can watch us discuss it. You can read our plans on GitHub. So there aren't a lot of secrets. In terms of desktop support for CodePush, we're definitely going to do it. It's just a question of focus.

So one of the things that I've learned in building teams and building products is that you have to have a small working thing before you can have a big working thing. And right now we're very focused on the small working thing, right? A very restricted product that only works on iOS and Android and trying to make that amazing. And then moving that to Windows and Mac and Linux will be very easy when we get there.

Nice. Generally, while watching YouTube videos, compared frameworks, one criticism often leveled against Flutter is a lack of Copish support. I think part of the challenge is just educating the community. People are aware that with Shorebird, Copish is actually supportive of Flutter.

Oh, I, I can only underline that a hundred times. I will tell you that by far our biggest problem right now, and something that you and your listeners can help with is that I think 90 plus percent of the Flutter community does not know we exist, right? So Flutter has something on the order of a million monthly active users. Um, I don't know what the exact number is, but you know, it was, it was on that order of magnitude when I left and Google has talked about that similarly before. Um,

Maybe 50,000 people know that we exist as Shorebird. And so my challenge right now is to reach the other million Flutter developers. And obviously beyond that, I would love to reach many other developers. But let's start by reaching all the Flutter developers. Very cool. And does the pricing make sense if you're a small developer? Are there stream plans or plans for a smaller app or a larger app?

Yeah, so Shorebird Copush is free. For... What we sell is actually the distribution of patches. So...

If you're a small developer, we give you 5,000 installs of a patch out of the box for free. And then we have, I think, a pretty generous step up tier from that where we add team support. So if you want to have multiple collaborators, for example, and then we give you 50,000 patches for $20 a month. And then our pricing scales from there. But yeah, we're essentially selling network delivery of these patches.

We give away the software to build them for free. Nice. Sounds very generous. And then one other area I'd love to discuss is Flutter in general, its current state and where it's going in the future. Like many, it's oriented to Google I.O. It's seen relatively little attention given to Flutter. That said, you see in the community amazing development. Do you have any insights you can share? Yeah. I am super bullish on Flutter. And it comes from a lot of reasons, but the biggest of which is incentives.

So I have been on the same quest for multiple decades at this point of helping the world stop writing everything twice. And I just believe that when we step back away from all the platform companies and the platform companies' incentives to have a winner-take-all game of you only write for them, we step back to what are the incentives that drive the businesses? Businesses want to be able to reach their customers wherever they are.

whatever screen they're using. And just like we saw with the web in response to desktop, where suddenly it was better for a business to be on the web than it was to write a Windows app, I think we will eventually get there with other screens, including mobile. And so I see the future for multi-platform, of which I think Flutter is the best vehicle we have, as being very, very bright.

In terms of your original question of Google's engagement with Flutter, I can't speak for Google. Obviously, I've been away now for a couple of years. My sense is that Google is very focused on AI at the moment, at least in their public messaging. And

you know, that probably just crowds out other things that they might talk about. I think that we're going to continue to see lots of great work from the Google Flutter team. There's lots of amazing people there. I also think we're going to start to see more and more amazing work from other parts of the wider community. And I mean, in part of that, just

Some of the big players, I think, are starting to get to the point. And by big players, I mean people with tens, if not hundreds of Flutter developers are starting to get to the point where they have the Flutter knowledge and experience and infrastructure to really contribute in bigger and bigger ways to the direction of the Flutter community.

And I think with big adoptions like, you know, so we saw LG recently announced that they were moving their smart screens to Flutter. We saw MGM announced earlier this year that they were moving all their parks to Flutter. You know, we saw, you know, I guess it's now been a couple of years ago that Toyota announced that they were moving all their cars to Flutter. And there's been lots and lots of other examples of that that haven't been as widely announced. But as we see these larger and larger companies move to Flutter, I think we're going to see

interesting pockets of Flutter and multi-platform related innovation that are not just going to be from Google. I think the future of Flutter is maybe federated is the wrong word, but it's certainly wider distributed than just Google Teams. And I think we're just starting to get to that.

I couldn't agree more. It's incredibly exciting to see. But one thing that personally I love about Flutter is how clean the errors are. It's easy to write code that works, challenges to code when it doesn't work. Other platforms available. However, they all have the same problem with leaky abstractions, whether layer upon layer, whether it's Java and another layer, JavaScript and another layer. And when things go wrong, it can take so much time figuring out where the problem is before you have a chance to fix it. I find with Flutter, 99% of the time, it's a Dart error. But I don't think I've ever seen a C++ error

It's that cleanliness that makes the developer experience I find so pleasant to work with.

I mean, I think this came from some very fortunate choices and happy accidents that happened early on. I mean, Flutter, again, comes from the web. It was written in large part by people who had worked on the web like RTL for a decade or whatever. It was Ian Hickson who wrote HTML5, right? He was just steeped in the web and all the web's mistakes and good parts of the web and sort of

had a very strong opinion as to how things should be designed. And similarly, you know, Adam Barth and myself, you know, we're developers. We've been developers forever. And we cared a lot about the developer experience. Yeah, it just, I...

It's never one person, right? You know, Flutter was built by hundreds, if not thousands of people making, you know, good, helpful choices all in their own little way. But I do think that we had the time and the space. We were lucky at Google to have the time and the space and the funding to lay some good initial layers. And then, you know, just over the years, people have built really nice things on that foundation. Well, it worked out well in the end. Congratulations. Is there anything else you'd like to add or promote?

Yeah, I guess I just, I mean, I would be wrong not to promote what we're doing today, right? So we are, I left Google and we're doing Shorebird. Shorebird is trying to be Flutter for business, right? We're trying to be your source of Flutter products over time. The product that we offer you today is CodePush, right? So if you have ever had the experience where you have had something go wrong in the field,

And you've then been painfully waiting for all your users to update and stop, you know, calling your support lines or or stop, you know, hitting your servers with with with buggy, you know, client protocols or whatever.

you don't have to have that problem anymore, right? We have the same technology now that all the other big boys and girls, you know, apps do. We have the same technology that all the other languages do. We have now a code push solution, which we offer at Shorebird, and you should check it out. Eric, thank you so much again for being on the podcast. Thanks for having me. ♪