Sorry, but here we’re going to rant a bit. Just a lil bit.
Developer’s Perspective
A few fairly minor, but fairly annoying things:
-
Mandatory semicolons, really? Java has a point for things that nowaday look obsolete: backward compatibility. What point does Dart have? And I don’t care how the end of line looks. I included that point when I actually started coding in Dart and got surprised how annoying that little thing appeared to be after I had been using Typescript, Kotlin and Swift for just about 1 year (as an equivalent for a full-time coder), even though it was along with using Java here and there.
-
Type variableName
instead ofvariableName… Type
This is sth that looks weird in modern times especially when declaring final properties. The 1st thing I care about as a developer is a property’s name and if it’s constant or not. So havinglet appVersion: AppVersion
is more readable to me if compared tofinal AppVersion appVersion
. -
Best practices: why would you invest into technology which is fresh to the community? What does “fresh” mean for the professional community?
-
Have you ever tried to run
git init
ornpm init
using a terminal? How hard could you imagine it is to init a new Flutter project? Don’t hesitate to consider me as dumb, but it took me ~25 min as a developer with 7+ years of experience. How does it feel? It feels annoying to say the least. This is a numbered list of my attempts with the Flutter’s output and my comments following##
:
1. $ flutter init
Could not find a command named "init". Run 'flutter -h' (or 'flutter <command> -h') for available flutter commands and options.
## why wouldn’t they just show me that `available flutter commands` list right away?
2. $ flutter new
Could not find a command named "new"
Run 'flutter -h' (or 'flutter <command> -h') for available flutter commands and options.
3. $ fl -h ## `fl` is my alias for flutter. Here I felt I needed to come up with something to type less while still hoping for someone to follow some standards...
Manage your Flutter app development...
…
## Here I saw the list of all available commands and found out there is a one named `create` – hm… that’s very creative.
4. $ fl create
No option specified for the output directory.
Create a new Flutter project.
If run on a project that already exists, this will repair the project, recreating any files that are missing.
Global options: ...
5. $ fl create --help
Create a new Flutter project... ## the same message as before that hasn’t brought me much of an idea of what to do.
6. $ fl create flutter-test
"flutter-test" is not a valid Dart package name.
See https://dart.dev/tools/pub/pubspec#name for more information.
## oh, god, I’m using this the 1st time ever for testing and should go through package naming conventions first? Can I please write some code to see if it can work at all or not first? Of course, it works, for thousands of developers, they say)) Though can I see if it works for me, just in case...
7. $ fl create flutterTest
"flutterTest" is not a valid Dart package name.
See https://dart.dev/tools/pub/pubspec#name for more information.
## no-comments
8. $ fl create flutter_test
Invalid project name: 'flutter_test' - this will conflict with Flutter package dependencies.
## ha-ha... Are you kidding? It’s the 1st time I’m using flutter and I’ve already come up with a conflict with the library dependencies naming...
9. $ fl create test_flutter
Creating project test_flutter...
## let’s go on and waste some more of my life on Dart – a version of Java without the `new` keyword
A fun fact: the number of attempts I needed to initialize an empty project corresponds to the answer to “should I be using Flutter?” in German.
-
How long did it take me to launch an Android build of the app that worked on some other developers’ machine (apparently)… well, about a week of reinstalling JDKs, adjusting JVMs versions, Gradle properties and all that crap… It’s not a crap actually, but for the sake of simplicity in this article I’m considering as crap everything that stops me for more than 10 minutes when I’m aiming to write and test code.
-
Surely, it’s just a coincidence, but this is how people’s faces look when they are exploring whatever Flutter is about to bring (that’s actually a photo from a dart workshop, but feel free not to take my word for that:)
Tech Maintenance Perspective
-
Less awareness or even an absence of the guidelines and use cases of how to organize the code. It took years for Google to realize it would be helpful to provide some guidance about apps’ architecture for Java Android developers need
-
Harder to find an experienced engineer. Engineers who are good at what they do for a long time and they love what they can achieve (otherwise they wouldn’t excel in what they do), why would they switch to another framework… which code looks like CSS to some extent?) So, most probably you’ll deal with a novice programmer who somehow got hooked by Google’s world-wide clinical trial.
-
A related point: code handover. You need not just to find one experienced engineer, you need to be more or less ok with handing over the project among different developers across time.
Of course, there can be reasons why to use Flutter. I want to offer nothing but support if you find a good one.
Thinking about Flutter, I remembered one of the technical talks I saw many years ago about adoption of new technologies. And the speaker was talking about TypeScript. The point was that it was nearly zero cost in terms of source code modifications to try it out: set up some TS transpiler and rename your existing .js
files to .ts
files. And they still would compile. And that’s an example of a great go-to market strategy, when it comes to programming tools.