This blog provides show notes for our September 23 webinar, “Flutter Q&A with Chris Sells, Senior Product Manager at Google on Flutter – Part 2.” If you missed the webinar, or would like to watch it again, please see our YouTube channel or watch it here.
During this webinar, Chris welcomed all questions from the attendees and dispensed answers only the Senior Product Manager at Google on Flutter could provide.
That’s a good question. It used to be a much smaller list, and I could just tell you individual resources. There are certainly training courses that I’m a fan of that I actually started my Flutter learning journey on. It was the one from App Brewery, which is about 25 hours of online Dart and Flutter, which I still recommend. It’s a little older. It doesn’t, for example, include null safety, but it does cover a wide range of the basics which are pretty great. There’s also a book I really love called the Flutter Complete Reference. It’s, like, a phone book. A 500-page tome. The first 200 pages are just Dart. And the nice thing about that book is it’s relatively recent, so it includes null safety and the latest and greatest recommendations for both Dart and Flutter.
But there are a number of other resources as well. For example, the Flutter Apprentice book is pretty great. And pretty much any Coursera, Pluralsight— anywhere you want to look for online training materials, there certainly are going to be Flutter courses there as a way to get started. And, of course, I would be remiss if I didn’t mention the tutorials and samples on Flutter development in our own docs. Our developer relations team and docs team at Flutter are second to none. They also have an excellent YouTube channel with all kinds of great things. Plus the Flutter community is very prolific as well. There’s always new blog posts, more than I can keep up with. And when I have a Flutter question, “How do I do X, Y, Z in Flutter?” I often end up in community sites’ blog posts, learning about bits and pieces of Flutter that I didn’t know the details of. So, definitely, there are plenty of resources out there to get you started.
I will give you one meta tip and trick, which is use Flutter DevTools. Once you’re in your debugger, you’ve started your debugging process for your app in IntelliJ, Android Studio, or Visual Studio Code, you can always start up something called Flutter DevTools. Flutter DevTools has a wealth of tools in it for tracking app size, CPU usage, memory leaks, stutter in your apps, etc. If you’ve got a shader warm-up that’s happening in the middle of your animations that you would like to pull out and do as part of an app initialization process, we have tools that do that. If you’ve got giant images that you’re showing as thumbnails, pulling in all that memory that you don’t need, we’ll show you that. Flutter DevTools, learn it, live it, love it. That’s my one tip. Use Flutter DevTools.
There’s a number of things that make Flutter an important choice when it comes to performance. First and foremost is that while we are well-known, we’re well-known for having a very nice development experience—composable, declarative, reactive—it’s a very nicely implemented API. And, of course, hot reload—being able to make instant changes to your app while it’s running. These are all very well known in the Flutter community. But also, because we depend on Dart and the Dart language and the Dart platform, Dart provides native compilation. So, while you’re using a JITter to have a great development experience, you’re going to get native code. If you’re targeting desktop, you’re going to get x86 code. If you’re targeting mobile, you’re going to get native ARM code. If you’re targeting the web, you’re going to get highly optimized JavaScript code. The idea being that whatever the performance is of the underlying platform, if your phone runs at 60 frames a second, that’s what you get out of your Flutter app. If it runs 120 frames a second, that’s what you get out of your Flutter app.
And we get that because we are generating native code. And we’ve implemented the UI ourselves. There’s no going back and forth. For example, there’s no JavaScript bridge that might cause stutter or tearing or jank. Instead, because we’ve implemented everything when it comes to the Cupertino design language, the Material Design language, in Dart and Flutter ourselves, all the framework compiles down to the same native code that you get when you run your app. So, those are things that make Flutter a really good choice when it comes to performance.
Yes. This is a feature we have in our Android Studio and IntelliJ plugin so you can bring up performance tools there. This is something that does not yet exist in DevTools, but it’s on our roadmap to bring it to DevTools as well, so that you can use it from Visual Studio Code, etc. It turns out DevTools was built after IntelliJ and Android Studio as a way to make those same functionalities that we had in IntelliJ and Android Studio available for Visual Studio Code developers or command-line developers or whatever your favorite editor or IDE of choice is. DevTools is standalone. The bulk of our effort for those kinds of tools has been in DevTools. But there are one or two cases where we haven’t yet brought all of the functionality in, and this is a case where you need the Android Studio or IntelliJ plugin for Flutter to get this specific functionality.
My goal is Flutter everywhere. Everywhere there are pixels to move, ultimately, I want Flutter to be there. And, of course, the Flutter team itself has taken on a huge chunk of this work by supporting the six most popular platforms that there are in the world. But it turns out that the long tail of other devices and embedded devices is more than we can do, but we’ve been working with partners to bring Flutter to other places as well. For example, Samsung is busy bringing Flutter to Tizen and their family of devices. Both Sony and Toyota are busy building Flutter support into embedded Linux for various applications. There have been folks that have built Flutter into televisions and devices and set-top boxes. I’ve talked to customers who want to put it in industrial kinds of devices where they need screens and displays. The future for Flutter is taking that core engine, which is highly portable, and then building the embedding APIs into the various devices, the long tail of embedded devices, so that over time, your Flutter knowledge becomes more and more important, because there are more and more devices you can target with it. My vision for the future includes Flutter, Flutter everywhere.
I’ll start with the second part first. Yes, there are hidden parts in the Flutter process. We maintain secrets, certifications, API secrets, etc., outside of our public GitHub repo. And we use a combination of proprietary internal Google technology for managing secrets, as well as the Google Cloud Platform Secret Manager. We use that for a number of secrets, and I can recommend that for folks. It’s not difficult. I would say that the core of what we do in our projects is use those services. Where we need them in our build process, we set up service accounts with access to those secrets that are not engineers on our team.
We try to keep the number of engineers on our team that can access those secrets directly to the barest minimum. Mostly it’s about setting up service accounts that have access to those keys so that we don’t leak them. We don’t share them with the world in their raw form, but rather we use them for signing things and accessing APIs, etc. So, the number one tip I will give you is please don’t check it into GitHub. That’s the thing you want to avoid. Anything you do on top of that there’s a number of solutions. That’s your first tip. Don’t check it into the repo.
The short answer is yes, there will be a way to open multiple top-level windows. This is useful for any number of things. I want multiple top-level windows. I want a window and a tool window that I can drag around. I want a context menu that doesn’t have to be adjusted to make sure it’s inside the window. Because right now, for example, when you do a context menu, a pop-up menu, we move it over so that it doesn’t hit the edge of your screen and then stop drawing, because we have only one window, so we can only draw in that window. If we let it get too close to the edge, then it’s chopped off. With top-level windows, you can have that context menu overlap—it’s a separate top-level window—or dialog boxes that you can move outside the contents of the screen. There’s any number of really good use cases in a desktop operating system for multiple top-level windows. We do not support that today. There are some plugins that kind of provide some of that support.
It turns out that the hardest part of this work is not to build support for, “I want to draw in another window.” Obviously, we know how to draw in an operating system window. We could create another window and draw on that. That’s fine. The hardest part is all of the assumptions that we have made about windowing resources and what the root window is, and the resources associated with that in static variables, because, when we initially shipped Flutter, there was only one. To this day, there’s only one. On the web, there’s only one window. On Android and iOS, there’s only one window. It’s when we push into desktop when we look at this problem and say, “Oh, well, there might not be one window.” And we have some re-architecting to do, and we have a bunch of test infrastructure to build up to make sure that we bring those resources out.
And this is work that we’ve already done some initial prototyping, some initial architecture work for, and we’re actually working with the Canonical team who builds our desktop Linux for Flutter. They are doing a bunch of work for multiple top-level windows. This work is underway now. It is unlikely to be part of the initial desktop stable release when we make that available, but hopefully soon after. This might make sense for a split screen. I could see how that would be. The good news is right now, you are not blocked on multiple windows to do split-screen work. For example, we’ve been working with Microsoft to bring split-screen support to Flutter for their Duo product and things like that. You can use that today. Essentially, it’s one window that expands or contracts based on notifications of the device, so you’re not blocked on that. But I agree. Whoever asked this question, that’s a good question, and you could imagine multiple top-level windows for split-screen support in the future.
I’ll start with layout editor. The traditional way to kind of build UI is with some drag-and-drop layout editor where you probably are reading and writing from some machine-readable file format, like some variant of XML. Microsoft has their XAML. Android has their layout XML files. That’s a pretty common thing to be able to do. Those files are read at runtime by the framework to produce a layout, and then the developer writes the code as separate from the layout. But what always happens then with those layout languages is you start wanting to do conditional layouts for scenarios like, “I’ve got this data. When it’s this big, I want the layout to look like this, but otherwise, I want it to look some different way,” and you start trying to build conditions into this WYSIWYG editor, or into this underlying declarative format. What you really want turns out to be, “Gosh, I really want the full support of a programming language when it comes to the conditional layout.” So what we did with Dart and Flutter was we said, we’re just going to let people write that code. To provide for WYSIWYG layouts, we have hot reload. You run your app. You write your code, and you could just see it as you do it.
So, we do it differently with Dart and Flutter. We find that that is something that Dart and Flutter developers really like. However, there is still demand for, “Gosh, I’d just really like to drag some things around the screen, and that’s how my designers work. And can I just work with my designers to take their designs and throw them in the code?” We are seeing these products spring up. FlutterFlow is a low-code solution that does that. It’s a whole design surface where you lay things out, and you declaratively say, “This is where your data comes from, and it plugs into Firebase.” And it does that kind of thing for you, and then it will generate the Flutter code that implements the layout that you’ve made.
One such product is Supernova. Another is Codelessly, where you take Figma designs and augment them and turn them into Flutter code with various levels of capability. We are unlikely, as a Flutter team, to build similar products ourselves, but we work very closely with all of those tool vendors to make sure that you have a good experience. For example, the Grant Skinner organization, working with Adobe to build the Flutter plugin for Adobe XD. Take your design from there, and out comes Flutter code. They just got to a 3.0 version. They’re working hard to make sure that the code that comes out is really something you can use. So, the team itself is committed to the foreseeable future to making the code-based experience as good as possible while still working with partners to do the layout editor kinds of things.
I think the second part of this question, or rather the first part is, “What about its own editor? How do we have an editor built into Flutter?” This comes up a lot, and it has been coming up more recently. About a year ago, we kicked off an effort. We gathered a bunch of interested members of the community together, and we started pulling together some requirements for a rich text editor, something beyond what text field can give you, which is multiline text, with all kinds of support for hotkeys and mouse and keyboard-based selection. It does have a number of really great features, but it doesn’t do rich text editing.
So there have been a few efforts that have led to a rich text editor. The most recent one that I’m familiar with, the most fully-featured one, and one that we’ve been working pretty closely with as a partner, is Matt Carroll’s Super editor, which does all kinds of great rich text editing and selection and multimodal kinds of things. But that’s not the only one. There are more, too. The thing that we do on the Flutter team is we work with these community efforts to unlock whatever it is they need in the framework to enable them to have a rich, high-performance, full-capability experience when the community is building their rich editors.
That is an excellent question. Do you still recommend REST and JSON? I don’t believe I ever recommended REST and JSON. There are a number of options, and I have been in the industry long enough to remember JSON as a payload, even before we had this thing called REST. Then we had REST, and then we had SOAP, I remember, and we were passing around XML documents instead of JSON documents. It looks like REST and JSON has won out, that SOAP has kind of died off. But then there are new technologies, too. There has been a resurgence in binary technologies. For example, Google has a binary RPC transport that works well in this kind of thing, and it’s something we expose from our own Google services as an API, called gRPC.
And then, of course, there’s the GraphQL kind of world. Firebase itself has this idea of a real-time query, for a real-time database, and Firestore. So there’s this kind of spectrum. I am a fan of REST and JSON for its simplicity, and there are a ton of these existing APIs. Of course, Dart and Flutter fully support that, so if you’ve got a .NET back-end that does REST, then it’ll work just fine with your Dart and Flutter apps without any problems. Of course, Firebase is something that we see a lot of Flutter customers using. And that real-time query portion of it is pretty great, which means I can set up a live query, and that works really well in a UI environment where multiple users could be making changes to the data, and as that happens, Firebase just says, “Oh, and by the way, the data’s updated.” Then Flutter is triggered, and it grabs whatever the latest data is, and all the caching and pulling down has already been done. It’s a pretty great developer experience, and it leads to a pretty great user experience.
That brings me to GraphQL. My favorite part of GraphQL is it takes that idea of the live query and makes it kind of general purpose. Any GraphQL back-end—it doesn’t have to be Firebase, or even a database—can have this idea of live queries. And GraphQL has another really great characteristic, where the back-end can expose this rich data source and the front end can just say, “Oh, but I only need this narrow view on it.” So you can essentially build access to your API in the client itself. A mobile client which only wants a little bit of data, or a web client that wants a lot of data, or anything in between, gets to tailor that as part of the query, as part of the filtering, as part of the paging built into GraphQL. This saves the engineering team from a scenario where every time the mobile developer says, “Oh, I need an API that returns this data,” and the server side says, “Oh, call this API,” and then the mobile developer says, “Well, yeah, it provides that data, but it provides all this extra data that I don’t care about, and it’s missing these three things that I do care about, and I have to make another round trip.”
GraphQL essentially kills that argument. The server side can just provide all the data, and then the client side can provide the filtering, and get exactly the data it wants. I’m a fan of GraphQL, as maybe you can tell. It’s fully supported by packages on pub.dev for Dart and Flutter because, of course, it’s just based on underlying network technologies that we provide out of the box in Dart.
As far as the recent discontinuance of Dart Aqueduct, I didn’t know about that. I don’t have any feedback or comments on Aqueduct. Specifically, I do know that there is a small but growing community around a package called shelf in pub.dev for doing server-side development. It’s something that we have been using ourselves, as we push into Dart containers, in support for Cloud Run. Ultimately, I’d love it if Dart ran in Cloud Functions, in Firebase functions. And we’ve seen that the shelf API is growing in popularity for that kind of work. So, that’s what I have to say about that.
The growth of the Flutter community looks up and to the right. We continue to be amazed at, not just the growth in the number of Flutter developers, but also the growth in usage. We routinely, at this point, hear about things where Flutter is being used, or this vendor is supporting Flutter, and we didn’t know, or this group or team is forming around Flutter, and we didn’t know. At this point, the Flutter team, to foster growth, is all about empowering these groups to form these technology efforts, to form outside of us, without depending on us, and we try to enable that.
For example, anyone that wants to can publish a package or a plugin on pub.dev. They do not need our approval. We provide the infrastructure for people who do that to gather likes, and we publish popularity, and we do some static analysis. We provide the infrastructure for the entire community to build on. Likewise, when it comes to these technical partnerships with Canonical and Sony and Toyota and Samsung, because our project was open source, these efforts all started without us. Eventually, we heard about it in various stages of completeness. But the way we foster and grow the Flutter community is really to enable the ecosystem, which, again, we all continue to be stunned at all the places we hear where Flutter has taken root and we didn’t know. We didn’t know that happened until sometime later. That is the ideal, that people can move forward with their Flutter plans without being blocked, or needing approval by the Flutter team.
That is an excellent question. We had a variation of this conversation internally, literally earlier this week, which is, how do I do the opposite? For instance, I’ve got a Flutter web app, and I have some existing web content that I just want to drop in. For mobile apps, we have this thing called the WebView that is specifically for that, but it doesn’t work on the web right now. The debate was, “Do we make WebView work for Flutter web?” The answer was, “The implementation seems so easy. It’s just an iframe, right? You just take all the content, and you drop it into a properly configured iframe, and off you go.” Just because it’s easy, doesn’t mean it’s not still a super useful thing to do because people want to build their apps, target the web, have the right thing happen; target mobile, have the right thing happen; target the desktop; and if the WebView can easily handle that, then it should.
But this is the inverse: how do I embed a Flutter web app in a webpage? I will give the same answer, which is iframe. That is currently how we recommend folks do it. There is some possibility in the future where we could build a Flutter web app as kind of a standard web component, and define that interface and implement that interface. So you could drop it in as a tag in your existing Flutter web app, and potentially provide some programmatic hooks and notification hooks, and all those things that you would want from a web component. We could do that. So far, we haven’t had a bunch of demand for that, and it’s not currently on our roadmap, but we have considered it. But right now, I would say iframe is the way to go.
My quick answer to that is honestly not very much. I’ve worked with so many customers that have said, “We set out a three-month prototyping phase to go and see if we could get a few of the screens from our existing mobile app into Flutter.” Three weeks later, they’ve done all of the screens, and they’re like, “How did that happen so fast?” They just had no idea. Dart is a modern language that has the modern C-style language features that you want. It’s got async and await. It’s got generators. It’s got object orientation. It’s got enums. It’s got the extension methods, relatively new. We just added null safety, which we’re pretty proud of. It’s got the modern features you need.
I’ll tell you a story. Early in the days of Dart and Flutter development, we sat people down, and, for a user experience research study, we gave them a bunch of code, existing running Dart and Flutter code. We said, “Here, run this code, and now add these features.” And 45 minutes later, they’d done so, and they were successful, largely. And they said, “What language were you programming in?” At the time, Dart and Flutter had not achieved the fame that it has today. They’re like, “I don’t even know the name of the language I’m programming in, but I was able to, with the context clues of existing code, just write some more, and it worked the way I expected,” and off they went. We find that to be the case. Now, when it comes to things like state management and what it means to build a modern UI with the declarative APIs, if you’re used to older imperative API style, it’s very different. I consider it better, but I’m biased, obviously. But that takes some time to wrap your head around.
We do have resources on the Flutter dev docs that say, “If you’re an existing web developer or mobile developer, come, and we will help you understand the different concepts. Here’s how to think about it if you’re a web developer. Here’s how it’s different. Here’s how it’s the same,” as a way to kind of bootstrap that process. Honestly, I can’t count the number of times I’ve heard someone say, “I was not a mobile developer. I picked up Flutter, and within two weeks, I shipped my first Android and iOS app.” And they were just completely surprised that they were able to get up to speed and be productive so fast. So, the bottom line is some. Not very much.
My answer is you shouldn’t use it. You should go and use the provider package on pub.dev. So, the idea of an inherited widget is I want to stick some data into my widget tree at some point high in the context so it can be shared amongst all the widgets lower down in the hierarchy, which saves you from having to pass that data from widget to widget to get it to all the child nodes in your tree that want it. The idea of InheritedWidget is you stick it in the widget tree wherever you need it to be shared, and then anywhere where you need it, you just reach into the widget tree and say “I want access to the InheritedWidget that’s holding my data. Now I have it. Now I can get my data.” Then, when that data changes over time, the whatever widget will be triggered to rebuild. That’s the mechanism. I want to stick some data in the tree, I want to pull it out, and then when that data changes, I want to rebuild that widget so that I get a new view of that data.
It is conceptually just that simple, but the amount of code you have to write is silly. So, I will say don’t use InheritedWidget. Go and use the Provider package, which is a package built and maintained by one of the Flutter community members, that takes all that down to all the individual concepts, down to a single line of code. So if you want to stuff something in the widget tree, you don’t have to build your own derived type, and expose the thing, and implement the pattern, and so on. You can just call one line of code and say, “I want to stick this into the widget tree.” Later, if you want to pull that out of the widget tree, it’s one line of code to do so, and you can either choose, “I just want to read it and don’t rebuild me,” or “I want to watch it for changes over time and rebuild me when it changes.” The Provider package just does all that. It is literally an order of magnitude less code. Now, it turns out not to be a bunch of code anyway. It’s pretty simple conceptually, but even so, I would just not use InheritedWidget. Go use Provider.
You could be asking this question from two points of view, so I will answer both. You might be interested in capturing and analyzing performance metrics from a developer standpoint, in which case we have full support for building profile mode, and timing individual parts of your app. All of that is exposed with the aforementioned Flutter DevTools. I will point you to Flutter DevTools and the profiling, and you’ll find that in the docs, and they’ll tell you how to do all of that stuff.
If you want to do it at runtime, asking “How is my app performing in the field?” then I will turn you to a Firebase plugin called Performance Monitor. You can see this on firebase.flutter.dev, along with all the other Firebase services that we integrate into Flutter. Right now it’s in beta, so that’s what I would recommend if you want to do it for your app in the field.
I’m going to cheat on this question, because I don’t know the answer, and I purposely didn’t go and figure it out. Instead, what I will tell you is how you find the answer to this question. What I would do is go to pub.dev and type “video player,” and you’ll get the one from the Flutter team that does the raw video playing but doesn’t have all those cool features that you’re asking for. I would look at the results on pub.dev, and I would look at them through a couple different lenses. One lens I would use is, what’s the popularity? What are other people using who look for video players? This popularity is based around actual usage, people downloading it via pub get. Next, what are the likes? How many people have used this, come back to the site, and said, “This is awesome. I like this. I recommend it.” You’ll also want to look at the pub points. Pub points is a measure of quality via static analysis, things like docs. We do a set of static analysis, and it’s all listed on the website.
Another metric I’ll ask you to look at is a little flag called Flutter Favorite. The idea of Flutter Favorite is it’s kind of an editorial look at packages and plugins that we’d like to highlight on pub.dev. Flutter Favorite is essentially somebody nominates a package or a plugin. The Flutter ecosystem committee gets together on a regular cadence, about once a quarter, and looks at all of the recommendations, people saying, “This one’s really great. This should be a Flutter Favorite,” and we take a look at it. We look at the pub points and the likes and the popularity, but we also have a number of Flutter Favorite-specific metrics that we look at, both from a static analysis point of view and from a subjective point of view. We look at the overall picture. What’s the readme like? What are the samples like? Does it have the runtime characteristics that we would expect from such a package or plugin?
Then, once the ecosystem committee says, “Here’s a handful that we think we really want to be marked as a Flutter Favorite,” then we turn that over to the engineering team. Then we ask them for a code review, and they read through it. It’s not a standard Google code review, but it is pretty rigorous. We look for things like security problems and concerns. We make sure nobody is mining Bitcoin in this package, or that there are any egregious, obvious memory problems or performance problems. If we think that the source code itself is generally in good shape, then all of that passes, and that’s how a bill becomes a law. That’s how a package becomes a Flutter Favorite? So, while I don’t know the answer to this question and a thousand others just like it, I’ve hopefully given you kind of a step-by-step guide on how to go and figure out the answer for yourself.
That is a good question. The short answer is no, I have not. I am not a designer. I am a coder, an engineer. When I sit down to build my Flutter UIs, I’m most comfortable writing code and using hot reload. That said, I know this is a popular plugin, and gaining in popularity. They just released their 3.0 version, based on feedback. As I mentioned there, the goal was really about how do we get production-level quality code out of it that engineers would actually want to keep and use. But that plugin has been popular, and what it’s helped do is kind of bridge that gap. How do we empower the engineer to get from the designs into running code as quickly as possible? There’s a range of what the engineers need to do. On one end of the range is, “I actually want to specify enough information where I can get running working Flutter code that looks and feels exactly like that design.” And there are tools that enable that, including this Adobe XD plugin.
On the other side is, “We have a bunch of designs, and there’s a bunch of things that are really hard to program, and it’s really tedious, like the specific values of all the colors in the design, and the specific font sizes, and all that design language that really makes up a design, that says, ‘When I use body two, I want it to look like this so it can match the design.’” Over the lifetime of the project, as the design changes, you want a super-easy way for the designer to just tweak the colors and so on. You don’t really care as a developer. You just want it to look however they decide, to be able to regenerate that code, and then the styles are automatically updated. All of your code that you’ve carefully crafted to pull the data via REST, or GraphQL, or whatever is still preserved, and you don’t want to have to mess with that.
But all of these key underlying design language kinds of things are in the same constants. They just have the same place in the code. It’s just different values. Then you rebuild it and off you go, and the designers are happy, and the engineers are happy. There’s this wide range of scenarios you want to support, and what we’re seeing is tools evolve. Adobe XD, Supernova, Codelessly, FlutterFlow. These tools evolve in this space to cover the various kinds of click stops on that dial. So, what I’m hearing is that people are being successful, and it is turning into a very useful way to speed up development, that interaction between the designer and the developer. So we’re seeing success there.
The App Clips I think we support already. If you look at some of the recent announcements, I think the 1.22 announcement, the 1.22 release of Flutter, last year, talked about App Clips and how you can take advantage of them. The Watch is a different story. The current run of Watches, a small screen, is not a problem. Flutter can easily run on a small screen and a big screen. That doesn’t matter. But it has relatively small resources. The runtime that comes along with Flutter is like, a 4- to 5-meg runtime, and it provides the engine that accesses the underlying high-speed GPU. For mobile apps and desktop apps and web apps, none of that is a problem, but for these very, very tight watches, we are finding that that is above their threshold. So we don’t have plans for watches anytime soon.
That is a good question. I have certainly kept my eye on Blazor. My understanding is that fundamentally, Blazor is all about writing your code in .NET and C#, and out comes WebAssembly that runs on the client, specifically targeted at the web. The core difference is today, we generate highly optimized JavaScript code. This is code that we have been using internally at Google for a decade, so it is very highly optimized. We have been working with the Chrome team. We’ve been prototyping support for WebAssembly. Future versions of Flutter may well use WebAssembly instead of JavaScript, if that has better performance characteristics. If it has lower latency, if it has smaller download sizes, if it has faster runtime. We’re still doing that engineering work to see if that’s a good switch, but if it is a good switch, then we’ll take advantage of WebAssembly in the future.
The short answer is yes. For every platform that we target, you can always drop down and write native code. Right now, the embedder in Windows is C++. Any code you want to write with C++, which, by the way, enables not only access to all the Win32 APIs, but all the .NET-based APIs through the magic of compiler switches. You can write that code.
Yes, it does. As I said, we’re looking at generating WebAssembly in the future if that’s a win for our customers. In the meantime, if there are WebAssembly libraries that you’d like to take advantage of, again, just like the Windows 11 question, you can always drop down, in your Flutter web application, and write JavaScript. With JavaScript, of course, you can load up a WebAssembly package and call the APIs, and so on and so forth. If there’s some great library that you want to host in your Flutter web app that does WebAssembly, you can certainly do that.
What we don’t yet have, which I also want us to do in the future, is from plain old Dart code, no matter what platform you’re targeting, just load up a WebAssembly module and start calling into it directly. We don’t yet have that support, but that is also something that we have looked at internally. I don’t have a roadmap for any of that or even a commitment that we’re going to do it, but I personally would like to see us do it, and we have done some experimenting there.
During this webinar, Chris Sells provided a treasure trove of valuable information about Flutter. We hope you enjoyed it and please keep an eye out for our future Flutter webinars.