As a Java engineer looking into developing a mobile device, I know where the difficulty curve typically lies. For Java developers, only Android Studio-based apps allow for Java’s continued use, and the steep slopes of learning how to use React Native can keep many creative workers from being able to display their engineering acumen. Faced with the rock and the hard place, a Java engineer needs to turn to some alternative solution- there must be a better way to build a mobile app, and it’s with Flutter.
Because of its mostly platform-agnostic structure, Flutter has the ability not only to resemble Java code but also to extend far further than the best of the more basic Android frameworks. Just search for the best Android app development frameworks on your favorite search engine, and you’ll find Flutter on any list written in 2023, usually at the top. The idea that once the app is finished for iOS, it’s also finished for Android, is a pretty novel one to many developers, myself included, and my Flutter experience has lent some truth to that notion.
Before working on this Flutter project, I worried that another framework in another language would be another set of speed bumps turned hurdles turned brick walls between my skill set and the process required for efficient development. With a remarkably small three months of experience in the language, I’ve become skilled (and confident) enough to start putting out the type of work I took a year to learn in Java and can develop many times more efficiently than I could with React. Some of this comes from knowing the project, but I’ve spent months on React projects before without gaining this level of understanding- that we are using Flutter has made a noticeable difference. I might not be a ten-year professional developer, but I’ve learned how to code in a dozen languages throughout my academic and professional career. Flutter is leaps and bounds easier to learn than even some of my favorite languages, like C++, and it has applications much more broadly than the types of college homework assignments on which I could flex my C++ knowledge, anyway.
Even though my story is a pretty specific one- I’m not even sure most newer professionals were raised on Java anymore- I think that there’s still merit to pursuing a project in Flutter when making a framework-level decision, or at least considering it a viable option. Though it’s easy for Java engineers to pick up, that doesn’t mean it performs like a Java-based app. I think of it more as a trimming-down of React-style frameworks than a sprouting-out from Java-style ones. In other words, if something in React Native was so deliberately open-ended because of a handful of self-maintained packages which leverage some sort of specific idiosyncrasy, that same thing in Flutter is done the way Google wants it to be done and allows only for the options that are acceptable therein. This may sound like a damper on coding creativity, but as a Java developer at heart, this makes the development process look less like modern art and more like puzzle-solving, a much less daunting task.
For me, my love of coding started while learning Java, and accomplishing tasks which felt like puzzle-solving. It’s true that the actual day-to-day work of building an app, wiring up a backend, or putting together a website isn’t the same as puzzle-solving, but Flutter’s design helps constrain the massive breadth of possibilities to a mere handful of optimal choices for execution. There’s no deliberating between the 6 or 7 packages which have implemented form text entries, or which set of icons works best. Instead, there are only a couple of reasonable packages to do the job, and using Google’s Material UI is the easiest choice by far within Flutter. This takes out some of the decision fatigue that can be so heavily associated with many of the newer, incredibly versatile frameworks, and though that certainly also comes with its own costs, the decisiveness and clarity make up for the lower quantity of options.
It’s not just for ease of use, either- the singleness of Flutter’s implementation options also helps it in other ways. That there are only a few options for app design means that a project’s Android version, iOS version, Mac, Windows, and html versions are all built from similar beginnings. On more than one occasion I’ve noticed that a certain package doesn’t work with my version of Node Package Manager, or that it’s not supported on Android or Mac, and that problem reared its head far less often during Flutter development.