Today is March 3rd, 2021 — the day of Flutter Engage. Here are my thoughts on the day’s announcements.
More than a year has passed since the last official Flutter event. Flutter Engage is the latest annual progress update for the Flutter project, as well as a general marketing opportunity and community celebration. Historically, Flutter events have taken place in person, but due to the state of the world, this event took place online.
Every Flutter developer will take away different points from an event like this. These are the details that stuck out to me.
Flutter for web is stable
Arguably, the biggest announcement from Flutter Engage is that Flutter for web is now considered “stable”.
To me, this doesn’t change anything because I’ve been releasing small websites built with Flutter for the past year. But we all know that CTOs, directors, and engineering managers care a lot about stability declarations. So here’s to the executives! You are now free to participate in the UI revolution!
Ubuntu announced that the Ubuntu installer is now implemented with Flutter. I think this is a deceptively minor announcement. It’s a lot more significant than it may seem.
The Ubuntu installer is the first and most critical interaction that a user has with Ubuntu. If the installation process fails, you can’t use the OS. If the installation process is ugly and error prone, it sours you to the whole OS as a product. I take this announcement as a major bet by Ubuntu on the future and pleasure of working with Flutter.
But Ubuntu didn’t stop there. The Flutter SDK is available from the Ubuntu app store for quick and easy installation. Reducing the friction to get started with a toolkit is a great boon for adoption and Ubuntu is donating to that cause.
It also sounds like Flutter is on its way to becoming the default toolkit for building any and all Ubuntu apps.
I’m very happy to see Ubuntu’s engagement with Flutter. I think it’s a big deal, and I look forward to a burgeoning desktop development future, made possible by opening desktop to the likes of web and mobile developers.
Metaprogramming in Dart
Bob teased metaprogramming as an upcoming extension to the Dart language. I’m both intrigued and skeptical of this future.
Metaprogramming, AKA glorified code generation, is an extremely powerful tool. Most of us already use code generation to avoid hand-writing JSON serialization and deserialization behavior. There are many candidates for metaprogramming. Any repetitive part of your code that you think of as “boilerplate code” might be a use-case for metaprogramming.
Unfortunately, playing with the dark magic of metaprogramming strikes me as an opportunity for a medium-level improvement, or horrific destruction. I’m not sure it’s worth the risk.
I’ll avoid going too deep in my analysis right now, because we’re here to talk about all things Flutter Engage. Instead, I’ll leave you with two points. First, almost no one understands metaprogramming. Seriously. We’re still arguing about “state management” (see next section). Most Flutter developers will treat metaprogramming as black magic. Including me. Second, any capability that you introduce at the language level will be used and abused in nearly every app built with the language. App developers in general are grossly irresponsible with the tools they are given. If that offends you, I’m sorry, it’s an observation of reality. App developers will setup a Redux store to implement a counter app. If Flutter developers are given metaprogramming at the language level then every single app will find an excuse to use it, which means that every single developer will be forced to learn how to work with it, and that will be a tax to get started with any and all Flutter development. And did I mention that almost no one understands metaprogramming?
Let’s not forget that one of the most powerful properties of the Dart language is it’s simplicity. The cool stuff, the magic stuff, the complicated stuff is done by frameworks and packages built with the language, not the language itself. This property is important.
At a minimum, my advice to the Dart language team would be to find a way to stick this behavior in an opt-in package. I don’t know how they might accomplish such a thing, but making metaprogramming available out of the box is more likely to be a disaster than it is a savior.
Upcoming “best practices” template
In the live after show, Ian mentioned that a new project template is coming to Flutter in the next stable release. This template will introduce a default “best practices” architecture as a starting place for an app.
The community has long demanded guidance with regard to application architecture. I understand why the team feels the need to introduce such a template. I hope the template helps somebody build a better app.
My experience building mobile apps over the last decade suggests that this template, and similar attempts to help with application architecture, will only further deepen the development failures at hand. Let us not forget that the abomination that is BLoCs was inadvertently made popular by a Google I/O presentation that the Flutter team put together because the community said they needed help. That mild suggestion for how a Flutter app *might* implement information flow quickly metastasized into the “obvious, default, best practice, every-app-should-use, one-size-fits-all state management solution”. The fact that so many developers keep using the phrase “state management” indicates a deep rooted lack of fundamental software engineering knowledge. Taking a large group of developers who fundamentally lack the ability to model software and giving them something called a “best practices” template is an invitation for disaster. I hope this template accomplishes its goals, but history suggests that it will make the problem worse.
I’m sympathetic to the community’s needs. I’m sympathetic to the Flutter team’s desire to help the community. But, the Flutter team can’t teach the world how to model software. It’s a losing proposition.
Flutter continues to grow in adoption, features, and platforms. There weren’t any surprises for me in today’s event, but that’s probably a good thing. One man’s surprise is another man’s shock. I think I’d rather see a slow steady burn as the Flutter UI revolution continues.
As the Flutter team continues to fix bugs and implement features, I’ll do my best to help solve some of these educational issues around application architecture, and show the world the expressive power of Flutter. If you’d like to learn from me, please subscribe to my YouTube channel and follow me on Twitter.