Flutter: A Java Engineer’s Journey into Flutter

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. 

At first glance, a Java engineer might simply resign themselves to operating on the server-side backend of some fancier-looking, JavaScript-laden React Native frontend. Looking around, it’s easy to see tech stacks which still respect and understand Java’s potency on the backend but use the power of the stack to write a frontend using different technologies and frameworks. Or, as has been the case over the last few years, many companies replace Java with a backend language more suited to a specific need.  Over the course of my engineering career, I’ve dabbled with various frontend languages and frameworks, from React to Django, and each endeavor has been harried by the disagreement between the strictly-typed, object-oriented practices I’ve learned from Java and the notably less set-in-stone typing present in JavaScript. 

Averse to the complexities of JavaScript and its peers, and yet aware of the ways those languages have become best practice for most professional apps and websites, I was in search of a solution. Flutter has turned out to be the best mix of both worlds, having the flexibility to incorporate dynamic typing but still include strict classes, and building upon the Dart language which, with a little squinting of the eyes, reads like Java code. When jumping into a project which uses similar frameworks like React, I often found myself taking up to two weeks to get acclimated, floundering when following the flow of information from form to model and getting lost among echelons of nested packages, incongruities in Node Package Manager, and the house of cards these frameworks can build after a month of being iterated upon. For Flutter, it took me a week before I added vertical slices of implementation to the application. 

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. 

Connect with us to learn more!