* Developing plugins (to use native code functionality) is fairly easy. I recently created a PDF viewer plugin for Android without any prior knowledge of java, in 2 days.
* Dart has smaller ecosystem but dart is a real language with a batteries included std library. I don't think I need to state the superiority of dart as a language.
* Flutter's non native components make it easier for you to customize them
* Flutter doesn't have an obvious way to use native views in apps. You can launch native views but compositing native and flutter views is a bit weird right now.
* The ease of use in the development cycle is phenomenal. Nothing like I've ever seen in UI dev.
I would add on the Cons that Flutter is a bit more verbose than React-native since it does not have JSX. And also on the Pros that the community is much nicer on Flutter, RN is Facebook's own pet project and it's very visible when you run into issues.
Since there's so much competition in this area, hopefully this means Apple and Google will start to make this style of development a native part of their APIs and IDEs.
My only complaint so far is some things are not documented very well.
I started leveraging the json_serializable lib and all my responses were returning null... it took me a few days of heavy debugging to figure out it was how I crafted my constructors and how the code generators worked with it.
It's been a pleasure to work with the past month. Traditionally I've worked with Cordova/Ionic and I feel far more productive than I have before on mobile. I was skeptical of the Dart language but now I've seen it's similarities with C# and really enjoy it. The whole widget model is pretty nice to work with too.
The experience of going from zero to HelloWorld with VSCode was so smooth. The community has done an excellent job with the VSCode extensions. Things like picking/install/starting an emulator is quick and intuitive as opposed to the work it takes to initially get thing Xamarin installed and running.
Hot reloading works well on a device or emulator and is really quick! There isn't support for remote updating (yet) once you've published to a store though. There is a GitHub issues tracking this.
Dart is a nice statically typed and compiled C-style language. If you have experience with another such language, it will feel like you already know Dart. The language compliments Flutter well, and the Flutter SDK makes it simple and easy to rapidly build a functional mobile app.
Lack of certain features, like reflection, in mobile Dart creates a rift in packages you can utilize in a Flutter app. There are a few warts in the type system, mainly around generics, and little things like the lack of union types and type aliasing.
There are also a few outstanding bugs that you might run into, which have had relatively long life since they were identified. The Dart team seems to be reluctant to add new features.
Also, managing state in Flutter is a little unclear: documents and videos from Google recommend four different ways to do so: explicitly calling setState(), Streams with StreamBuilder, scoped_model and the various third-party Dart/Flutter Flux implementations.
Most languages I can think of have this type, from void* to dyn to bounding by the root of the type hierarchy. Not all languages. However, what is c, c++, java, rust, go, if not statically typed? Ambiguously typed? Seems like not a useful distinction to make.
I argue static typing is the ability to static type up to 100% of a program, not the exclusion of a dynamic type.
Rust doesn't have such type. And type annotations in Dart are optional - when programmers are not obliged to use them, guess what will happen? They do NOT use them. People are lazy.
Dart's types exist only on compilation step. You can try to use "strong mode" in theory, in practice you will never compile it with third-party libraries.
> And type annotations in Dart are optional - when programmers are not obliged to use them, guess what will happen?
The type system will infer a static type based on the type of the initializer.
In some cases, inference may fail to infer a type. Right now, that can silently give you dynamic, but there's a flag to make that an error. I expect before too long that will be the default behavior.
If you have a well-thought out argument, and not a quippy one-liner, I'd earnestly like to hear it.
Dart's developers think otherwise[1]:
> Q. Is Dart a statically typed language?
> Yes, Dart 2 is statically typed. For more information, see Dart’s Type System.
> With its combination of static and runtime checks, Dart has a sound type system, which guarantees that an expression of one type cannot produce a value of another type. No surprises!
> Even with type-safe Dart, you can annotate any variable with dynamic if you need the flexibility of a dynamic language. The dynamic type itself is static, but can contain any type at runtime. Of course, that removes many of the benefits of a type-safe language for that variable.
> With its combination of static and runtime checks
Do you personally use it? That "strong mode" is a theory-only thing, it doesn't work with any real code, only with code you wrote without real third-party libraries.
You are, at best, confusing Dart 2 with Dart 1; strong mode was one of several Dart 1 modes, but, yes, it's possible to run into problems because dependencies weren't designed for it.
There is no option in Dart 2; everything is the equivalent of strong mode, which eliminates ecosystem problems.
> only with code you wrote without real third-party libraries.
Your claim was true several years ago, but since then the entire ecosystem has migrated onto the new strict type system. It was a monumental amount of work, but, thanks to lots of effort from our users, we're there.
Aside from a small number of more-or-less dead packages, you should be able to use any third-party Dart packages you want while still using the new type system.
C#, Scala, Kotlin, TypeScript, et. al have a dynamic type. As long as every type isn't dynamic, I think it's reasonable to claim you have static types.
I work for a Danish city with 60.000 inhabitants, so we're a small team, and because of that we looked into flutter since it seems like an easy way to do mobile for people apt at c-like languages. We even had some internal talks about angularDart and flutter being comparable to react and reactNative.
Our proof of concept wasn't that much of a hit though. Flutter integrates really, really well with Firebase, but being the public sector in Europe, I don't see us using Google cloud anytime soon. Without it we couldn't really get a full stack dart thing running because stuff like aqueduct isn't mature enough, and is really hard to run within Azure. At least if you want to run comparable to other options seeing how application insights even works on Node.
Dart is a nice language, and Flutter is certainly an easy way to do mobile apps, but I don't see us using either, unless they becomes much more popular.
Microsoft was a lot faster to accept and accompany our privacy terms. The EU data protection laws that you've seen all the fuzz about may be new for the private sector, but in much of the public sector we've actually been under much stricter requirements for years. If you have a big enough agreement with Microsoft, you can even have your data stored on servers you have physical access to and share with no-one else.
AWS was a little slower, but now meet the same requirements, pretty much. Other parts of the public sector is big in AWS instead of Azure.
Google only recently got into any type of real agreements with the EU on data protection, and they're still far from having national agreements. They also don't meet EU requirements on all their products, making it easier to blacklist all Google products than risk your GIS department using Google Maps or your PR department using Google analytics, both illegal for public usage.
For us personally we have more than 25 years of partnership with Microsoft, who have an excellent record on support. By contrast we've never really worked with Google, and we're not typically the ones to try new things. :) Especially not when we're happy with what we have, and since we already have a presence in Azure, I doubt we'll be expanding to another Cloud when pricing is pretty competitive between them. I mean, to run two clouds would also mean our operations crew would need to obtain security certifications for both, which is fairly expensive.
Technically and legally we could sign an agreement for Firebase in particular, and host our mobile apps with a Firebase backend, but as that's not likely to happen, Dart would need to become popular enough to integrate seamlessly and easily with Azure for us to use it.
One reason could be that from what I understand Azure licenses it's cloud software to other providers ("Azure Stack"), so you can get "Azure" run by a European company in an European data center, or even a state-owned one.
* Flutter is faster. You really notice that for example the animations in flutter are much smoother than in RN
* Flutter has really fast development cycle with hot reload (< 1s)
* Writing UI only once for both iOS and Android
* Better documentation
* Better tooling support in editors (VSCode and Intellij)
Cons:
* The Flutter ecosystem is quite small, there are many lacking plugins
* The Dart ecosystem is way smaller than JS
* RN uses the native widgets, in Flutter they are mimicked and sometimes wrongly, for example the iOS datepicker