[Note: please be advised that this transcript contains strong language]
Transcript
Abid: I'm Faisal [Abid], co-founder of a company called dydx.dev, but we'll talk about that later, if at all - nothing to do with Flutter. When Anna reached out to me and said, "Do you want to do a talk on cross-platform clients and all that?" I started thinking about my experiences with cross-platform development and I've been doing development for a long time. I was a tiny little nerd doing development as a kid and back in the day, the hottest thing was Flex. Does anyone remember Adobe Flex? I was a co-author on that book, Flex 2 in action or 3 in action. That's how I got good marks on English in high school because I just said I wrote a book.
When I was doing Flex, the promise was cross-platform applications. The reason why that promise was important was developers are lazy, all of us are lazy here even if you don't think you are because we want to do more with less code. We don't want to build a web app, an iOS app, an Android app, and then build IoT apps or all sorts of apps and then you end up managing tons of crap that you don't want to. Then when there's a new feature, you have six juror tickets and you end up managing those six juror tickets and team velocities are different, there are weird issues with each platform.
We've all been burned. We've all heard about cross-platform in the past, whether Cordova or PhoneGap, that stuff was crazy. I remember doing Angular in PhoneGap and just trying to figure out why everything was slow because I was lazy and I wanted to build a cross-platform app. Then you saw the rise of HTML5 after Flash died, and then progressive web apps slowly came on board and the promise is living. Then React and React Native come on, and more and more people started to think about cross-platform again.
I have this philosophy, and if you remember me in 10 years, remember this one thing I say, which is everything old will be new again. Whatever's old now is going to be new again in five years and on and on. Soon in 5, 10 years people are going to be, "Uh, React Native. Uh, Flatter," and they're going to go right back to doing something that was old and then we're going to go back to monolithic software and forget Kubernetes and then go back to decentralized again. We're going to do everything again, it's the cycle of life.
Anyway, it's not about this. We've all been burned in one way or another and then we started thinking about cross-platform apps again. That's when we start to look at React Native, and then Google came out with a thing called Flutter.
Before we get into that, why should you even bother listening to me? I'm a Google developer expert for Dart and Flutter, I've been doing Android development since Android came out. I bricked my Windows mobile phone and that's how I bought my G1 in university and that's how I started doing Android. Right now, I'm a co-founder of the API observability and monitoring software called dydx.dev. If you guys are interested in that, feel free to go to the website and request an invite to join.
The Story
The story: where did Flutter come from? It was 2015 and I was sitting in the front row like this at a Dart Developer Conference. This was just Dart, no one had heard about Flutter. I gave a talk there about how I moved some application that I had back in the day to Dart from Node.js and I gave the talk, it was great. After that, I was sitting in the front row and Eric Seidel, who at that point was the project manager of the Chrome team, came on stage and started talking about a project called Sky.
Sky was very interesting. He showed a demo running on iOS saying we wrote this in Dart, and then he showed the demo running on Android, saying we wrote this in Dart. The demo was amazing. It was a box spinning around the screen. It was very uneventful but at the same time very interesting, because it was a cross-platform app running really fast using Dart. At first, I was confused. At first, I said, "Oh no. Everything old is new again. We're going to do PhoneGap all over again. I don't want Dart just becoming HTML5 language for mobile," but it turns out that they were actually comparing this to Native.
This was 2015 and this project was called Sky, and after that one talk it disappeared and it didn't come on back till I was in Munich at another Dart Conference and they announced a thing called Flutter. During this year, they've been developing the language and the platform. What I started learning was it wasn't using HTML5 or web views or whatever. What they did was very interesting. They took the world's most used rendering engine, which is Chrome, and they stripped down the DOM layer, HTML, CSS, all that stuff, they got rid of it and they kept the one thing that mattered, which is the Skia rendering engine.
That engine runs on mobile, desktop, TVs; wherever Chrome exists, that rendering engine exists, so they already had something that was versatile. It renders fonts really well, it renders games really well, animations, colors, so they had this powerful tool. What they did internally was they made a big matrix. What they did was they went around team to team asking them, "What language are you using at Google and why?" Teams were using Go, were using Python, JavaScript. Some of the teams were using Dart. Dart at this time had terrible PR. It probably still does, but it had really bad PR back in the day because some very aspiring journalists went on and wrote, Google wants to kill JavaScript with Dart. I don't think that was ever their intention. I don't work for Google, I have no idea, but because of that, Dart got a lot of hate.
Dart wasn't as popular back then, but there's this team inside Google using it and it was a small team of no value to Google called AdWords, and they were using Dart a lot. They said, "Why is this team using Dart?" They started to investigate and they found out that Dart had a lot of good reasons to be used for mission-critical software like AdWords. It was type-safe and it was actually productive. They found that when they were doing JavaScript development, TypeScript, or whatever, they were a lot more productive in Dart. There's a lot of research on this. I don't know how they measured this, but you can go on and search this and there's a whole video on the case study that they did with the team.
They made this matrix and they said, "You know what, Dart seems to be the language we should use for Flutter," and so they started to write this rendering engine language inside of Flutter. That's essentially the birth of Flutter. A year later, 2016, Flutter Alpha came out and then a year later beta came out and now we're at Flutter 1.5. Flutter's grown a lot and this is actually interesting because we have so many people here. If I were to give this talk two years ago probably like three people would come.
This is a testament of Flutter and how fast it's growing. You're seeing it used by some big companies like Alibaba, Hamilton app, the Hamilton musical uses Flutter for their app. It's actually very interesting because if you look at these apps, you wouldn't know it's Flutter. When you look at HTML apps, HTML5 or any sort of cross-platform apps, a lot of times you can tell that, "This was a cross-platform.” It looks just like an Android app or an iOS app running on my device, but it's not. Flutter kind of adapts and we'll learn all about that.
To recap, Flutter is fast and Flutter is not a web view, but Flutter is the 60 frames per second native on Android and iOS. This is very interesting because two years ago I was in Mountain View and I was visiting the Flutter team and they had these big screens in the back. All these screens had all sorts of crazy charts and I asked them what these charts were. What was interesting was when they push up code to GitHub, they actually run UI tests. Not just unit tests, but they run UI tests to see the performance of all the components that they're pushing up and they have to hit 60 frames per second native on Android and iOS. I think they've actually doubled this to 120 frames, I'm not sure, but they have to hit this threshold. If not, the pull request guy is yelled at and they’ve got to fix your code, whatever happens at Google.
Flutter is built on three principles. It's built on fast, beautiful, and natural. Fast is a given; it needs to be fast, it can't be janky. Beautiful is subjective but Google being Google, said, "Cool, we're going to adopt material design for Flutter." At the same time, they've also built components called Cupertino for iOS, so if you want your Flutter app to look exactly like a plain old boring iOS app, then you can use Cupertino. Or if you want your Flutter app to look like a boring material design app, you can use material design. What they recommend is do whatever "New York Times", they create their own brand identity on top of material design or Cupertino.
Then natural is actually the most important one to me, which is if you run a Flutter app on Android, it behaves like an Android app. When you press back, the screen goes back. When you scroll your list view, it has that weird blue glow at the bottom. And then on iOS when you scroll an iOS app, it will fling the list to you. It has the physics and it has the behavior of the OS it's running on. That's very important, because sure, your app might look good, it might behave good, but if the user is using the app, the user needs to understand that the gestures that they've been using in all the other apps work in your app, that are platform-based. On iOS, you can swipe from left to right or whatever and the page moves; your Flutter app automatically gets this. You don't have to build all this functionality in.
Demo: Hello World
Let's do a demo, Hello World, and I will give you your first glimpse at Flutter. I've gone ahead and created a Flutter app in case something happened during the demo, as always things do, but you can use IntelliJ, you can use VSCode, Sublime. I even have a friend who uses Vim for Flutter. He's crazy, I don't understand why he does it, but he looks like he's in "The Matrix" all the time. Anyways, here in IntelliJ I'm just using it because I'm used to it. Ever since I was doing Eclipse for Android, I moved to Android Studio. You create a new project, you create a project name, a project location, the same old standard stuff that you do on an iOS or Android app.
The organization is your package name or classpath on iOS and then it'll ask what language do you want to use. Now, you obviously know that Flutter uses Dart, so why is Flutter asking me what language do I want to use, Android or iOS? We'll get to that. Typically, I just keep a default Java Objective C, but if you have experience in one or the other you can choose. Then I'll click finish, it will create the app and we'll create this app. What I'm going to do is run the app. I had my phone plugged in for another demo, but here when I click run app, it gives me two choices, Pixel 3 or iOS simulator. Already that's pretty cool. I get to run my app on an Android or an iOS device just by choosing which platform to target, so I'm going to choose iOS. It's going to open up the iOS simulator.
Now I'm going to hit run. What happens here at the bottom is interesting. It's launching in debug mode, but what it's going to do is actually going to invoke Xcode. It's actually compiling the app using Xcode or if you use Android, using Gradle. There are no weird tricks happening here; it's actually just running it through the same toolset. As advancements happen in those toolsets and the compilers, Gradle compiler or the Xcode compiler, you'll see advancements on your Flutter app. Flutter's running inside a rendering engine, so it's going to see improvements on that rendering engine, not specifically your app. Here we have this app running and now I'm going to just hit this plus button. Very boring demo, it's just incrementing.
Here's one of Flutter's coolest tricks, it's called hot reload. I'm going to make my I.D. Now, you're building an app, your developer comes to you and says, "Faisal, our brand colors aren't blue, they're actually red," and I'm like, "Oh shit, I'm sorry. Let me go ahead and change this color." Now, if you are an iOS developer or an Android developer - let's talk about Android because I'm more familiar with Android - you're going to change the colors on XML, change the file, and then you're going to wait awkwardly as Gradle builds and then it slowly builds and your machine runs out of memory then finally your app runs and then you realize you chose the wrong shade of red. Then you do the whole thing again.
On Flutter, here's what you're going to do. You're going to go to colors - let's just assume that this color's not red - I'm going to hit save and my app has changed colors. Now, two things happened here. My app changed colors which is a cool trick, but if you notice number 22, it hasn't gone away. All my variables are the same, they're instantiated, they're not changing, and so this makes it very easy to develop and debug apps. For example, if I want to change the font size of 22 and make it really large, I'm going to find right here, counter, style. Font size, I'm going to call it 50, I'm going to hit save. Fifty is too small still, let's call it 100. I'm just increasing. Now let's add a button. There's a button there.
I can keep going, I can build this entire app this way without ever having to actually close my app down and reload. This works perfectly on the phone also and I can show you that later. This makes development extremely fast. This is basically like the web development expert, the Holy Grail. You have your browser open, you are editing CSS, it's all happening in real-time and the feedback response is great, so you're not really waiting. A couple of times where hot reload really is amazing and we'll have a demo of that a bit, is when you're doing network calls. You make an API call and you don't know why your API is not working and you realize that you just have a key run. You can go in and change the key and your API system will start working again, so it's very fast.
In fact, hot reload is so crazy that a while ago a friend of mine asked a question saying, "Hey is there equivalent to RelativeLayout in Flutter?" He came on Stack Overflow and he said, "This is my Android app and this is how it looks and I want to do something like this in Flutter." Someone from the Flutter team came on and gave an answer and said, "Flutter layouts or built blah blah," and then they went all out and they actually did the whole layout for them. Here's the whole code. Here's hot reload in action. I'm going to copy and paste this code into my app and we're going to see something cool. Now all I have to hit is command-S which is saving it.
I hit save and the entire app has changed. This is very interesting where if you're doing rapid development, you can change the entire app this way and now this is an actually functioning app. This is not a weird screenshot. This is working, I can tap on this, I have the effects here, inkwell effects. Everything is working the way it's intended to be. When you're doing development, this is an extreme case. Your app is not going to change in one code push, but when you're doing development, it's very interesting because you can go to StackOverflow, you can go to GitHub, find sample code, find sample components and without actually doing a whole rebuild of your app, you can start trying new stuff.
This saves a lot of time. Even if it takes 60 seconds in your day per time you're trying, this is going to add up and give you an hour back in your day. This is one of the biggest things why people like Flutter, which is, it's moving really fast. What's cool is, this is all native. When I actually compile this and run it on my Android app or iOS app, it's going to look and feel and behave just like a native app. That's "Hello World."
Why Flutter?
This is a slide that I usually just have here. This talk isn't intended for you to be a master at Flutter, but this is a good way just to understand what's happening on Flutter. You have your material widgets at the top and now Cupertino and then you have this layer of widgets. What widgets are in Flutter are like Lego blocks. When you saw me do development there, I took a raised button and I put a text label in it. A raised button and a text label are two different widgets, and all I did was, I said it takes a widget then I said cool, textures class widget. Also, I'm going to put you guys together, and now I have a text widget living inside of the raised button.
Flutter is very composable and extendable that way. Everything takes a widget and everything is extended by a widget, so you can kind of mix and match and create some really crazy components. If you look at some of the examples online, you'll see that people are doing some wild stuff that you really can't do without writing your own custom drawing views on Flutter, Android and iOS. You have your rendering engine, then you have animation, painting and gestures. That's just giving you control to gifs or writing drawing games, drawing videos, and gesture control, which is taps, swipes, you have all that. Everything that you expect in a mobile app, you have.
Lastly, you have this thing called services. What services are, are a way to expose the app to the phone world. Flutter doesn't come with everything packaged up. Samsung's coming up with wacky sensors all the time - if they come up with a nose authentication, Flutter is not going to have a nose authentication plugin. They're not going to invest time in that, but if you absolutely need nose authentication, you can go into the Java world, the Kotlin world, Swift or Objective-C world for iOS and write that plugin and just submit it to Flutter. When you do need something very custom, you can do it yourself. Otherwise, you don't really ever need to touch that. There are plugins already out there that do mostly everything. It's very rare that you ever need something custom, especially given where we are in the life cycle of Flutter.
Then at the bottom, it's stuff that you'll probably never ever touch, the Skia, the Dart VM, Engine, all that stuff that's low level. If you're very interested in that you can go to flutter.dev and actually see talks about the in-depths and internals of Flutter, but that's way beyond the scope of this.
To summarize, why Flutter? It's a tightly integrated development environment. It's one codebase targeting both platforms and we'll talk about an extra couple of platforms right after this. Faster platform iterations - this is what's very interesting. Previously, I was CTO at a company called zoom.ai, and we were doing lots of platforms and development on those platforms. The most painful thing to me was going, "Cool, the Android team is about a week away, but the iOS team is about two weeks away because iOS Apple has these weird things we've got to do and there's just a different beast on doing this kind of animation on iOS or vice versa." There was always the weakest link in the teams and we always had to wait for the other team before we made a splash at a public announcement. With Flutter, you're just writing one code base and you can deploy on both. It's kind of like doing the Thanos snap on your team, where you kind of eliminate half the resources and allocate them to your main product and then it's easy to talk to native platforms if needed.
One Codebase; Multiple Platforms
One codebase, multiple platforms. I'm going to show you a demo of Trace, which is another beautiful app that's ready, you can go to this GitHub. It's an open-source app, it's also available on the Play Store and I'll show you how to fix a bug in Trace or how quickly it is. Let's open up Trace here - again, on iOS. Trace is compiling, running Xcode build. Here is Trace. This person has done an amazing job with this app and I do recommend downloading his Android app or checking out the open-source and just starring it. Here's an example of a very complex app doing a lot of things, and how hot reload works. Again, this app works on iOS and Android, I can have it running on my android also. It's on the PlayStore; if you actually search Trace Crypto, you can use it right now.
If I change the theme to dark, dark mode works, all that dark mode marks. That's cool and so here, I go to this list view and here's something off. You can see that the market cap is all zero and the volume is all zero. This is a live app with a lot of live data coming in. This isn't that sample app we were using before, so this is as close to a real-world scenario as possible. What I had done earlier is introduced a bug in this app by spelling something wrong or adding underscore here, so marketcap right here should actually be, "market_cap," and this is something that's happened to all of us; we used the wrong JSON key and it doesn't work. Then I've got to fix it, recompile the app. If you imagine, this app had a login screen or some sort of other screen, I'll have to click through all those screens to get to the screen and then run it and then realize I screwed up again and do the whole thing again.
Here, I'm going to go back to the screen and I'm going to add the underscore, hit save, and you'll see that market_cap. It actually figured out that "Cool, they want this variable." I already have a JSON data representation, so I'm going to just going to populate all this data. This is a live app that's running. Same thing with here; volume, I think it's, "volume_24_hours." You see all the volumes are working. This is extremely fast to develop when you're actually building a very complicated app.
Now I can go ahead and I can change this. If I want to swap this around, I can swap that, I can paste this here and can call this market cap, and you'll see all the values just flip around where all the values flip. I'm doing this rapid development. I can change the theme; instead of calling it the hintColor, I'm going to call it accentColor and now it's purple. This is very fast rapid development, and this isn't like an Invision prototype. This is an actual app that then you can just go, "Cool, I'm going to File, Export to Android or iOS and it's done."
Future Flutter: Web & Desktop Platforms
I hope you guys are liking the power of Flutter there. What about more platforms? I still don't want the same product being built on web and then a whole different team building it on mobile, if it's the exact same app. I had a use case. I built, with my friend - it was his company - a Christian music streaming app, so Spotify for Christian music. One of the biggest problems with overflow was we had to build a Flutter app, which was great, but then we had a web app. It was identical other than the fact that it was just the mobile app running on desktop.
What we did was we architected it in a very interesting way. We took all the models and all the core business logic and we put it in a separate repo, and then both apps just used that, so it was built in angular Dart. That was cool, we reused as much as code as possible, but the UI again we had to rebuild all on our own. If we were to build overflow today, overflow's gone and dead. But if we were to build it today, we would probably use Flutter and Flutter for desktop. What Flutter for desktop gives you is the same app you can compile and run on desktop, whether it's browser or even your Mac app, Mac or Windows.
I'm going to give you an example of an app here, GitHub Visualization. If you look at it, it is the exact same Flutter code, you're still doing the same Flutter so there's nothing new or added. There's only one extra thing you do, a small detail which is where you import Flutter web, instead of the Flutter SDK. This is only because it's under beta preview right now. Once it finally hits 1.0 you'll be able to just copy and paste the code. This is just an example of what you're going to see probably in the next six months.
All I'm going to do is run this, and I'm going to run it in web dev, and what it's going to do it's going to compile this app into JavaScript. It's not using Flash or anything crazy, it's actually just compiling into plain old JavaScript and it's going to run it on Chrome. I think it's done; it's compiled. I'm going to copy this URL, I'm going to paste it here, and here we go. The resolution is kind of weird on my Mac right now, but it's interactive, it's not a video and you could take this app and run it on a phone. All you've got to do is modify it a bit just because it's a beta, but you can just run this app on your phone.
This is amazing because what you can start doing is you can build your Flutter app, and then once you've done your mobile app, you can say, "Cool, how does this make sense for desktop? Do we just need to extend it?" If you're writing iOS apps or Android apps for tablets, essentially you kind of do the same thing. You say, "How does this look on a bigger screen? How do I make my app more responsive?" You can have the same conversation with your team and you're just going to add that feature in.
There is a good case study, and we'll look at this app at the end, called Reflectly. What Reflectly is, is just a diary app where you can write about your mood and you can reflect on your personal feelings. What they did was they had this popular Android and iOS app, it's actually in the top 10 grossing apps on productivity, something like that, and what the developers did was they wrote a blog post, saying over a beer they were able to port this to the web. What that means is they just had to go in and remove that during the beta, remove the Flutter tag at Flutter beta, and they had to make sure that they're not using any native Android or iOS services like GPS or phone vibration, because that stuff doesn't exist on a browser; you need to hook into a different API. They did that and the app just worked and they were able to have a whole new monetization strategy, which is web.
Does Flutter Support X? Native Integrations
Going back to integrations, we talked about the Flutter support X, and I talked about Flutter's not supporting any random sensors. If you do want to implement your own sensor, it's fairly easy. This code slide serves two purposes. Number one is just talking about how you can talk to a Flutter service; you call a platform .invokemethod. That's a tiny detail, the bigger reason for the slide is everyone here could read the slide. This isn't some complicated syntax. This isn't like Haskell or OCaml or something crazy where you're just wondering what's happening, this is simple. I like to say Flutter is a very boring language because it is in a lot of ways. You kind of automatically know it, there's no excitement. When you learn a new language, you're like, "Wow. I figured how to do this." You already know it so you just start writing, and you're, "Whatever. This is exactly like every other language I've used, there's nothing new to learn."
If you want to learn the tricks and the best practices, that's really cool, but you don't need to know that. You can just start using it. If you've ever used Java or JavaScript before, you know this already. You have a battery level function that returns a future, it's an async function and it waits to get the battery level and then it returns it. Simple, straightforward, this is how you interact with services and this is how you can build additional services. Once you have written something in Java or Kotlin, Objective-C or whatever, you can just call it using this.
Flutter for Android, iOS and Web Developers
You're an Android developer and you want to learn Flutter. You want to actually start building your application. Flutter has great resources, I am biased towards this resource because I wrote this resource, but if you go to flutter.io or flutter.devnow/get started, you can find Flutter for Android developers. What Flutter for Android developers gives you is to take your existing Android knowledge. "I know how to do a list view in Android, how do I do it in Flutter?" They'll tell you how to do it.
The same thing for iOS developers - it exists. I didn't write this but someone else did, the different tasks of Java. If you're an iOS developer you can transfer your existing knowledge right away.
Same thing for web developers. Flutter's taken a lot of time to make sure documentation is good. A lot of times I find when a new language, a new platform comes out, the technology roadmap is moving really fast but the documentation is lagging, and I saw this with Android. When I was doing Android 1.0 the documentation was total crap. I had no idea when an activity was. I was just like, "I don't know, I guess I'll write something," but over time the documentation got good and now documentation is amazing. Flutter and Google learned from those lessons and made sure documentation from day one is excellent, so you will never run into an issue that's not documented that you can't figure out. What's great about the Flutter community is if you do run into an issue, you go to their GitHub, you can write an issue and you'll have someone guaranteed respond to you from the Flutter team, either saying, "Your issue has been previously looked at. Go to this GitHub issue," or saying, "This is a feature that we're not going to add," or something, but you won't be left in the blank. You won't be left in the void just wondering how I fix this. The Flutter team is working very hard to make sure that developers figure out the platform and build really excellent apps.
Demo: Reflectly
Let's do a demo, Reflectly, because I want to show you how you can take a very custom UI. We previously talked about material design and we also talked about Cupertino, but this is Reflectly. Right away you see this is unlike any other app. This does not look like a material design app, this does not look like an iOS app. It's just an app, a whole custom app. I'm going to say, "Hi, Reflectly." Great animation, it's kind of lag here because it's just streaming it, but if you download this app right now on your phone, Android and iOS, you can see the fluidness of the animation. "They call me Faisal."
All these beautiful animations don't take a lot of time to do. These are all built into Flutter. Flutter's built with animations because what's interesting about Flutter, and the reason why I show this demo is, a lot of this stuff would take a lot of time if you had to do it on Android and iOS. That's because those platforms are built from day one with the whole different use case in mind. Mobile has evolved so much and so now those platforms are catching up. Flutter was designed with best practices in mind, given the current state of mobile world. Flutter knows that you need to have smooth animations, Flutter knows you need to have this easy-to-use composable framework that you can write apps really quickly.
Let's keep going with this. Let's just choose red, I like that color. Next, "send me reminders." Here is an example of platform notifications in action - platform plugins in action. This is actually hooking into the notification plugin, so all this developer had to do was import firebase notifications or iOS notifications and just hook it up. I'm going to click yes and then that's it; I have now given permission to get notification access. You can play with this and you can understand that this is a very seamless application and you're not constrained on material design or Cupertino. You're constrained by your imagination and the skills of your designer.
Questions and Answers
Participant 1: I have two questions. The first one is, one of the challenges with the user interface is the language. Some of the language is right to left, so does Flutter solve this or support this language? The second question is for the web applications. What kind of hosting can I host Flutter web application on?
Abid: To answer your first question, yes it does support right to left or left to right. Yes, it just supports everything and then in terms of hosting, it's just you're building an APK or an iOS app at the end, so you can post it on Play Store and you can host it on the iOS App Store. There's no difference. Fundamentally, it's the exact same if you're writing it in Android Studio using Java, or Xcode using Objective-C or whatever. It's the exact same end result. It's just the way you're writing this is different.
For the web application you can host it on Firebase hosting or it's just an HTML JavaScript application so it doesn't matter; there's Netlify, there's CloudFlare functions you can host your JavaScript stuff on. It doesn't really matter where you're hosting it, you can host it anywhere. It's like an Angular app, wherever you can host an Angular app you can host a Flutter web app.
Participant 2: Do you know how committed Google is to this Flutter thing, because their interface is changing all the time?
Abid: While I have no inside knowledge at all - I wish I did - I know that Google is very committed to Flutter. That's partly due to two reasons. One is they've invested a lot of time and resources into Flutter. They're doing a lot of internal laps in Flutter that are core to them. There is an app called Greentea which is their CRM. They manage Google CRM, that's some pretty big CRM and that's written in Flutter now. That's because they want to move fast and they're investing a lot of resources into getting developers on board. I will be surprised if Google just tomorrow says, "Ah, cool, we're killing it," because they're seeing a clear ROI to their investment.
The other thing is Flutter is also being used for IoT types of applications. Does anyone have a Google Home hub here? Google Home hub is just like Google Home with a screen. A lot of the watch faces and a lot of the other stuff on it is written in Flutter. Lenovo and a couple of the partners are writing those UIs in Flutter so Flutter's finding a lot of life in a lot of other places other than just mobile, and so that's great ROI for Google because they're able to have their hands everywhere.
Participant 3: You showed us how to transpile compile mature the Flutter application to web application. If we want to have an actual desktop application, do you know if it's going to be possible to actually compile to native Windows, Mac, Linux, whatever, or will we need then again electron or something to package it to a desktop app?
Abid: That's a good question. I'm not too sure about the Windows story. I know for the iOS side, iOS has this thing called Marzipan, or whatever they're calling it now - Catalyst, I think - where you can take iOS app and run it on desktop. I think that is the route that Flutter's taking. You can rebuild an iOS app which is a Flutter app and you'll be able to run it on desktop. They do have a demo of this on Flutter web and they have a "New York Times" case study where "New York Times" made a game and it runs on desktop, on mobile and web also, so you can read more about that.
Participant 4: Is there anything that you think existing frameworks are doing better than Flutter right now?
Abid: Yes, I'm sure, I just don't know what. I think React Native is doing great in terms of the developer community that they have, and I think this is because they got there a bit before the React community in general. One of the things that React has working for them is JavaScript. Not that JavaScript is a better language - all languages are the same in my opinion - I think JavaScript has so many NPM modules already out there and stuff that it's a lot easier for someone just learning to get in because all the resources exist. However, that story is changing, at least qualitatively, as I see. The NPM version of Flutter is pub.dev. If you go to pub.dev, you can find a lot of things now that you didn't really have back even a year ago.
The Flutter explosion is happening and it's getting to a point where it's kind of comparable. I don't necessarily know if one platform is doing something vastly greater than the other. They're all following the same principles, even in terms of just the way you write the UI. You can see even Android and iOS now trying to copy this reactive nature style with Android Jetpack or something, and iOS has the Swift UI, where you can write your UI in code and it's the same pattern that everyone's following, this reactive pattern.
Participant 5: I'm just wondering what some of the trade-offs are with this, and what would you not use Flutter for or not recommend it for?
Abid: Emerging markets. I don't think Flutter is good for them right now. The Flutter VM and stuff does add two megabytes to your binary, which in this first world we don't care, but for an emerging market that's very heavy. If you're building an application for the emerging market, use a PWA. Go to HTML5 and build something very solid on that, but if you're building something for the North American European markets and stuff, I think Flutter's great for that.
Participant 6: There is another cross-platform framework, Xamarin. I'm a Xamarin developer, so actually Flutter took a lot from Xamarin forms. The only thing is, in Xamarin forms you defined one interface using XML-like language called XAML, but it's a declarative language. One thing I noticed is that yes, it looks really cool and fast when you make changes to the code and the hot reload. Hot reload is something that's not available in Xamarin forms. Is there anything else that you can think of that's quite different between Xamarin and Flutter?
Abid: I haven't done a lot of Xamarin. A lot of people ask me in general what's different between React Native and Flutter. I don't know a lot about Xamarin, but maybe I can answer the React Native question, and if you know both you can probably do a comparison there. The way you write React Native code and the way it deploys is essentially what it's doing is you write your React Native, and it says, "Hey, React Native VM, I want an Android button." Then it will generate a native Android button for you, and it will add it to the screen.
What Flutter does is Flu,tter says, "We don't want to do that. We're going to control the entire rendering process." There's a pro and con to this. The pro is that they can guarantee consistent performance across all devices, so even if you have a low-end Samsung device, Flutter and Google have enough resources to make sure that that VM runs 60 frames, 120 frames per second on that device; versus React Native, where it will say, "Cool, I'm going to throw an Android button." That will most likely work fine, but what will happen is you'll run into the OEM design issues where HTC, Samsung, all these Android manufacturers, add these weird paddings and buttons.
There was a big company in Toronto that I consulted with for a while. It's a massive company, 100 million-plus installs on Android and iOS, and they said that they built a React Native app. They deploy it to 100 million of their users, and what they found was an insane amount of issues with phone compatibility, where they have tons of users in the Philippines, tons of users in all these other places and the phones were just being weird because it looked fine in iOS. Apple controls that environment, but on Android, on their Pixels, on their device, it would look great; on some other phones it just totally broke. Flutter really want to invest a lot in, and they're investing time into Flutter because they know that they'll get a pixel-to-pixel match on all the phones and devices.
Participant 7: Do you know if Flutter can support other languages like TypeScript?
Abid: Probably not, I don't know. I would think no, only because of how close the Dart and Flutter teams are, and how important Dart is to Google and how much time they've invested in it. With that said, if someone is smart enough here, they can probably build something that is an interface into Flutter using TypeScript, but I don't think Google's probably going to do that.
Participant 8: Have you ever come across any OS-specific bugs, so an iOS bug, something happens on just one side or the other? How hard is it digging into those specific bugs?
Abid: Those bugs were a lot more prevalent back during the betas, so yes, I did run into early betas. So far on the 1.5s, I haven't come across, but I'm going to mention that if you do go through them maybe you’ll find some people running into it. There are two types of issues, they are super hard to debug. If you do run into an issue, that's probably just a UI issue, you can fix it yourself. Mostly the bugs that were happening during the beta were around VM issues, so iOS compatibility, unlike in iOS 4 that was causing some issues. So if you do run into something, it's probably a VM bug, which you'll have to tell Google to fix, but it's very rare that you’ll run into a UI issue that has anything to do with the OS, simply because your rendering it.
See more presentations with transcripts