Not too long ago, I had a healthy conversation with a member of our Android team about Flutter. We both arrived at the same conclusion: Flutter is made exceptional by its simple yet ambitious goal of allowing front-end engineers to build multiplatform applications that run everywhere. From different vantage points, we agreed that the scope of front-end extends beyond the web because we are all building user experiences.

I have been an engineer for about 10 years, primarily specializing in front-end web development. I have witnessed the rise and fall of a plethora of technologies on both the backend and the front-end, ranging from Java to C# to Node.js and jQuery to Angular to React. These transitions were not whimsical, they stemmed from the need to make better tools that would enable developers to write better software. Phrased another way...

Software has already made the world so much better, but it’s still insignificant to the problems that we could be solving if software was better. Since programmers are the ones that write software, it is on us to become better, and every day we don’t, humanity is worse off. -- Mattias Petter Johansson

If you do not agree with this sentiment, then you may be wasting your time with this article. Regardless, let's explore why we need tools like Flutter to help us build better software.

It's about reachability and rich experiences

Build web apps to reach everyone and native apps for rich experiences. This rule has been set in stone basically since the inception of mobile applications, and maybe even further back to desktop applications. Mileage varies greatly when you try to cross these boundaries from the safety of your sandbox.

Flutter is built with these two polarizing requirements in mind - what if you could reach users everywhere and provide them with rich experiences?

Flutter's target is not Android and iOS - it's wherever your users exist. As it stands today, there are open source targets for mobile, web , and multiple for desktop application development. As software engineers, we strive to pick the right tool for the job. Building multiplatform applications is the goal etched into Flutter's design and that cannot be understated.

It's about the users

One day I see an awesome application that I believe would improve my life. I get excited about using the application but discover that my platform isn't supported. Now I am at the mercy of fate. Maybe the company has decided that they'll never release to another platform because it's not feasible. Maybe they will release it one day in the future. Maybe they promise to release it one day in the future. You have probably heard or experienced this story before.

As developers, we choose tools because they make us effective. The more effective we are, the better we are at building applications that make a positive impact on our user's lives. Remember the quote at the beginning of this article. If you agree with that quote, then every user engineers fail to reach is a person whose life they've failed to positively impact.

Taking this a step further, we are not just developers but rather we are users ourselves. What resonates listening to interviews of Flutter team members is that they actually build things w/ Flutter. They aren't too far removed from app dev to empathize - entire apps are built in Flutter just for demonstration purposes. In the same way that being a user of my own apps will help me build better apps, being users of their own tools will help them build better tools.

Platforms are an implementation detail

The very first application that I built was a Java Swing application. My process for building it was to determine the scope of the application and the user experience and implement it.

The second application that I built was a web application. My process for building it was to determine the scope of the application and the user experience and implement it.

While the tooling that I used and even the code that I wrote varied greatly, the basic essence of my development process did not. I am not trying to downplay the amount of work that goes into building applications. On the contrary, I am looking at the breadth of knowledge that front-end engineers need to reach users where they are. It is overwhelming.

I occasionally have a good idea for an application and I build that application. Sometimes I yearn to build that application for another platform to reach more people who may share my enthusiasm. Needing to rebuild the application using an entirely new toolset is a barrier. An understandable barrier, considering the differences between every platform's ecosystem, but a barrier nonetheless.

I firmly believe that other platforms should be an implementation detail. Implementation should not cost so much that it discourages us from accomplishing our tasks or reaching people, but it does. And it will continue to so long as the status quo remains. We deserve a better solution, and Flutter has made this burden its own.

It's about the community

I was fortunate to attend Google I/O this year and speak to some of the developers behind Flutter & Dart. The paraphrased question that I asked frequently was "How does Flutter shine and stand out in this crowd." I know enough about Flash to know that it was a fun environment to build apps in - it's dead. I wrote enough Silverlight to know that it too allowed you to build very rich applications - also dead.

The overwhelming answer given was it's about the community. I believe that what separates JavaScript and similar ecosystems that have survived for decades is the community surrounding them. Flutter has a burgeoning community. Its core teams treat the open source community with the same level of respect as their own members. If a developer wants to have an impact on the direction of Flutter or the Dart language, he is only limited by the time that he can devote contributing to each project.

Conclusion

Flutter started as an experiment to see what Chrome would look like as a development ecosystem without the technical debt accumulated over the years. It was carefully constructed based on the past learnings of several minds that spent the better parts of their careers contributing to the web platform. These engineers are passionate about both the tools and the community that they are building.

Flutter's goal is to be the best way to build experiences. Dart's goal is to be the best language for building experiences. Even if both fall short of those lofty goals, they are pushing us forward.

In the end, front-end engineers are creators. The technology we choose limiting who we reach is a problem worth solving. Flutter is trying to solve that problem. To build better software we should be pulling for Flutter and tools like it to succeed.