Back to the list
Eric Seidel
Episode 35 - May 11, 2021

Multi-platform Development with Co-creator of Flutter, Eric Seidel

Featuring Eric Seidel, Director of Engineering at Google and co-creator of Flutter
Apple Podcasts Google Podcasts Spotify Youtube

In this Semaphore Uncut episode, I meet Eric Seidel, co-creator of Flutter and Director of Engineering for the Flutter team at Google. We chat about the Flutter developer experience, the Dart language that powers it, and the transition Flutter is making from mobile to desktop.

Key takeaways:

  • Flutter allows one codebase for mobile, web and desktop
  • Dart is designed for developer experience
  • AOT or JIT compile for performance or .js transpile for iterating
  • An active Dart community fuels growth
  • Flutter integration can start with a single button
  • Flutter architecture supports many test styles
  • For mobile developers, Flutter is a must-try

Listen to our entire conversation above, and check out my favorite parts in the episode highlights!

You can also get Semaphore Uncut on Apple PodcastsSpotifyGoogle PodcastsStitcher, and more.

Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

Edited transcript

Darko (00:02): Today I’m excited to welcome Eric Seidel. Please go ahead and introduce yourself.

Eric: I’m Eric Seidel, I lead the Flutter team at Google. We started the team six and a half years ago, myself and a few other engineers. We just try to build great things for developers, help you get to more platforms faster.

Darko (00:30): Can you give us a brief overview?

Flutter allows one codebase for mobile, web and desktop

Eric: I used to work on the Chrome team. Eventually, after many years, I got sort of frustrated with my inability to make the mobile web as amazing as I wanted it to be. That was enough to sort of seed the project that was Flutter. We built something that helps developers reach the same number of platforms as say you would by embedding WebKit or Electron, that kind of thing. We help folks start by solving the problem of what do they want to build rather than where do they want to build it, which we see the games industry having done.

Darko (02:20): I saw that Canonical will build all the UI as part of Ubuntu and probably other products that they have by using Flutter?

Eric: We’ve been on the desktop journey for a while. It’s interesting. We started with mobile and then we built something that was portable enough. The Linux part sort of took off and Canonical took notice and we have been slowly over the last few years, teaching our mobile-first framework, what a mouse and a keyboard is and helping to bridge that gap.

Dart is designed for developer experience

Darko (07:17): Can you give us a bit of an intro about Dart?

Eric: Dart is fantastically easy to learn. It’s an intentionally small language. It has few pieces in it to try and make it easy to learn, easy to use.

It found a home inside Google as sort of a GWT replacement. GWT was this technology where you could take and write a bunch of Java and then translate it to JavaScript. Developers can write in Dart and then transpile it to JavaScript and still get good JavaScript out at the end. There’s this whole ecosystem inside Google with so many developers using Dart in that mode. In fact AdWords, the whole thing that makes all the money, is all written in Dart. We came to working with the Dart team after some frustrations with JavaScript.

We found a partner there who cared about developer experience, who cared about reaching developers. We were able to build a really great developer experience together. So hot reload, this sub-second time between when you save and when the changed app, not restarted, on the same screen that you were 30 pages into your navigation of your app [appears on your phone]. It came out of co-experimentation with lots of engineers at Google, all who cared about just making developers happy and productive and get home on time.

AOT or JIT compile for performance or .js transpile for iterating

Darko (10:43): For the web, Dart is compiled, let’s say into JavaScript, but for iOS and Android is compiled into native code?

Eric: That’s correct. We were using JavaScript, one of the frustrations that we had was around startup time. We thought a lot about the layers so that you could use any one of them or use some of the lower ones without using the upper ones. But as it got bigger, we started seeing like 12 second startup times. That just wasn’t scalable. So that is part of what caused us to evaluate a whole bunch of different languages and ended up picking Dart because Dart was a language that we could co-evolve with.

One of the early evolutions was that we needed to start up fast on iOS – as fast or faster than the native apps or the pre-installed apps. Dart has many modes. For mobile development there’s either a JIT that runs on the phone or the ahead of time compile, AOT compile, to just a library, just a normal ARM binary. On the web side you can ahead of time, whole program optimization, compile into a single .js file for when you want to deploy. But they also have this mode where they will compile every single separate Dart file into its own .js file with very minimal optimizations. It allows you to rapidly iterate. The team is focusing on that developer experience.

An active Dart community fuels growth

Darko (14:03): As iOS, Android are moving along, introducing new APIs, how is Dart as a programing language catching up?

Eric: We actually run Flutter on a separate thread from the underlying operating system and that again was a reaction to the web where one of the things that used to happen a lot on the web is that your JavaScript would get interrupted because the browser was doing something or the network was doing something.

A Flutter app is just an iOS app. It’s just an Android app. It’s just Ubuntu app. I mean, in Ubuntu it’s a GTK app and it’s just a view. So you just have an Android view or an iOS view, and it’s just a window into OpenGL or a window into Metal or a window into Vulcan that runs like Unity would, or like any of these game engines would its own separate thread with its own separate language.

Then you can write as much GTK as you want. You can write as much Kotlin as you want, but you do have to call out to that through a message-passing system and this is where plugins come in. This is where the community come in and you go to pub.dev, which is our community site where you see all these plugins and that’s where you can find 15,000 existing plugins. So if you’re just trying to do a little bit of Bluetooth, you can go find a good implementation of that. But if your whole app is about Bluetooth well you just go and write a bunch of GTK code or you go write a bunch of iOS code or write a bunch of Android code.

So in terms of keeping up, I think what the actual underlying question is it’s an incentive question. It’s who do you keep up with the most? I think when we were just iOS and Android, it was very obvious. We do all the iOS things. We do all the Android things. I think that will be increasingly a challenge in the coming years because you may find we’ll do all of the iOS things and all of the Android things and maybe require other companies like Canonical to do all of the Ubuntu things.

Flutter integration can start with a single button

Darko (17:06): If I understood correctly, it’s possible in existing iOS/Android apps that you bring Flutter in and then…?

Eric: How does Flutter inter-operate? So we’re just a view, just like WebView is just a view. We’re much lighter weight obviously and you can just throw us in. The best way to use us typically in that mode is a full screen, but people do use Flutter for just part of screen or you can even use it just for a button. It’s very difficult to context switch back out of that and have to write one of your buttons in one language and one of your buttons in a faster, more productive development environment that Flutter offers. So I think that teams tend to switch whole screens at a time. What we’ve seen inside Google is that people try Flutter and then they love it and they fall in love with it and they just use it for more and more.

Flutter architecture supports many test styles

Darko (19:08): What’s generally the testing philosophy for Flutter apps.

Eric: One of your previous guests, I think the gentleman’s name was John Reid talked about being testing infected. I will tell you I am testing infected. I think it came early from my web experience, but once I learned how powerful testing was in terms of just not having me make the same mistake twice.

So we started from a very testing, friendly culture. We built a whole bunch of layers of testing, more layers of testing than possible to build with other frameworks. So, for example, because we built this also layered and because it’s portable, you can run visual UI tests for your mobile application in the background on your desktop, because of course, we do headless and of course, we can just chop off the pixel part and they run blazingly fast because you don’t have to start up a whole simulator for every button click you want to test.

So yeah, so we have unit tests at the language level. We have unit tests at the widget level. We have integration tests and we have golden file testing, both textual as well as pixel tests. We’ve got tests for our own usage and then of course we expose all of these to the developers.

When we release Flutter to the outside world, we develop everything in GitHub but we take that master branch and we check it, and then we deploy it inside Google and to get all the way through Google, it has to pass through hundreds of thousands of tests before it even becomes a Dev channel. So yeah, we’re big testing nuts, I guess is the short answer.

For mobile developers, Flutter is a must-try

Darko (23:31): 2021, someone is opening their browser and starting their Flutter journey. What piece of advice would you give?

Eric: I would say to any of your listeners, if you haven’t tried Flutter, it’s worth a couple of hours on a weekend, right? Just to experience what development built-in 2016 is like, maybe you’ll never use it. Maybe you don’t have a use for it, but I believe that we have successfully pushed development forward some, and I think that cross-platform correctly gets a terrible rap. I think that we have tried to right many of those sins and make multi-platform development a lot better and produce a lot better output for the users. You’re right that a large percentage of our user base is first time coming to mobile. Some of them had tried mobile before and failed. I think because mobile development is harder than it needs to be. So we’re seeing particularly Flutter is huge in growth markets.

Darko (25:29): Before the call, I checked on Google Trends, React Native versus Flutter, and Flutter is about to overtake React Native on Google Trends. So that’s one sign that something big is happening. Okay. To wrap up for this year, any big releases coming? Any bigger movements that community can expect in Flutter world?

Eric: Everything’s open. If you’re paying attention to the source code, you will see it coming for months in advance. But I think 2021, the two biggest things on my mind in terms of the source code are we have more work to do in terms of performance, including on iOS. And I think we’re going to be spending a lot, a lot, a lot of time on web in this next year. My team is dealing with today is all the influx of web users and all the many wonderful suggestions that they bring.

Darko (26:50): Well, thank you for this conversation. I would say from my perspective, it’s a very brave battle or you’re entering. I wish you good luck with adoption and I hope that many of our listeners will try Flutter. Thank you.

Meet the host

Darko Fabijan

Darko, co-founder of Semaphore, enjoys breaking new ground and exploring tools and ideas that improve developer lives. He enjoys finding the best technical solutions with his engineering team at Semaphore. In his spare time, you’ll find him cooking, hiking and gardening indoors.

twitter logolinkedin logo