msfjarvis
/
msfjarvis.dev
mirror of https://github.com/msfjarvis/msfjarvis.dev.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Finish first version of Flutter post [staging] 

Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>
This commit is contained in:
Harsh Shandilya 2021-03-07 21:53:38 +05:30
parent 9c5a74dad2
commit 1a45d55395
2 changed files with 48 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
content/posts/my-flutter-experience.md Normal file
View File

@ -0,0 +1,48 @@
+++
categories = ["dart", "flutter", "android"]
date = 2021-02-25
description = "I've had the chance to explore Flutter (and Dart) at work for the past few weeks and I have opinions :tm:"
draft = true
slug = "my-flutter-experience"
tags = ["androiddev", "dart", "flutter", "kotlin"]
title = "My Flutter experience as an Android developer"
+++
## Hot reload is great! (when it works)
Not much to say there, it really is great! The lack of IDE support for previewing your UIs is more than made up by being able to press one key and see it on your device instead. The catch: it requires you to use a debug build which usually means janky performance, and sometimes borderline unusable levels of UI sluggishness depending on how many widgets you have on your screen. I've also noticed that subsequent hot reloads seem to exacerbate the UI slowness to the point where 4-5 hot reloads in you will need to restart your app to have things move on the screen again.
However, I can say for a fact that being able to press 'r' on the keyboard and being immediately guaranteed that the code you wrote is what generated the UI you're seeing is great. No more "okay I'll do a clean rebuild and see if my changes show up" which, while a **lot** less frequent now, continues to be a thing in Android.
## Widgets are easy to build and extend
The core and material libraries included in Flutter are great for building design systems at a rapid pace, and theming has been very easy in my experience compared to Android's XML-based approach and the often confusing distinctions between _themes_ and _styles_. The explicit distinction between stateful and stateless widgets can feel welcome to some, but after having used [Jetpack Compose] for a few months, I feel that Flutter could be doing more to handle this by itself.
## Dart is...eh
:warning: Hot take alert :warning:
Dart as a language still feels like it hasn't escaped its JavaScript roots. It has a lot of _implicit_ features that are not always desirable, such as [implicit interfaces] and most notably: [dynamic failsafe for type inference]. One could argue that rather than filling in with `dynamic`, the system should report that type inference failed and ask for the user to annotate the type themselves. The language also does not support [sum types], which makes modeling some situations harder than it needs to be. There are community developed libraries to fill in some of these gaps ([sum_types]), but they often involve codegen, which is another pain-point.
## Flutter tooling is (for the most part) great
I'll say this upfront: having the `flutter` CLI is amazing. It encapsulates a lot of functionality that is usually all over the place and puts them into a easily accessible interface. I absolutely love it.
That being said, there are some gripes I have with one specific tooling aspect: codegen. Coming from the JVM ecosystem, I have a certain degree of expectations about code generation. It should be transparent in that I should not have to explicitly run it, and the generated code must not be a part of my source tree. Flutter does both in ways that feel _wrong_ to me. Again, my distaste stems from what I've experienced in the JVM ecosystem.
To run codegen tasks in Flutter you need to call into a package called `build_runner` that performs the actual codegen. This amounts to the `flutter pub run build_runner build` command in the terminal. I have not found any support for doing this from the IDE in either of the first party plugins offered for Visual Studio Code and IntelliJ IDEA respectively. Once this is done, you'll find that your source tree is now littered with `*.g.dart` files. Now you have the decision to make of whether or not to check them into version control. The official [`build_runner` docs] recommend that you **don't** do it for applications, **do** it for published libraries, and check the specific code generators you're using on what their authors recommend you do. Much more involved than the JVM answer of "no".
Switching between Flutter versions is also an experience, to say the least. `flutter upgrade` works great, but when you attempt to rollback you'll find options lacking. Why would you want to rollback? Well, [Flutter 2.0] brings significant changes both to Flutter itself and the underlying Dart language, which means that all dependencies need to be updated as well. There are ways to disable new features like sound nullsafety to allow for the upgrade to happen without waiting for dependencies, but since null safety has been such a pain point personally, I want to be able to leverage it fully when I upgrade. For rolling back, your option is to either just delete and redownload the version you want, or in a slightly easier way, open a terminal in `$FLUTTER_DIR` and check `git reflog` for the previous state and `git reset --hard` to it. Flutter does insist on redownloading the Dart SDK each time you move between versions which I find extremely wasteful and avoidable, but that's how it is for now.
## Closing notes.
While this has been a rant-esque post, I do find Flutter to be a generally pleasant way to build cross-platform apps. With the web target reaching stable in [Flutter 2.0], it is now an even more lucrative option for new projects to become available on multiple platforms with a single team. As an Android developer, I will still be leaning towards [Jetpack Compose] for Android-only projects. Maybe the reasons for that can form another blogpost in the future :)
[Pause]: https://getpause.com
[Jetpack Compose]: https://d.android.com/jetpack/compose
[Implicit interfaces]: https://dart.dev/guides/language/language-tour#implicit-interfaces
[Dynamic failsafe for type inference]: https://dart.dev/guides/language/effective-dart/design#type-inference
[Sum types]: https://chadaustin.me/2015/07/sum-types/
[sum_types]: https://pub.dev/packages/sum_types
[`build_runner` docs]: https://pub.dev/packages/build_runner#source-control
[Flutter 2.0]: https://medium.com/flutter/whats-new-in-flutter-2-0-fe8e95ecc65

29
content/posts/my-gripes-with-dart-and-flutter.md
View File

@ -1,29 +0,0 @@
+++
categories = ["dart", "flutter", "android"]
date = 2021-02-25
description = "I've had the chance to explore Flutter (and Dart) at work for the past few weeks and I have opinions :tm:"
draft = true
slug = "my-gripes-with-dart-and-flutter"
tags = ["androiddev", "dart", "flutter", "kotlin"]
title = "My gripes with Dart and Flutter"
+++
Before you tear into me on Hacker News and this comments section, I'm going to go ahead and enlist my biases from before I approached Flutter.
- I am an Android developer with Java and Kotlin proficiency, and my first foray into declarative UI was [Jetpack Compose]
- I have used and disliked JavaScript in the past, and am aware that Google intended to ship the Dart VM in Chrome back in 2015 as a JS competiter
- I am a huge fan of strongly typed languages, especially ones with powerful type systems like TypeScript and Rust, both of which I use and enjoy using.
With that out of the way, let's dive in.
## Hot reload is great! (when it works)
Not much to say there, it really is great! The lack of IDE support for previewing your UIs is more than made up by being able to press one key and see it on your device within seconds. The catch: it requires you to use a debug build which have janky performance, and sometimes borderline unusable levels of UI sluggishness depending on how many widgets you have on your screen. Also, subsequent hot reloads seem to exexacerbate the performance woes to the point where 4-5 hot reloads in you will need to restart your app to have things move on the screen again.
However, I can say for a fact that being able to press 'r' on the keyboard and being immediately guaranteed that the code you wrote is what generated the UI you're seeing is great. No more "okay I'll do a clean rebuild and see if my changes show up" which, while a **lot** less frequent now, continues to be a thing in Android.
## TL;DR
Flutter is a generally pleasant way to build cross-platform apps, but Dart and the some of the tooling around the language feel like they hold Flutter back. Again, I'm a biased commentator because of my JVM/Android experiences so it is entirely possible I'm just deluded. I'll let you be the judge of it :)
[Jetpack Compose]: https://d.android.com/jetpack/compose