Flutter - the new kid on the mobile development block

Wondering when Google will dump java and bye bye Kotlin :slight_smile:

1 Like

Probably not in a few years is my guess :slight_smile:

There have been some recent podcasts on flutter:

From the Fragmented Podcast
118: Flutter and cross platform development with GDE Eugenio Marletti – Part 1
119: Flutter with GDE Eugenio Marletti – Part 2

From Software Engineering Daily
Flutter with Eric Seidel
Flutter in Practice with Randal Schwartz

2 Likes

But Dart can be used for the front end too, and there’s always the option of using it for iOS (with Flutter) in case things with Swift don’t work out - that was my reasoning anyway :slight_smile:

2 Likes

FYI:

Flutter in Action MEAP

The code also works on Progressive Web Apps.

1 Like

:wave:
I’ve been away from the forum for a while so I missed this and it’s one of my favorite topics. I’m gonna mention a couple of points I didn’t see highlighted here so far that I think really speak for Flutter:

  • It’s not just compiled. Dart also runs in a VM with hot code reloading which gives you very fast development cycles in dev (web dev like) instead of the usual compile fest that native development is. Production compilation is for releases.
  • The same app runs on Android and iOS. It’s not like ReactNative where you basically write the UI twice (or do incredibly complicated dances not to do this) reusing some logic. We can discuss the problems that “iOS users don’t want an Android UI” so that you’d have to write it twice either way but I call it a great improvement nonetheless
  • At the same time the elements and performance are native-like. How do they do this while the same app runs on iOS and Android? They have a renderer written in C++ (iirc) that goes against the system bindings and hence take over at a much lower level and they don’t use web views etc. which leads to a truly native feel. At least to the Android dev I trust (he says he can notice if something is ReactNative and with Flutter he can’t see it).

Moreover, I really like how much thought and design went into Flutter. I really liked this video showcasing the different ways to work with state/redrawing which is a common and typically tough UI programming problem:

When they say “you can also use redux” - be aware, the redux library isn’t really integrated into all of flutter so you gotta expect to write your own solutions or glue code for common problems (Routing being one).


I still feel as if Dart will be holding back Flutter and it’ll be a make or break point. I don’t particularly like the language. For context, it was first unveiled in 2011 where lots of people were excited about it but once unveiled mostly everybody was like “mehhh” go away. If you want to have a fun trip down memory lane I still vividly remember dhh’s tweets from that day the most memorable for me being this one.
Mostly because nothing new and looked a lot like Java. Plus people where unhappy about google wanting to run it natively Chrome - they eventually gave up on that favoring the to JavaScript compilation.

Dart was also first optionally typed versus now statically typed. It is worth noting that one of the design goals (despite being easy to compile) was to not differ too much from JavaScript/Java so that it’d be easy to pick up :man_shrugging:

It’s also worth noting that Dart sports quite strong influences from Smalltalk. One of the core designers is/was Gilad Bracha who despite Smalltalk also worked on an interesting programming language called Newspeak.

Another notable among the language creators is Lars Bak whom I mainly know as a great virtual machine expert.

He gave one of the most interesting talks I ever saw at my old university: https://www.tele-task.de/lecture/video/3178/

IIRC it was the first time I saw a VM implementor say that they don’t need types to make a language fast.

So while I’m not a fan of Dart the language so far I trust the people behind it is what I’m saying.


Sorry for not providing many sources, if necessary I can look them up - this was mostly my brain dump from looking into Flutter/Dart ~May when we were evaluating it.

Oh btw. release preview 2 is out and is supposed to be the last major mile stone before 1.0.

7 Likes

After playing a bit, Flutter is to me, the only thing Dart’s offers better than JavaScript’s stack for mobile development.

Dart type system = TypeScript, Flow
AngularDart < Angular
Dart’s ecosystem < JavaScript’s ecosystem
Dart’s community < JavaScript’s community
Flutter > React Native, NativeScript, Cordova

If you’re not focused on mobile apps, I don’t see any reason to learn Dart. Instead of trying to replace JavaScript, we need to accept that it has taken the world of web development. At the end of the day, Dart is just another way to write JavaScript with its own pros and cons.

1 Like

Oh I think that Dart’s bid to replace JS has rightfully failed. But Flutter (as you also mention) seems to be vastly superior to React Native at least from the technology.

A question I’m debating myself a bit these days is what to do if you write an app for both the web and mobile app: all JS? All dart? JS on the web, Flutter for the mobile app part?

The latter is what I’m thinking atm and in an actual project it’d be interesting to see if sharing core services (API access etc) through dart2js would be worth the trouble.

1 Like

I think in that case Dart is the best choice I guess, because you can reuse a lot of your code like you mention, and Google is the best creating dead-simple languages and a great developer experience. But in my case, I’ve spent like 5 years with JavaScript, and I don’t want to change my stack because of “the new hottest thing”. Also, I’m not on the same boat as mobile app developers. To me, using React Native, NativeScript or PWAs is good enough.

But it really depends on your goals, what’s the point of learning Dart / Flutter? getting a job? Then you must wait until not only other developers, but enterprises knows about Flutter and realizes that it’s viable to rewrite its applications (here in Spain is like, what’s Flutter? a movie?). My conclusion is that adopting a new technology also comes with big costs for developers, and in some cases it’s not worth it.

Another thing is that I don’t like how Google manages its open source projects (like Angular and its breaking changes every six months for free, yay!), but being honest, they always create good stuff for developers.

1 Like

Yeah I think Dart sounds like the rational solution. However, I’m not sure how easy the JS integration really is (I’d have to look into that). I.e. I don’t wanna build things with angular, and last time the Dart <–> React integration didn’t exactly seem trustworthy.

For me the point would be a side project, so the main goal is whatever is best for the project. However, I sadly haven’t worked with ES6 a whole bunch and getting more experience with that again would be nice as well. And again, question is how Dart works with something like gatsby. I don’t doubt one can make it work, the question is more how much time is spent making it work.

Interesting decisions all around :slight_smile:

1 Like

I thought this was interesting: https://feather-apps.com/

Also: https://github.com/google/flutter-desktop-embedding

Running flutter mobile apps on desktop

3 Likes

That’s super interesting and confusing as I remember they explicitly said they wouldn’t do it, the caveats showcase that though:

  • This is not an officially supported Google product.
  • This is an exploratory effort, and is not part of the Flutter project. See the Flutter FAQ for Flutter’s official stance on desktop development.
    (…)
3 Likes

That’s actually quite interesting, and for me anyway, would make Flutter more attractive.

You can use RubyMotion to make desktop (OS X) apps as well and I’m definitely going to revisit it when I start looking at mobile again.

1 Like

Been away from the forums for a bit. This year I was all over the place, from NET Core and F# Suave, to working with SPAs in Vue.js and then Nuxt.

…and now I’m checking out Flutter for a project or two.

So far, Flutter does look interesting. The lack of a JavaScript bridge will certainly help things performance-wise.

Biggest question to me right now concerns the overall UX - how mature is the iOS Cupertino library, and how easy / hard it will be create non-Material Design themed widgets. I guess I will soon find out…!

3 Likes

Wouldn’t reasonml’s (ocaml) native compilation enable to bypass JS on mobile for React in the long run? I didn’t search for it but maybe it would be Facebook plan.

5 Likes

iOS development is my day job. I compiled the tutorial app when flutter went 1.0b1. I successfully deployed on an iPhone 5s and the android emulator. I don’t own an android phone at the moment.

Generally I’d say the tooling is pretty good. No inexplicable errors or issues that I couldn’t follow-up with a web search. Hot code reloading really works and having to deal with the slow compilation of swift 4, seems almost miraculous to see happen on an Apple phone.

The API is very event-driven. It feels like they intentionally hid-away a lot of the lower-level details of client-side programming that UIKit has progressively been trying to hide for the last six years. I get the feeling the language is aimed at web developers who are accustomed to JavaScript syntax.

Can you make a quick-and-dirty tableview-listing app with it? Yes. Will you get stuck in the weeds when doing something a little more exotic like websockets? Yes.

Michael

3 Likes

yep, I smell it… it is coming:

https://twitter.com/reasonml/status/946460440955113472

2 Likes

:wave: I’ve played with flutter for a few days and I must say I quite like it.

Biggest question to me right now concerns the overall UX - how mature is the iOS Cupertino library, and how easy / hard it will be create non-Material Design themed widgets. I guess I will soon find out…!

I didn’t quite like the Cupertino widgets as well as some basic ones like TextField, they just don’t feel native enough thus creating this eerie feeling of something being a bit off. Like there is currently a bug with TextField where a tooltip’s arrow not showing above the selected text but under the tooltip’s center. And there are more issues like that for other widgets opened on github … But they’ll probably get fixed? That is, if flutter lives …

As for creating custom widgets, that’s what I liked the most about flutter. It’s very easy to make almost anything you want with very little code which is great for me since I usually style UIKit’s components heavily (which wasn’t very difficult per se, but still required too much code compared to flutter). I also like flutter’s take on navigation. I used to compose my apps out of “coordinators” to avoid dealing with segues and flutter’s Navigator with a parent widget kinda feels like it can take over the job of a “coordinator”.

UI Performance is not always great with flutter, but there are tools to help debug common problems like blocking UI thread or Skia re-drawing widgets too often.

The interop with the underlying platform is complicated …

And, as many have mentioned, dart might feel dated if you are coming from swift. The most daunting things about it are null checks everywhere and unexpected throws (there is no concept of marking a function as throwing as in swift). Also, I’m not quite sure about dart’s multithreading story.

The tooling though is excellent, and so far for me outweighs the language’s problems. Before flutter I used to have an xcode playground open for REPL-style development which imported a framework which served as a proxy to the app, and it would often crash or hang on me.

There’s also a problem with 3rd-party libraries – there just aren’t many of them and what’s there is just not as good as a swift’s alternative. For example, the most popular sqlite library doesn’t even have wal mode support and the only quickcheck library is not dart 2 compatible.

2 Likes

:wave:

Actually, it felt much easier to work with websockets in dart than in swift for me. What I did get stuck with was interacting with the underlying platform and drawing maps. So I decided to make as much “service” work as possible in swift and use flutter mostly for UI and some business logic. I hope using both swift (instead of objc) and flutter wouldn’t bloat the app size too much …

1 Like

Just to summarize, what I liked the most about flutter and dart:

  • everything is a widget – makes building custom interfaces (both in the way they look and move (animations)) easier since everything is composable unlike in UIKit (although small container view controllers can achieve the same level of “composability” but that requires much more work than in flutter)
  • Stream and Future in dart’s stdlib
  • kinda lend themselves nicely to the “functional core, imperative shell” idea*, which is a bit hard to get right with uikit since it requires an active effort
  • tooling – hot reload, testing library, vscode integration (had to use it since there doesn’t seem to be emacs mode for flutter yet), debuging tools, although very primitive, do help as well
  • reasonable UI performance (but it’s quite easy to make mistakes and make the app janky right now, just even by following the official codelabs)
  • supports ios 8+

And what I didn’t like about dart and flutter:

  • not enough types – like there’s no Option type, some type mismatches are checked during the runtime which felt strange: I can mark a function as returning Widget, but return nothing instead, and the compiler is ok with that and only emits a warning. And there is no easy way to build new types like Option or Result.
  • everything can throw – hence lots of try/catch blocks (ideally I’d have none of them)
  • interop with the underlying platform – can’t show the platforms views like maps in flutter’s canvas easily, same goes for camera, arkit, keyboard, etc.

[*] by the “functional core, imperative shell” here I (probably wrongly) mean the untangling of the app’s core business logic from the inbound and outbound IOs. In flutter widgets like TextEditingController and other “controllers” take care of the inbound IO which can feed the business logic modules with Stream, which then can feed the outbound IO (any visible widget) with some other Stream as well (the widgets are reactive and they get redrawn when their properties change). Similar to rxswift but without fighting with uikit, this also seems to remove any need for viewmodels (I can just add some private helper functions to widgets instead). There is also rxdart, but I haven’t tried it yet.

5 Likes