undefined | Better HN

0 pointsbschwindHN7y ago0 comments

I've been starting work with Flutter over the past couple weeks. The tooling and general experience so far has been pretty nice, though it doesn't always "just work". The fact that flutter is so coupled to Cocoapods is a disappointment and it means your build system is dependent on Cocoapods not screwing up - quite a tall order. I already ran into an issue that required me to generate a new project, copy my source over to get a working app again, then inspect the source trees to see what went wrong. It turned out to be a Cocoapod symlink issue or something to that effect. Not entirely a Flutter issue but something to be wary of.

Some good points of Flutter so far:

* Hot reloading is fast, much easier to iterate on designs and experiments

* Plugins seem to be easy to make, they made an architecture that focuses on minimal boilerplate

* Being able to use async-await syntax on a whole UI view is a cool idea (like Android's onActivityResult() with much less typing involved). Push a view onto the navigation stack, let it collect input from the user, pop off the stack with a data structure representing the user input)

* Animations are easy

* Minimal opening of Xcode. Most days I can get by without ever opening it.

* Data flow architectures like the Elm Architecture or Redux are well supported

Some not-so-good points:

* Having null

* Material design is pushed way too hard - Cupertino widget documentation/examples are lacking

* Code generation needed for JSON parsing

* State for StatefulWidgets are generic over the Widget and not the other way around - I would have expected a StatefulWidget to be generic over a State e.g. `MyHomePage extends StatefulWidget<MyHomePageState>`

* Because of the previous point, the UI building function, build(), is usually on the State class and not the Widget class

* My relatively barebones app is around 33MB on iOS

Overall though I like it! Lots of good ideas and tooling. I one day want to create something with a similar architecture using a language like Rust instead of Dart, and native UI components instead of reimplementing the entirety of Android and iOS component behavior.

0 comments

roughike7y ago

I don't really agree about pushing hard on Material Design. Sure, the current widget situation might be skewed towards Material components and Cupertino is lacking. For Material widgets, they've implemented almost everything, even the most obscure ones. But I think they're pushing more for customized UIs. Meaning, UIs that don't look Material or Cupertino, but are more of a branded experience, think Spotify, Tinder, Snapchat, etc. Designs that don't really conform to Material or iOS design languages. The Hamilton app is a good example of this. Sadly, I'm not a UI designer so I went with Material Design on this inKino app since that's an easy route for me.

With your other points, I generally agree. Didn't mean to imply that it "just works" 100% of the time. But compared to other cross-platform dev tools / SDKs I've used, I feel like Flutter does such a great job in the tooling department.

AgentME7y ago

>* Having null

I must have been spoiled by Flow, Typescript, Kotlin, and Rust, because this (having null implicitly be a member of every type rather than a separate type) has been the major factor in my decision to avoid playing with Dart yet. It's so nice to not have to often manually re-check functions I'm editing to see whether or not each of the parameters are supposed to handle null, and to not have to document that in comments (the same way you usually end up documenting types in a dynamically typed language; this is what I'm using a typed language to get away from!).

j / k navigate · click thread line to collapse