[00:00:00] Introduction
Eric: Blink was whiskey and frustration, mostly frustration almost tears giving up on this idea that we could actually make web kit do what we wanted. the same thing happened with the web. Flutters started not to do flutter. We were not trying to build a multi-platform toolkit. What we were trying to do is build a fast mode for the web.
Andrew: Hello, welcome to Dev Tools fm. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my cohost Justin.
Justin: Hey everyone. Good to see you again. It's been a little, little bit since our last episode. We're excited to have Eric Seidel on with us. So, Eric, you are the. The brain or one of the brains behind Flutter which is such a cool project. And you also worked on Dart which I have so many questions about.
So I am incredibly excited to chat with you today. Before we dive in and talk about what you've been doing and like these recent days, uh, would you like to tell our audience a little bit more about you and like what you've done in the past and how you got to where you're at?
Eric: Sure thing.
[00:01:09] From Apple to Google
Eric: So yeah, I am a Midwestern boy who ended up out in California. 20 years ago to work for Apple and ended up at Apple, then ended up on Safari, did web browsers for a very long time. Ended up YC back in oh six, long, long time ago. Had a. Failed fashion, social network that I built with a friend.
And um, then went to Google, did Chrome, um, did WebKit there, started the Blink project there, then started Flutter led the Flutter team and later Dart. And then I left there about three years ago to start. My current company Shorebird, where we are trying to take flutter further than I could at Google. Um, and we build a code push product, lets you update your Flutter app without. Waiting for the stores.
Andrew: Yeah, quite, quite the long resume there. Lots of foundational technologies that have defined like the past 20 years or so. Can you, can we start at the beginning and what got you into browsers at first and what were like some of your major accomplishments that you added to WebKit early on? And are they still there today?
Eric: yeah, a surprising number of them are, um. Apple takes a apple's very good at simplicity, which is great. And so yes, some of the things that I I made are still there. So how did I get into browsers? I got into browsers very unexpectedly, unintentionally. I was not trying to get into browsers.
I was a UI engineer at Apple working on sync services sync services. This is. Predates the iPhone, right? So you would hook up your Palm Pilot to your Mac and it would sync your contacts and tell you that you have two copies of your Aunt Linda and one of them has the wrong middle name. And then my UI would pick would show up and let you pick and all that stuff.
Obviously all that tech has long since removed. But I was working on that team and this was the end of Leopard Snow, leopard Panther, something like that. And Apple gave us a month off. Um, where we were still working, but we could work on things that we thought were interesting, thought were important.
We sat right next to the AppKit team. So we went to lunch with them and they had all these cool demos about how you could build a, a, a text editor in five minutes or whatever. And I wanted to build a, an illustrator. Kind of Like a simple sketch app in five minutes. But in order to do that, I needed a drawing framework.
In order to do that, I needed a fi, a file format. Uh, And so that introduced me to SVG. I found SVG, and then I started writing a SVG framework for Mac. I wrote, I think it was SVG Kid or SVG Core or whatever in this, you know, one compressed month. I wrote it all in objective C. I got a couple weeks in.
SVG is stupidly complicated. It's a little better these days, but like back then they were working on SVG 1.2 or something. You fricking had a, like a, a networking stack inside your, your, your graphics rendering a socket api. It was crazy. Anyways, so I, I had started implementing just a, I. Basic SVG. It was too complicated.
I went looking for an existing implementation. I found KSVG from the KDE project. I ported that to Mac. Rebuilt my system on top of that. And then it was, and then I demoed this to our VP at the time. This was at the end of this, you know, one month thing. Got forced all and he was like, this is great and all, but we shouldn't ship this as a framework.
You should go work on Sari. And suddenly I was on the Safari team and was then asked to own XML. 'cause this was like, we were like, I don't know what, 10 people, 15 people or something like that. It was very early. I was owned, asked to own XML. I did work on XML HT P requests and XSLT processor. And then I did performance related work and did a bunch of bot and testing stuff for them.
I helped start the windows web kit project. I like literally created the Visual Studio Code project or the visual Studio was Visual Studio. Visual Studio Code didn't exist at the time. Um, Project. It was, It was um, you know, young, ambitious uh, 20 something who was just floundering their way around uh, apple at the time.
And I got dumped into the web and I, I really enjoyed it. And then I, I left Apple again being a young ambitious 20 something and thought I should start a company. I ended up at Y Combinator 'cause of the startup school stuff that Paul Graham coming, giving talks at Stanford. Which is just down the street from Apple or just, 10 miles away or something from Apple. And uh, went to that talk, met my future co-founder got sucked into yc, left Apple. That was a very interesting learning experience of 15 months of not having any idea what you're doing. Banging your head. Back then Y Combinator, they gave you a whopping $18,000.
Andrew: Wow, that is so little. That's
crazy.
Eric: and these days they give you half a million or something like that. But yeah, no, it was like 7% of your company for $18,000, which was up from 12,000, which was the previous batch. And uh, yeah, no, we lived off of my Apple savings and tried to build a, we first built a fashion search engine. We, we connected to. I dunno. Banana Republic and think nascent Amazon kind of stuff. And built like a, something that Google did better with like Google shopping many, many, many years later. So we built that and that didn't go anywhere. And so then we built a fashion filter network. I have no idea why we're doing fashion 'cause I am not a fashion forward kind of guy. And we actually had some customers not paying customers, but people using us. Etsy was really new at the time, and Etsy people needed a way to show off what they were selling. And Etsy has much more sophisticated tools for that these days. But they would use our, our like closet and they would use our collage tool to do that. Um, But we never talk to our users and the big user from all big. Big thing I learned from all that, which I would say to your dev tools listeners, is talk to your users. We never talked to our users and so we never built something people wanted and that flamed out after 15 months. Um, And then I got recruited into Google I, thought I was gonna go back to Apple.
I was not probably literally living in my parents' basement, but pretty close. At the time after my yc I went and hiked the Appalachian Trail. On a whim was out there for three and a half months, recentering in the wilderness. But then I came back to my parents' house and thought I was gonna go back to Apple and ended up getting recruited into Google instead. Uh, kind of On a last minute, the VP in charge uh, at the time uh, Linus Upson took me and, and sat me down and said, I can't tell you what you're gonna work on, but if you don't like it, I will help you find a job that you do like inside Google. I was willing to take that bet. Then it turns out he was building Chrome. Uh, he and Sundar were building Chrome. It was awesome. I came with all this WebKit experience. I was a, a senior reviewer in WebKit. You know, Your startup's going wrong when you start doing your old job and when, when the startup was, was
going wrong, I started working on WebKit, you know, for fun. Uh, And so. Then I got to do it for full-time at Google in the early days of Chrome. And uh, yeah, that was just a blast. We uh, you know, it was, it was another learning experience as a, as a developer. I came in, I was pretty senior senior in my mind, I guess, uh, I was asked to update their web Kit Fork, which was like two years old at that point, to being, closer to Tip a Tree. And I did. But I took the like long way, the like correct way and I took their patches and I upstreamed them. 'cause I could do that as a, as a. As a reviewer. But I just, I got in over my head, you know, I bit off more than I could chew, and another senior engineer had to come rescue me. But yeah, no, it was a, it was a whole experience.
And then that led into that led into many years of working on making Chrome viable on mobile. Uh,
[00:08:38] The Birth of Flutter
Eric: One of the things that eventually pushed towards Flutter was that we. A whole bunch of us inside Chrome just really believed that all these app experiences that we had on the most important device, right?
So this is like early 2000 tens, right? The most important device is these iPhones and Androids in our hand. And they were all writing in these terrible old Java, terrible old objective C stacks, and we just believed it should be the web. But then we tried, we put our money where our mouth was and we tried and you just couldn't do it.
This is actually pretty close to when Flutter was started, so several years down the layer, down the line from this. But we tried to build the Android calculator in web technology and you just couldn't do it. You couldn't get the shadows perfect. You couldn't get the ink splashes perfect. You couldn't get the drawer perfect. We tried to build the calendar. You couldn't get the parallax perfect. You couldn't not have jank in the scroll. And maybe that's all been fixed 10 years later but that is why we ended up going down the footer route, which we can get into, is that you just couldn't make the web good enough.
You couldn't build good enough apps with the web. And we believed that was the right way to write was with these portable technology stacks.
Justin: Yeah. So at that time, were you like, so. iOS definitely was like locked down is to this day, I guess, to like Web cat safari. So you had like limited control over like what you could do with on the iPhone. Were y'all like using, what tools were you using at the time to try to build apps pre flutter?
Was this like, was this around the like phone gap Cordova days? Were y'all doing something just special internal, like what?
Eric: I just remember that us on the Chrome team. know, So I don't know how much of this ended up, but there were lots of experiments to build a, like a web, first phone not just at Google, but I'm sure lots of other people were. Obviously Microsoft did this right. And Google had some dabblings in that space too. But even if you build web first, even if you build, the ChromeOS equivalent on the phone, um, you just. You couldn't, like we, we spent so much time during this era, and again, this is over a decade ago now just getting JavaScript off the main thread, right? Or just getting so, so getting everything else off the main thread so that JavaScript thread could be your thread, because it used to be back in the time that like the Chrome networking stack or the Chrome font parsing stack or whatever would just wake up in the middle of your animation and you would just drop frames and your only other option was to use CSS animations. Cs s animations, once you start 'em you're done. Like you can't interact with them. There's no catching that drawer. There's no like grabbing it and, and, and scrubbing it. And so those were your two options, jank and js or have no control in CSS and we just believe there was a, was a better way. And so we tried lots of things like, before we got to the Fluter stuff, which we, we took a more radical departure, but we tried. What if you just took, js and you gave it some GL bindings and drove everything that way. But unless you like, rip out the rest of Chrome, you still have the like, oh well, the font parsing stack woke up in the middle and caused me to Jan. Like, I remember working a lot with the inbox, team inbox.
If you, it was a, this is many years ago. Um, It was an early attempt at like a revolution on, on uh, on Gmail. I remember working with the inbox team and they just had the most basic problems. They were not their fault. They were just like, my thing, Jens in the middle of this animation. Why? And it's like, well, you're using an inline script tag and so we're parsing the script as you go, as opposed to like deferring that part. And this is why we, we rewrote the h ML five parser. Well, I mean, We rewrote the H ML five parser, which was one of the things that I did while I was working on Chrome. Um, because You couldn't understand the existing parser, so you couldn't know if it was correct or what it was doing. And so thankfully Ian Hixson and H ML five and the what wg tried to write a spec.
This is how we, the HTML should parse. And then when we implement that, once we did it, then we could change the parser. We could fix those bugs. And so that was a lot of the journey. I, I think we skipped to some steps here, but this was a lot of the journey after blink. So when I was at at at Chrome, one of the things that we started, in part so that we could fix these mobile bugs, but a lot of it was just actually process.
What had happened is that when we had worked with Apple, when we had collaborated with Apple over WebKit, Chrome got so large, Chrome got, I think at its peak. The whole Chrome organization was close to a thousand people. And not all of us were working on the the core web browser, but still there were probably 30, 40, 50 people who wanted to send patches up to WebKit. And that's larger than the entire Safari team, at least it was at the time. And so we just had this funny setup where Apple was in charge. They, ran WebKit, understandably, you know, by fiat or whatever, like they were in charge. It had to go through their, their approval. There was a reviewer system and all, but like for, certainly for big controversial things that needed the Apple stamp of approval, and again, makes total sense.
I would probably run the, the, the project the same way, but that was a point of large friction for something as large as Chrome, where it's like we got 40 people trying to write patches and they're all having to squeeze through this tiny, does the Apple team wanna review it? Constraint.
And so that was part of what drove us to Fork Web Kit. Uh, This is another one of the things that I did while I was at Google, was myself and some others. We forked web kit to make the Blink project, which is Google's own fork of web kit, which has now been integrated more properly into Chrome. And it allowed Google to take Chrome and move it faster.
Justin: That's, uh, you've been on such a part of like this in Incre incredible history of like, not only the web, but like of this era in Silicon Valley, which I feel like is very special. So what was your sort of transition from like. I'm sure this whole time you were stewing on like, man, I really wish we could have made the web work on a phone or like, it's like when you're in that world, you just like are, are sort of like web maxing.
You just like really want it to apply it everywhere. So what sort of process led you from like really thinking about that's like, all right we need to do something radically different. Like we need something like what becomes flutter?
[00:14:51] The Evolution of Flutter and Dart
Eric: Yeah. I'll tell you man, it's a process like the, when we did blink. Blink was whiskey and frustration, mostly frustration almost tears right in, in that, like giving up on this idea that we could actually make web kit do what we wanted. And the same thing happened with the web. So the web was maybe a little more gradual.
Flutters started not to do flutter. We were not trying to build a multi-platform toolkit. What we were trying to do is build a fast mode for the web. So Flutters started the project. The code name at the time was called Razor and we were literally taking a razor to Chrome. We were just cutting away all the slow bits 'cause we had worked on this thing for a decade at that point and we'd realized that so much of the web is death by a thousand cuts. You When I left the web, and this is probably still true today, there is like a single if statement in the deepest, hottest part of text rendering. That all exists because there's five websites on the internet that at least used to maybe still do lie about their RTL ness, right? So they actually give you LTR left to right text, but in a right to left, uh, context and like, there has to be a way to like override that and like it got hacked in at some point, who knows, whatever.
But it like slows down every page's text rendering by 1%. You know, Last time I measured again, that's a long time ago that I last measured. That's not the only one. There's a thousand of these things. And so Razor was a well, what if we just cut out all the, the stuff is, is there like a, a golden nugget in the center of this thing? And so we did that and we just started cutting away and cutting away. And after two weeks of cutting away, we had made some of the benchmarks for Chrome 20 times faster. Not 20%, but 20 times. And so that was enough to get the attention of the then CEO and the next gen slush fund sort of stuff.
And we got some funding through that. And six of us left the Chrome team to continue to explore. Could we just have a duck type fast, you know, or some way to just like, cut out all the junk and use a a, a rendering engine that's much simpler. And so we cut and we cut and, this is where the break happened was that eventually we realized we'd cut so much that we had to add something back.
I think the thing that might have triggered it was that we had, we'd cut away all of the exec command stuff. If any of you ever worked on the deep bowels of text editing on the web, it's all this like weird API that Microsoft came up with a nineties called Exec Command and we cut away all of that. But then we still need to be like. Type, type characters into a text field. And so you have to add something back. And so we imagined some stuff, but then what we had imagined was at least three years away from being the web, right? Because even if we had done a perfect job, it still was gonna go through standards, committee approval process and all that stuff.
And, get to, can I use being green and all that? We just realized and this fractured the team and was another, like tears and I dunno how much whiskey was involved, certainly tears moment of okay, we're not going the web anymore. We're not working on the web. And half the team left you know, of those six, three of them went back to the Chrome team and. Maybe two of them went back to the Chrome team, and then a couple was more of us continued on until we hit another blocker where we realized that we couldn't even, so again, this was fast mode. So the early days we moved from the razor experiment to a thing that we called Sky. We named it Sky 'cause I don't know, it was a name we knew we could never keep.
'cause there was, sky TV in in, in the uk, but we named it Sky. And we wrote three versions at least of the framework in JavaScript. It was still served over HTPS. It was run locally. It was Android only. Um, at The time. I mean, there's, There's demos of me showing this uh, online on YouTube of this like HT P based. This, you know, remote loading based framework. Um, But eventually we um, eventually gave up on JavaScript, not because JavaScript's not awesome. I've worked on JavaScript VMs before. You know, JavaScript's a, a great language, but just like your last guest was trying to solve JavaScript doesn't a OT. And we we had hit this point where we had started to work on iOS as well. And we took our thing and we would run it on iOS and it would take 12 seconds to boot because we'd written so much JavaScript and JavaScript. So what a OT is is ahead of time compilation, right? And so the way that your. Stuff on your mobile phone works is that when you click on an icon, it just loads up where the code starts and just starts executing on the CPU, which is different from how JavaScript works. JavaScript and all these interpreted, or just in time compiled languages, they have to first parse it all, they have to compile it all, or maybe they have to interpret it all and there's ways to make it, you know, fast ish. But um, it's still not as fast as just, I'm gonna just start it. Offset Zero and go.
And so we needed a language that could a OT. And so we eventually left JavaScript and we rewrote in Dart. And Dart at the time was super close to JavaScript because Dart had been written by the same team as wrote V eight. And the same team had wrote in hotspot for Java before then. And so when we transitioned to Dart, it was funny, it was months later that we realized that we hadn't even updated all of our unit tests. To be Dart syntax. They were still just JavaScript syntax that was parsing fine. And Dart. And Dart and JavaScript have evolved since that point in time. But back in 2014 or 2015, they were very similar languages or more similar than they are today. So we successfully transitioned to a language that had both just in time compilation for really nice developer experience, as well as ahead of time compilation for really nice deployment experience.
Andrew: It's interesting to see how like the field is moved in similar ways, like in parallels.
[00:20:46] Comparing Flutter with React Native
Andrew: Like I myself haven't done flutter at all, but a lot of the stuff you just said reminds me of React Native. Like they've done an incredible amount
of work to make things like feel like a OT with the Hermes engine and all of that stuff. So it seems like we're all just solving the same problems over and over again.
Eric: Oh totally, totally. Yeah. I have a lot of respect for the React native team. We used to have lunch with them on a regular basis. The fundamental difference there is that React is taking an approach that browsers used to take. So way, way back in the day, browsers used to have native form controls. Again, I don't know how, this may be too old for some of your audience, but like back in the early aughts um, browsers used to have native form controls. So when you clicked on that button, it was actually an aqua button. And when Safari was running on Windows, it was actually a whatever, a win 32 button, right? And browsers just saw no end of problems as a result of that because you go to a website and it'll have a thousand buttons on it, and it'll just crash. Or you go to a website and it expects that the CSS should cascade into the button and it doesn't. Right? And so this was a thing that we went through in the, in the early aughts, was like figuring this out and, oh, maybe we should have CSS form controls and form controls should look like what the author wants as opposed to what the platform wants.
And um, and you know, this even caused security problems for browsers. 'cause like you, when you're displaying something that's drawn by AppKit. Which is max UI framework, not by Safari. You could like, could cause AppKit to crash in weird ways under the covers, right? And so browsers transitioned away from that to just bringing their whole stack, which Firefox was a pioneer of.
But then all the other browsers eventually followed suit where like Chrome doesn't use or maybe it does these days, but I don't think it uses, core graphics on iOS. It just brings Skia. Along with it and talk straight to the GPU. And so like the difference the major difference between React Native and Flutter is that React native is understandably taking the approach of no, no, no, we're gonna use core graphics. We're gonna use the, the, the button that's already here, assuming you have a button, we're gonna use that button. Whereas Flutter is gonna be no, no, no, we're gonna bring all of our own buttons. We're gonna function much more like a game engine does. And it's sixes and sevens. There's, There's trade offs to both.
Justin: the seems like. Rebuilding the whole graphic stack for a UI framework would be a challenge. Maybe understating that and, you know, especially when you talk to folks on the web about uh, I guess like a common product surface area that folks will work on as like a canvas. And you may literally take the HTML canvas like feature for an ocean.
So if you're building an infinite canvas, you may use that feature. You may build or emulate it. Just using HTML and there are certainly trade offs to both approaches. And one of the biggest things that sort of crops up in these conversations is like accessibility in these surfaces or in trying to, bring some of the features that are like.
You can just rely on in the web that, you know, have been built up all of all these years, all these extra capabilities. So when you're, starting to really shape like what you thought flutter was gonna be in those early days and thinking about capabilities, what were the things you're like, okay, we absolutely must do this because like, the web has shown us that this is invaluable versus like, we can just not do this and that's okay.
It's like you have to make this trade offs. Like what were, what was your guiding direction there?
[00:24:07] Designing for High-Quality Multi-Platform Apps
Eric: So Flutter was all about the ceiling. Flutter was all about making it possible to do anything your designer wanted to do, which we were trying to build multi-platform, high quality, multi-platform that was good enough for Google, right? So Google had a whole bunch of weird, bespoke ways of sharing code between. Some of its different large app surfaces, but there wasn't like a, we should use this for everything. There were teams that wanted to use the web, but then they ended up with a poor result. We wanted a thing that could produce amazing results, that had perfect accessibility, perfect graphics, perfect animations, the Google Quality apps, and also be portable. And so that's what Flutter was designed around. So the answer, would we do accessibility and all that we did all. And what gave us confidence that that was possible. It was browsers, right? So we'd worked on browsers forever. We'd done the nuts and bolts of browsers and like browsers have to do perfect accessibility.
We can argue about whether they do, but they have to do perfect graphics. They have to do perfect performance. Right. And again, our experience had been, it not had been that the browser itself and all the ancient compatibility in the 30 years of cruft, that was what got in the way. But so we knew that it was possible. I will say with one caveat, which is iOS. Right? So iOS, because they do not have a second browser, they have never exposed these APIs. So if you go to GitHub, if you go to WebKit, there w there is a there is a whole folder of things they call SPS system private interfaces. It used to be one file when I worked on it and we at the time had the value of trying to like, make that file as small as possible.
'cause these were clearly holes in macOS that we should expose for all other apps to be able to use if Safari needed them. Shouldn't these other apps. Now these days it's just folders and folders and pages and pages of just, these are all the private APIs that it takes to make safari possible that you as a common developer cannot access. And so Flutter does have that challenge on iOS of that, until the US government or somebody else, you know, steps in, you can't access these things that like Apple can. Um, And so. we have to fake it. Um, Whereas on Android, because there are third party browsers, they generally expose all the things you would need to do to have perfect accessibility.
Andrew: So building cross platform, like we, we left the web behind and left its challenges behind for I'd say probably a host of new challenges. While we can build for all platforms at once, they offer different experiences. An iOS app feels a lot different than an Android app and they feel a hell of a lot different than using a website. So how did Flutter deal with that? Like I have a drawer or a sheet on a mobile app. How does that translate into the full fledged desktop or web app?
Eric: Yeah, so I think you're right. And Flutter has always focused on the ceiling, right? Making it all possible, not necessarily the floor, which is making it. Trivial to do. And I think that there's a lot more work that we could do in the flutter world on the floor in terms of that multi-platform adaptive experience. We focus so much on making on the ceiling right, that if you go to desktop, you should be able to get perfect desktop experience. If you go to Android, you should be able to a perfect Android experience, but it can require a lot of work. And I think that comes out of Google culture. Is that like Google is just. Brimming with amazing engineers. And so as long as you give them a tool that can get them where they're going, they're gonna get there. But yeah, it's a, it's a challenge, right? And Flutter provides you many of the pieces, not always all the way stitched together. Like This is the, the Cupertino, you know, we provide you. It turns out it's really easy to make a perfect replica of a iOS switch control and amusingly. When we, When we started the project and we were, perfectly matching the switch, we found bugs. iOS is switch control. Um, you know, I don't know whether they fixed them since, but like those parts are easy.
What's hard? What hard can be to make it easy for developers to get that to put the iOS switch control in the right place and use the iOS navigation on in the right place. And Fluter does have some affordances for that, some of these adaptive controls, but I think there's a lot more we could do or a lot more the community could do. And this is one of the things I'm excited about with my current adventure with Shorebird is that the incentives for the Flutter team. Flutter team is wonderful, full of all sorts of great people, and Google's been an amazing steward of that product. But the incentives are all around making Google teams successful with it and not stepping on Android's toes and you know, other things that would, would detract from Google. And less about the how do I make you. Andrew, a developer, successful for your business needs because your business needs don't get me promoted on the, on the flutter team or inside Google, right? And so that's one of the things I'm excited about fixing with, with my current company, is how do I align those incentives so that like when you are successful, Andrew, or when you are successful Toyota.
Toyota for example, I believe it's this model year is rolling out with footer across all of their vehicles, right? So. In a, In a shorebird first world, shorebird should be extremely thrilled about that. 'cause Shorebird's making money from that. But in a flutter world, is anybody getting promoted in the flutter team when that happens? I don't know. And so that's not good or bad, it's just, it's a demonstration of the misalignment of incentives that I'm trying to fix.
Andrew: Yeah, that seems to be a common property of Google projects. So for example, I'm on a platform team and basil is a thing that we interact with a lot and it seems like it's almost in the same world of like it's been put out, but there's a lot of. Stuff inside Google that makes that a very productive tool, that there's no incentive for anybody to share widely.
Eric: A hundred percent. Yeah, I mean, I, again, I have nothing but great things to say about the Flutter team or the about the Flutter project. I really do believe it's the right technology stack for us as an industry to be moving forward on, which obviously always needs more work. But as an example, doing JSON in Flutter is kind of awkward, which is like a weird sentence to say in 2025, except for the fact that Google doesn't use JSON. Google uses protos, so like. again, like it's important and people recognize it's important, and all the hearts and minds of the Flutter team who are some of, are listening to this, right? They're aligned with this and they believe in that, but like again, somebody got promoted probably for the amazing Protobuf package, is somebody gonna get promoted for the amazing js ON package?
[00:30:38] Building Shorebird
Justin: So let's talk about shifting to Shorebird and what you're trying to sort of what your North Star is, what your goal with this company is. You'd sort of mentioned, going, moving from Apple and working on WebKit and then going to Google and working on WebKit and like Apple, having control of WebKit and, caring a lot about that project and wanting it to succeed and like building, chrome on that and the sort of like challenges you had with that interface. And I, I'm interested as you're moving into this company where the company is based on Flutter and the core technologies around that, but this is, flutter is still a Google project largely. And I'm curious about like yeah, where are you trying to go and how is, how are, how are you thinking about the interface at this point?
Eric: Yeah. So the first thing that we're trying to solve is we're trying to fill in the pieces, right? So one of the things that, the incentives that we were under, that I was under as leading the flutter team was to build a piece that fit in Google's puzzle, right? Didn't overlap with too many other pieces or cause conflict with too many pieces.
And, worked with Google Technologies, right? And it was good, but I think that you have a different puzzle. You, Justin, have a different puzzle than, than a random Google engineer does. And so, uh, the first thing that we're trying to do is make sure that the, that the set of stuff that you need to be successful, as you Justin, with Flutter is there. And the first hole that we sought to fill was the number one most up footed issue of all time across Flutter and one of the most upvoted across all of GitHub. Um, Which was missing code push. For flutter. So code pushes the idea of being able to update your code instantly across all your users, just like you do when you push to the web, just like you do when you push to server, just like you do with honestly any normal development environment.
It's just we've somehow acclimated to this idea in mobile that all of our teams are just gonna be like NASA, where like we prep for many months and then we bottle it up and send it to Mars and hope that when it gets there in three months, it's gonna work perfectly. And just the reality is the, the world doesn't work that way. And so code push is the way that all apps function. If you look at all the big apps on your phone, the tiktoks and Facebooks and YouTubes and whatever, they all automatically update as you launch them in different ways. They've all built their own, you know, sort of different solutions for that. And that's just necessary.
'cause again, like right now, it's, we're recording it's, it's Thanksgiving week in the United States. We're about to have, you know, black Friday, where all the stores make all their money. Can you imagine as a commerce. You know, If you are, you know, a flutter app that's commerce based and you are down for an hour on Black Friday that's just unacceptable. And so that's why something like Code Push has to exist. You know, We were talking to a, a very large customer um, and they were, they were telling us last week that one of the cool things that they've figured out is that like when they have a bug in production, maybe not a fatal bug, but like a bug, they now realize that they can just push logs. They can just push logs. Go to lunch, which is like a normal thing you would do as a web developer, right? Push logs, go to lunch and come back and do it with your logs after that. But now they can do that on mobile that they just had never realized was possible. And so they come back from lunch and they just have logs from the field of like, this is what's going on in our app, this is how we debug this.
And then they fix it after lunch and another push. And that's just how development should go. And so like you asked, what is shorebird solving? We're just filling in the pieces. We started with this piece. It turned out it was way harder than I thought it was gonna be. Which we can talk about, but like we had to build a whole bunch of crazy stuff to do it. But so we filled in this code push and then we've built a CI product mostly 'cause we needed to do it for our own. So we have a, it turns out we have a lot of DART code. We wrote, wrote our servers in dart, we wrote our command line in dart. We wrote a whole bunch of stuff. And so we needed a, a really good CI system for that.
So we built one for ourselves and we, we made it available to others. And we've seen some large flood projects move to it. We're just filling in the pieces and then the long term is that coming to Shorebird should be like downloading Unity or you know, as a business going to Red Hat or whatever. And like you just feel like, oh, they have all the things that I want. They get me, you know, I think React Native has some of this in, in the, in from Expo. Right. You know, It is just like, oh, they get me that they understand me. They, They have all the things I want and Oh yeah. They take a credit card and, and I can. I can. pay for the things that I want and not pay for the things I don't want.
And that's how it should be. Right? Because there are millions of flutter developers. There was a stat that Google published last year that a third of all free apps submitted in the previous year had been flutter apps. Right. The Stack Overflow survey showed that DART is slightly larger, I think, than Swift, right?
This is a very large community. And where is the, where's the Flutter company? Where's the company? I can, I can come to and then just give me this big, warm hug of, of course you're gonna be successful with Fluter. We're gonna make sure that you're successful with Fluter, and that's what we're building.
Andrew: Yeah, that the code push stuff probably unlocked a lot for fluter developers, like you just mentioned, the Toyota project. Like I'm sure they couldn't confidently ship that if they didn't have over the air updates to fix their cars. 'cause who? Would, how else do you update a car?
Eric: Yeah.
Andrew: so let's dig into that code, push stuff. You said it was a lot harder than you thought it was gonna be. How much work did you think it was upfront, and then how much did it end up being and like, what were the steps that it took to get there?
Eric: so that was another lesson in business to me. I think that it took us about a month to get the Android version going and then maybe two or three to get the iOS version. And I think that we could have more aggressively sort of stopped there and tried to sell. Um, but the engineer in me wanted to make it amazing. And so we spent then another two years, almost year and a half. Making the iOS part in particular, iOS has more restrictions than Android does. Making it amazing. And, And the part that makes it really hard is that we have had to teach the DART system. So Dart already had an interpreter and you need an interpreter in order to comply with app store guidelines so that the App Store says you can update your app as much as you want. Just, you have two things, one of which is that you have to use an interpreter if you wanna update it. And you can't change the purpose of your app, right? They, They don't want you like selling a game and turning it into a gambling app for some regions or I think that, that's like a real historical example.
They don't, They don't want you doing that. And that's fine. 'cause again, all of the largest apps work this way. All of them do. but, but it was, it was really hard to. Do to take dart's interpreter, which was very slow because interpreters are very slow. And make it work really well in production.
'cause our initial iOS demo, just whenever you would patch the app, whenever you would like turn on shorebird, it just suddenly your app would get super slow because it was interpreting everything. And so the, the real hard thing that we did was we taught it how to. Without you pre-commit within your dart code, which parts were going to be interpreted versus not for us to dynamically without you having to do anything magically figure out, okay, we're gonna run this part of your app and the interpreter and this part not, and I can go into more details as much as you like.
This is a Dev tools podcast after all but it turns out to be a very hard problem.
Justin: Yeah. Uh, does iOS like limit? At some optimizations, like do they disallow jet? I'm not. I don't They do not allow Ji. So the, the technical restriction on iOS is that you cannot get a page of memory. A page is just like a unit of memory. But you can't get a page of memory that has ever been writeable to be then executable or other way around. Or I think maybe you can get one that was executable, but it loses its executable bit if you wanna make it writeable and. There are some, like you can get the JIT permission, during development time. You can get the JI permission when Xcode is connected. But in general, you cannot get writeable memory to be executable, which is what you need for jit. And so you are stuck then using interpreting, which is fine. Again, that's what they're, their guidelines say and we're happy to follow them and we do. But you have to use an interpreter and interpreters are just very slow. Hermes, which you mentioned before, does have some interpreting capability, and one of the things that they do is they have a very high level interpreter. We haven't gone down that route of, of uh, so high level in this sense is good, right?
Eric: Because instead of breaking a four loop into, you know, a hundred different little pieces like that you would do, if you would compiled it, not a hundred, but, three or whatever they just, the for loop is just one command. I, I don't know that, I haven't like gone and looked at their il, but I would expect that's how they work that they have a high level interpreter.
Justin: So we've gone on a, a long journey here. And it's, it's cool to see where you've ended up from your early days. And I kind of wanna connect your two startups. So the first one, you know, you're young, you are still learning, you get into it, and you're not talking to customers and you're working on a domain that's maybe not your actual passion, but you think there's something there until you, you know, are starting to work on your old employer's open source project.
But you had that experience, which I'm sure was still very formative. And then here you are, you know, now at this point in your career where you've been foundational on so many layers of technology, of the web of like, you know. Both in inside of Apple and inside of Google, and I'm sure have learned all these like incredible lessons you've been working on.
Flutter is a UI framework in this problem space for a really, really long time. So I'm sure you have a lot of like well sharpened instincts about the technology, about the needs that developers have about their desires. But now you're back in business.
[00:40:26] Monetization and Customer Focus
Justin: And tell me about it. Like how do you, how are things going?
We always love to ask developer tools companies, it's like, especially when they're dealing with open source, it's like, how do you, how are you thinking about, monetization around these things? How did you come to those ideas? I just, I just want you to like distill some of your learnings and like what it's like to be back as a startup founder.
Eric: Yeah. So things, little things I could say. Talk to your customers, right? Y Combinator, I would say 90% of their advice is good advice. Maybe 99% of their advice is good advice. Make something people want, make something you want. Those are all good things. I do think that one of the things that's very similar to the first time is that it is a schlep. There's just so much uh, I, I run a fully remote company which shocked me at how complicated that is from like a government filing sort of point of perspective. But I think it mostly comes down to talk to your customers, build something people want charge from day one. If you're in the B2B space, we did, and I'm really glad that we did. It's not even about the money. It is about the money in the sense of when people pull out their credit card, there's a different thing than if they just download your, so like there's a different level of intent, but. More importantly, you know, as a developer, as a developer listening to this, it's about completing the loop, right? The last 5% is, you know, 90% of the work or whatever, right? Like, And you just, when you actually force yourself to all the way, complete the loop and do the stripe integration and take payment, and just, it makes it more real. And so I'm glad that we did. I would've gone to market sooner. Uh, I think that I had read this, that like second time founders, third time founders, whatever, would tell you that like the advertising and the market pen, like that's the hard part.
It is like people getting, getting people to know that you exist is really hard, even with the like, level of platform that I have. So yeah, those are some of the learnings I would have. But things are going well for us. We're not profitable yet, but we are, we're going to be next year. We've been growing very well. We have thousands of customers who use us every month. We work with all sorts of very large brands, most of which have NDAs in their, in their MSA. So, you know, We can't talk about 'em. Um. We sell to, I don't know, 50 plus countries, it's just we're all over the world.
Flood is a very global product, so things are going very well. We're hiring a bunch now. So thing, things are great. Lots of big, hard problems left to solve. And that's always fun for me.
Andrew: Yeah that's great. Great advice, dog fooding. I've always been a huge fan of it. And if you can make your own, if you can make yourself the customer, just become obsessed with yourself and you'll have a good product in the end. But as we wrap up Justin, wanna do these last two questions? 'cause I feel like we could go both get good stuff outta them or do you not have
Justin: yeah, just, just run with what you want and then.
Andrew: Cool. Yeah. Be
[00:43:01] The Future of App Development
Andrew: Before we look to the future and wrap up here we live in a time of change for programmers. I'd say I, in my tenure career, I have not felt as like scared of the environment as I am now. Vibe coding is here. It's changed how a lot of people think about programming. Maybe not programmers but I wanna get your take on it.
What do you think of vibe coding as a person who's been in the industry for. Twice as long as me worked on like foundational technologies is probably like a powerhouse coder. Like how do you view vibe coding in the AI tools that we have today?
Eric: Uh, so I, I'm really glad to have the new tools. I think the new tools are great. Particularly my current. The current best I've had is the cursor, multi-line autocomplete. I just think take away all the other autocompletes. I don't want 'em, I just want LLM based autocomplete. That's great. I am intrigued by anti-gravity, although I have so little quota that I, I can't seem to use it for more than five minutes without it telling me I want a quota. Um. I don't really get the one shot vibe coating stuff. Maybe, I don't know what vibe coating is, but like the V Zeros of the world, like I get the attraction. It's really useful. So we, we recently hired a, a marketing person and, and one of the things they brought to our recent summit was like, we could look like X or we could look like y which are we more that was super useful, right?
Having a, like a one shot, whether it's a still image or a website or whatever, like. You know, I had somebody that came to an interview last week and they brought a like, vibe coded version of how they thought our, our website should be or our concept be. That's super useful. But like actually taking that and turning into something that I can ship to production is not a journey that I've personally had success with. So I guess I am um, bullish positive on these tools. Over time. I think there's a lot of UX work that needs to be done. 'cause I don't wanna write a Claw MD file. I'm sorry. Like, That's the, there's been a UX failure if I'm writing a Claw MD file. And, but I think I'm also very bearish on the bubble. Like, It just, there's just the, the revenues don't make sense to me. So like, there, there's something going on there. Um, But I think when, when the dust settles coding never gonna go back to the same. It was, but I, but I would caution against fear, right? Like when I started on this. I was writing objective C. Nobody writes objective C anymore, right? Everyone brunches c plus. You know, Increasingly people don't write c plus plus anymore. Right? The web wasn't really a thing. Right? And yet everything is JavaScript now and is that a direct comparison? No. Is it changing faster? Sure. But like I think that where I see folks get in trouble is being a flutter developer. Or being a React developer or being an Android developer. And I would tell you, you're a developer, right? You solve people's problems. And so focus on that and the tools empower you and don't really threaten you. 'cause like you still need to drive the tools. I think even, I just don't believe the a GI claims.
I just think we're a long ways away from you as a developer being replaced. And so I, I would encourage you to embrace these things and see how crazy far you can take 'em.
Justin: sounds like sage advice. Yeah. So as you look forward to, having experienced this sort of gamut of like how people are thinking about building apps, you're, you're building a company to enable people to build flutter apps in a more scalable solution, giving them all the tools that, that ecosystem was sort of lacking.
And as you, as you think about like the, the next step, the future be it of flutter specifically of like. The new capabilities you think are gonna come outta that ecosystem and how people build apps or just like, maybe more broadly in the industry, how we think about like, how you think building apps may change.
I'm just curious, like to get your forward perspective, are there things on the horizon that you're excited about? About, do you think there are gonna be any seismic shifts in how we, you know, approach putting together, uh, ui, ux? Are there any new capabilities? Uh, and again, you can scope this down to flutter or make it broader to the industry, whichever is sort of more interesting for you.
[00:47:09] The Next Paradigm Shift in Devices
Eric: Yeah, so I think the industry is spending a lot of time chewing on the AI question at the moment. I was excited to see Google announcing the dynamic UI generation that is flutter powered. Last week they had a line at their last io, which was like, vibe once run anywhere. I think that the need for multi-platform is going up, not going down.
I think there's another big shift that's coming and I don't know how it's going to come, which is, I would describe it as the Microsoft phone, which, if those of you are old enough to remember, there was a Microsoft phone and it failed due to lack of apps, lack of ecosystem, and this was actually formative for like flutter. And the, the experience, like the reasons why we existed is that we didn't want that to happen again. We have this funny duopoly right now between iOS and Android. We maybe see this with Huawei building a phone and, and maybe there will be more. But I do think that there's gonna be more devices and I don't know that it's gonna be AR or vr. I don't know that it's gonna be little pins. But there's gonna be another device paradigm. It's gonna happen. And I think that's gonna be more multi-platform, not less. Uh, and also there's all these device paradigms that we've forgotten, like desktop. How is it in the world that electron is the best way to write a desktop app? Like I agree, it's a revolution over having to write AppKit and then separately um, you know, whatever the windows, whatever the 11th Windows framework that came out. This, last year is, I don't know. Like it's definitely better than that, but like, can't we do better? Please? And so I just think that as we get further with solving. Solving portable software, right as we fix the incentives so that it's not, driven by Apple, it's not driven by Google, both of which have com, conflicts of interest in this, right? How do we have a real, a real whack at portable software? And then once we have that, what does that mean for more different devices? What does it mean for the next Microsoft phone? What does it mean bleed over for like. Improving the experience and the developer experience of the existing devices we have. I'm excited about that. So I, I guess that's a very focused on, on me, on Flutter, on Shorebird. But I'm very focused on solving the incentives problem to unlock all those amazing developers who wanna push this forward.
Andrew: Well, that's an exciting vision of the future that I can get on board with. I'm not the biggest electron fan either. Thanks for coming on, Eric.
[00:49:36] Conclusion and Final Thoughts
Andrew: This was like, this was a blast. We've had like a two month break now, and I think this was the perfect the perfect conversation to come back to.
So many cool tidbits, so much history. Thank you for coming on.
Eric: Thanks for having me.
Justin: Yeah. Thanks Eric. And just thanks for all your work in the industry. Uh, both Andrew and I have built our careers on the web and, you know, it's like people like you that enable that and, you know, just like grateful for all that work and really excited to see where you take Shorebird.
Eric: Thanks.