Testing Flutter wasn’t an easy decision to make given that Kotlin Multiplatform has been growing fast and making tons of noise over the last six months. I was trapped in a Remix vs Next, Django vs Spring or avocado vs peanut toast. As usual, the solution is to test everything out. What follows are my initial impressions on the framework and the language.
Setup
Setting everything up took less than half an hour following the official Flutter documentation. This included downloading the flutter SDK, adding it to my $PATH, installing the official VS Code extension, starting a project and launching it on an Android Virtual Device. Developers with experience messing around with Node versions, Python virtual environments or Java SDKs will find this a breeze.
IDE support
The VS Code signed extension is excellent. It allows launching the app you are developing in any target platform with debug mode turned on or off. It also features a complete debugger, a tree view where you can see your app widgets (components), and more. The best is that it-just-works™: the only manual steps were to help indicate where the flutter SDK was stored. Although you will find yourself using it for refactoring code most of the time, as it features great code replacement and manipulation tools that make containerising components very easy.
People who prefer being independent of an extension for the entirety of their workflow can always rely on the flutter command line, which is just one step lower than the extension itself.
Coming from a Typescript project, the maturity of the extension can be felt instantly. It behaves as a sort of Swiss army knife, featuring everything you might need instead of leaving gaps to be supplied by community extensions.
Dart is Flutter
Dart is a free and open-source programming language tailored for multiplatform application development. It has a syntax similar to Java with the lightness of Typescript but lacks the amenities of Kotlin. Engineers with experience in the previously mentioned languages will not feel much of a difference when developing Dart, and for those utterly new to the syntax, its learning curve is very low, and it has well-maintained documentation.
The problem with Dart is that it was unsuccessfully pushed by Google to be the following JavaScript. The WWW is full of articles titled <Why does Flutter use Dart instead of Kotlin|Java|TypeScript?>. No one is very excited about the language - except for Google. This is disappointing, as the rise in Kotlin Multiplatform could have been replaced by implementing Flutter with Kotlin.
Widgets
Everything is a widget in Flutter. For those coming from a web development background, think of a Widget as a Component that receives props and can have its own state. This is great and makes things simpler. However, things get deeply nested really fast, and I found myself using the “extract into widget” IDE function several times, even for a small application. Prototyping in Flutter is fast, but I find maintaining these prototypes hard if some planning has not been done beforehand.
The elephant in the room. Thinking of Killed by Google when exploring this framework is unavoidable. Google’s support is everywhere, from the SDK to the docs, IDE extensions, or Dart. If Google decides to pull the plug on any of those areas, the whole castle would crumble. Kotlin Multiplatform might surpass Flutter pretty fast - at least in business applications - if it manages to offer the same experience Flutter provides.