Topics like this one may seem trivial, but frankly after using Flutter for over 4 years it’s easy to forget why this tool makes me so satisfied. Thus, I decided to document some of the most spoiling things about Flutter. Maybe next time I’ll write about problems I can’t stand 😉
This is the obvious one, but every time I have to use a compiled language without this kind of instant feedback loop, I really wish instant code reload would become a new norm in any language. Recently, I gave dart_frog a try and the ability to instantly reload the implementation of the server code felt like magic.
Flutter and Dart are open source projects. It means you can browse and inspire from the freely accessible library of almost infinite knowledge. The IDE’s ability to access the code by just inspecting it is a cherry on top.
Naturally, the open source SDK code written by over a 1000 contributors is not going to be the same as client-facing production app code. You’re not going to copy and paste the framework code and built the app out of that. However, anytime you need to figure out how to write an atypical test, build a new library of widgets, or design new API used by thousands of users the Flutter ecosystem and codebase are places to go.
The open source attitude affects not only the framework code. As a developer I clearly see how it affects the community and newcomers to share all the things they build and learn every day.
Since the very beginning of my work as developer I always wanted to build for every device. I started with things like ASP.NET, Xamarin, Android, Ionic, or WPF. And they were really amazing tools. However, it was the Flutter that actually allowed me to not feel limited by the tech stack I use.
There are definitely things that will be astronomically difficult to build with Flutter, especially on web or if the SDK does not support it yet. The recent discussion on Twitter about Flutter Web sums it up nicely. And many of you already know my personal hesitation about this use case. However, it’s all the other platforms that make me enthusiastic about the future of Flutter.
Work done by Canonical with their Desktop Installer, Sonos with the setup sequence, foldable support by Microsoft’s Andrei Diaconu, Raspberry PI support and e-ink POC by Simon Lightfoot. The list could go on and on.
To make it even better, the bulk of my day to day development work for mobile I can do by running a lightweight desktop app. If I need to build a simple utility app to use on macOS, most of the APIs is there and I can just reuse my mobile dev skills. If I need to dig deeper, there’s another groundbreaking thing about Flutter:
Announcing my newsletter
To make it easier to never miss a new blog post, I decided to start a simple newsletter. It's called Occasional Flutter and I invite you to subscribe today!
Unobstructed access to the underlying platform
This may not be super obvious but the more you build apps that need some platform-specific functionality, the more you appreciate modular design of a Flutter project. Each platform is just another wrapper that can be freely configured as if it were a standard macOS/Windows/Android/iOS/Linux… app.
There are of course some specific setup steps (e.g. in Xcode build phases) that are required to run it as a Flutter app, but for the most part you can do whatever you need with your native project. This is extremely convenient compared to e.g. Xamarin where (I guess) at the cost of being able to use native APIs in C#, they had to hide/bundle the native project inside of the Xamarin app.
Having access to a native project means that you can utilize your other skills and resources to help you with release, customization or building more features.
Especially the federated plugin architecture makes multi and cross-platform cooperation easier. In a bigger team you may find groups of experts in their own areas that alone would have a hard time building solutions in the opposite ecosystem. Imagine implementing a camera app on Android as iOS developer. With Flutter you can split the efforts with a thin layer of common “consumer-friendly” API and have the best of all worlds.
This list is definitely not complete. There are more features like thriving community of tutors and learners, high quality open source libraries (just to mention flutter_bloc and riverpod), Discord server where Flutter maintainers work in the open, and many more. However, as in every technology there are also some pain points. We’ll try to discuss them next time 😉
Subscribe to my newsletter to never miss a new post