I’ve been tinkering with Flutter.io for a few days now and wanted to document a few early impressions.

It uses the programming language Dart. I’d looked at a lot of Dart code when it was first announced, but hadn’t looked at it much since. I couldn’t see it gaining meaningful traction against the JavaScript juggernaut as a transpiled option (as it added too much overhead from the complaints I’d read) and there was zero evidence that any company besides Google was considering integrating it as a native option for Web pages. Without broad industry cross-browser support (from desktop to mobile as well), it seemed like a dead-end option that didn’t add measurable value. In some ways it was doomed to fail as it was trying to be a better JavaScript rather than rethinking the whole client development experience. It was just a new web programming language.

Originally, Dart’s messaging was broad and suggested that it was an ideal language for everywhere. That has changed since it’s original announcements to be focused on client development. But, that shift was recent and apparently connected with the announcement of Flutter.

From November 1, 2011:

 

to late February 2018:

Even as recent as May 2017, the Dart team was still considering server development as a potential platform target:

It seems logical that the team would pivot to concentrate on a single target platform type, the “client.” Dart hadn’t gained substantial traction in server development or client development. While a recent video I’d watched suggested there were 70 million lines of Dart code on Github, I’m not sure who’s writing all that code and why. The dart-lang repository hosted on GitHub hasn’t seen a lot of “Star” love.

Compare those numbers to TypeScript for example:
Nearly 30,000 more stars (and TypeScript was announced about a year after Dart).

I wouldn’t choose Dart for new development outside of Flutter. My initial impression is disappointment that the Flutter team is using Dart as it adds one more language to the client-side development smörgåsbord. I don’t know that the world needs another programming/UI toolkit lock-in option right now added to the buffet. I like variety and competition, so I’m all for that, but I also worry that limited adoption of frameworks leads to abandonment and frustrated developers. I can speculate why they choose Dart, especially as it’s staffed by Google developers, and I can see the appeal of the language, but….

I don’t need more programming languages right now in my solutions toolbox. It’s one more thing to learn and master. Since Flutter is also new, it has made the initial ramp-up time longer than I’d expected and wanted.  And because the language syntax is very familiar by design, it’s unfortunately likely that habits from other C-like and TypeScript-like will find their way into coding I do in Dart.

While the community at large apparently considers the Widget building syntax to be a strength of Flutter, I can’t say that I’m excited about it. It’s chatty and verbose. (And I haven’t been able to tell if the enthusiasm about the current syntax is just from the early adopters or fans, or it’s generally well liked). It absolutely doesn’t feel like it’s moving the needle when compared to all of the other GUI frameworks that have come before it. In fact, it reminds me of my earliest coding experiences using Turbo Vision. Yeah. Turbo Vision from Borland. (Wow — the past 20 years of IDEs and development tools originally from Borland has undergone an amazing number of ownership changes).

(Yes, it’s not really like that too much, but I had some flashbacks to my Turbo Pascal days).

Here’s a snippet of some code, written in Dart which represents a single item (more about this in a later post), with a thumbnail, a name, and a year published.

Of course, alternatives have been proposed, like a JSX-like syntax. This proposal brought out the best and worst of engineers of course. A few of the collaborators on Flutter were so dismissive of the idea I nearly stopped looking at Flutter.  As Flutter is in its early days, and backed by Google, I expect ideas are rationally considered and individuals to be treated with respect, even if there is disagreement. I’ve done years of WPF, Silverlight, and UWP development which used XAML. While there continue to be some rough spots in XAML, I appreciated the structured document for building a UI. I don’t know that I’d go in that direction for Flutter, but I don’t think describing complex user interfaces entirely in code is the best for its future viability, especially as it needs to compete with a variety of other frameworks and options.

Ignoring the syntax of how to describe a UI though for a moment, I’m still having trouble with wrapping my head around the idea that State actually renders a UI:

It’s the build method that returns the object hierarchy that describes the widget tree, not the class that subclasses StatefulWidget.  If you instead use a StatelessWidget, it builds its Widget hierarchy directly within the class. I can see how they arrived at this implementation, but it just feels inconsistent.

I like the async/await support in Dart. I do wish that I wouldn’t need to specifically declare the return type as Future<T>. The code has already signaled that it’s async, so if Future<T> could just be T, some code clutter would be eliminated.

The the code above, it’s great that the return value is automatically wrapped in a Future without any special code, but taking it a bit further would make Dart and Flutter more appealing.

I’ve been using TypeScript long enough that let and const functionality is second-nature. Unfortunately, Dart’s language is subtly different and I end up trying to use const where I meant to use final. That’s my problem of course, but it’s just a gotcha. Const in Dart is for compile-time constants.

I’ve been generally pleased with using Android Studio with the Flutter plugin. It performs reasonably well, and it’s a good editor with lots of bells and whistles. The build/debug times are quite long, even for a basic app. It’s about 25-30 seconds for a build and deploy to an emulator. Thankfully, the plugin and Flutter both support hot reloading, so many changes to the code can be updated without needing to do a new build/deploy. While that’s very helpful, I’d like to see a significantly reduced build and deploy time.

In a market saturated with options for building cross-platform application UIs, it’s not clear how Flutter fits in. I’ve liked the experience enough that I’m going to build out a few simple apps and will show off more details in a later post of an app I’ve been tinkering with as I learn the platform and development environment. Flutter is in an “alpha” state right now, so a lot could change before it’s available in a final release (if it ever is). According to their Github repository, they have currently 86 issues open for their “beta” milestone. There’s no meaningful date associated with the transition though.