We talked with Tim Sneath, Google's product manager for Flutter and Dart, about how both the language and the framework have evolved over the last two years, how they're being used today, and where they're headed.
The Interview
Evrone: Your job title is "Product Manager for Flutter and Dart". What does it take to be a product manager not for consumer products, but something developer-related, namely the framework and programming language?
Tim: I’ve never been a product manager for a consumer product, so all I know is developers! But in general, being a product manager is about combining business strategy, customer feedback, engineering resources and a certain amount of predictive intuition into creating a product that is hopefully loved by its target audience.
Flutter usage has grown hugely over the last couple of years, and many of the challenges I spend my time thinking about relate to managing the trade-offs associated with that growth: how much of our resources do we dedicate to building new features versus polishing existing surface area? How do we divide our attention between internal users, enterprises and startups? How do we support new form factors like foldables and platforms like Windows and macOS without spreading ourselves too thin?
Evrone: There seems to be something of a renaissance for frameworks that build UI with code at the moment, with Flutter, Swift UI and Jetpack Compose all being announced or released in the last couple of years. And hot reload is something you're talking a lot about with Flutter. What trends are you observing here?
Tim: I think developer productivity has been sacrificed at the altar of innovation for some years now. I was at university when Visual Basic 1.0 came out, and in many ways that represented a high water mark for ease of UI development. I mean, think about it — before VB, building a Windows app involved writing hundreds of lines of C, using a DOS editor and command-line compiler, and a painstaking edit/compile/debug loop to get it running. Visual Basic brought hobbyist developers the ability to paint their UI design directly on the screen, along with “edit and continue” — the ability to pause an app, make changes and then continue without recompiling.
Over the last couple of decades, it’s got harder, rather than easier. We’ve added many layers of complexity to once-simple operations, with preprocessors and transpilers, deeply-nested module hierarchies with unclear transitive dependencies, and stacks that shift so fast your app is obsolete before it’s complete.
We’ve got a long way to go — but stateful hot reload is a step forward to bringing back that “edit and continue” ease of UI development. I’m hopeful we can continue to bring down the cognitive load of turning an idea into an app with Flutter, so that developers can focus more on what they want to build and less on how to express that in code.
Evrone: The war between "Native OS widgets" vs "Pixel-drawn own widgets" is decades-long, starting with the first Qt versions. Given your experience with lots of big companies that create mobile apps, what is the current situation?
Tim: I think that’s a false dichotomy. The only thing that matters is quality: can you build a beautiful experience that is worthy of a discerning user? And quality has little to do with which binary renders a particular pixel on the screen: it’s a combination of performance, attention to detail, and technical capability. Some of the most awarded games out there are built with the Unity games engine, but nobody cares whether Monument Valley uses ‘native OS widgets’ or not.
We believe Flutter is to apps as Unity is to games: bringing native performance and visual finesse to apps regardless of their target platform.
Evrone: How is Dart related to the all-new Google "Fuchsia" project? It's listed as one of the "recommended" languages, alongside C++, Rust and Python.
Tim: Fuchsia is an experimental open source operating system that we’ve been working on for a little while. We don’t have a lot to share about it at this stage, but the source code is all public. Flutter supports building for Fuchsia, so you’ll see various references to it in the Flutter source code. And of course Dart is the language of Flutter.
https://github.com/dart-lang/sdk
Evrone: Big companies like eBay or BMW embrace Dart+Flutter combo for their mobile projects. What are the main selling points for them?
Tim: For a lot of them, it’s simply the ability to unify their app development with a single high-quality solution. When you think about it, it’s crazy that most consumer-facing apps have multiple teams working on exactly the same business problem, with the same deliverables and timescales, all doing the same work just with a different language and tool for each of iOS, Android and web. There’s almost no other analog in software development today: companies don’t willingly implement three new separate payroll systems. When teams discover that they can not only build a high-quality native experience for multiple platforms at once, but that they can be more productive than they would be on any individual platform because of features like stateful hot reload, that’s an easy sale to make!
The biggest challenges are non-technical: many companies have organizational alignment around their target platform, so there’s sometimes initial resistance from teams who don’t want to merge into a unified effort. And of course, we’re still a young platform, so more conservative companies have innate skepticism for a path that isn’t well-trodden. But time will fix that problem: our ecosystem of packages and plug-ins has grown 5x over the last year, and there are tens of thousands of apps in the store that demonstrate Flutter is capable of delivering quality at scale.
Evrone: In your opinion, is it better for developers to create separate layouts for tablets and mobile phones, or are modern technologies already potent enough to create "adaptive" UI's that perfectly fit different screen sizes?
Tim: The challenges with adaptive UI design are both in the framework and in the tooling. The web has had media query support for years, but it’s still tough to build an experience that scales evenly across form factors. Flutter makes this possible, and Matias Duarte recently demonstrated one tool prototype that we’re experimenting with for Flutter.
Evrone: What IDE do you prefer right now? Android Studio, JetBrains products, VSCode or something else?
Tim: Personally, I’m used to VSCode, because I came to Google from the Visual Studio team and it’s a product suite that I’ve spent a lot of time with over the years. And I’ve loved the work Danny Tuppeny has done on building out the Flutter and Dart extensions; it’s been great to see Flutter become a seamless experience from within VSCode. As a team, of course, we don’t really care what programming tools you use, whether Android Studio, IntelliJ, VSCode, Vim or Emacs!
One project that’s interesting to me is the Language Server Protocol effort, which is trying to bridge the gap between editors and languages with a common protocol. Alongside a similar project going on for debug adapters, we hope that this gradually allows developers to choose tools that fit their needs without language authors having to duplicate their work across each of those tools.
Evrone: There are rumours that Dart was meant to replace JavaScript in web browsers but now pivoted to support the Flutter. Is it true? And what is Dart usage outside mobile app development?
Tim: It’s true that Dart’s origin story began as an outgrowth of the V8 team, who were prototyping new approaches to app development. But that Dart bears little resemblance to the current language, which was reborn as a client-optimized language a couple of years ago with the launch of Dart 2.0. Today’s Dart is focused on a specific technical envelope: platform portability across web, mobile and desktop; fast object creation and garbage collection; VM code injection during development with native compilation at runtime. That makes it particularly suited for client scenarios, whether Flutter, CLI or business logic.
Evrone: What is your personal opinion about the "Full-Stack" idea? With languages like Dart that can perform well both on frontend and backend, is it viable for modern-day developers to author all parts of the application?
Tim: I don’t know about others, but I find it hard to keep up just with client technologies! It’s great to have a language with the flexibility to run across mobile, web, server and cloud, and we’re seeing various folk using Dart to great effect on the server, often to share existing business logic that they’ve already written for the client. I guess it’s viable for developers to be full-stack developers: since there are plenty of people who do just that. But specialisms are increasingly necessary as applications grow in scale, and I don’t think you’ll find many true full-stack developers at Google outside startup incubation projects.
Evrone: Flutter for Web is now in Beta and Flutter for Desktop is an early Alpha. What future do you envision for them?
Tim: They’re both in development still, but we’re getting ever closer and we’ll have some announcements soon about the progress we’ve made on both fronts. We never designed Flutter to be mobile-only; it was always designed as a portable UI framework, and iOS and Android just happened to be the first two targets. There are new challenges for desktop-class applications: the form factor and input methods are different, they often use different UI metaphors, and need to be able to resize and handle multiple windows. Added to that, the web is ephemeral, unlike an installed desktop or mobile app.
Both web and desktop are exciting in different ways as targets for Flutter. The web is more technically challenging, particularly if you want to avoid the ‘uncanny valley’ of older projects like Flash and Silverlight. We want the web experience to be seamless enough that you need to look at the source code to be sure whether a page is using Flutter or not. We’re also making good progress with performance: most recently, we’ve been completing a CanvasKit backend for the web that offers tremendous gains.
Desktop offers an intriguing set of use cases: from giving developers an easy route to the billion-plus Windows, macOS and Linux machines, to greatly reducing the friction for new users to get started with Flutter. I’m increasingly using desktop as my first target when working on a Flutter app, since you don’t need an emulator or a connected device to see the results.
Even more intriguing is that the choice of web versus desktop is late-bound with Flutter. We have several projects going internally where they are mid-development, but still haven’t picked whether they plan to ship as a natively-compiled desktop app or a PWA. It’s great to be able to offer that level of flexibility.
Evrone: Can you compare Flutter with React Native? What are the gains for an average developer to learn a new programming language and drop a familiar JavaScript?
Tim: The reactive programming style inspired Flutter a great deal in the early days. It’s a major shift as compared to the message passing and retained model styles that have been prevalent for a long time. But it’s tough to answer this question without being seen as disparaging another framework, which isn’t my intent. They each have their strengths and limitations, and there’s plenty of opinion out there without me adding to it!
Evrone: If you could travel back in time and change any feature of the Dart language, what feature would it be?
Tim: Ha! Without question, the feature we’ve spent the most time on over the last few years has been strong mode: bringing a static, sound type system into the language. The original concept of Dart was as an optionally typed language, with the ability to express types through annotations for development purposes, but no runtime semantic effect. In Dart 1.x, this was a core principle of the language, but over time the limitations of that approach have become apparent, as even the web world has moved towards type checking with TypeScript.
Making a change of this magnitude to a living programming language was no small feat, but the engineering team completed this work with Dart 2.0, in the process migrating millions of lines of Dart code inside Google’s monorepo to a new common frontend compiler. Now we’re building on this work to add sound null safety, providing verifiable non-nullable types throughout the framework.
We’ve spent perhaps 50+ engineering years on reversing these two design decisions, but the end result is a sound, null-safe language with battle-tested compilers to JavaScript, Intel and ARM machine code from the same source code. That’s unique, I think.
https://github.com/flutter/flutter
Here at Evrone we're really excited by the continuing evolution of Dart and Flutter: the more powerful they become, the better the mobile app solutions we're able to craft for our clients and partners, many of whom have already seen first-hand the benefits the Dart ecosystem brings in supercharging development!
