Anybody using only dart for their mobile apps, how has been your experience with it? Where does it triumph & fail over RN??
* 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
* 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 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.
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.
I'm a fan. I hope the community grows around it.
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.
It definitely beats native development.
I argue static typing is the ability to static type up to 100% of a program, not the exclusion of a dynamic type.
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.
*const u32 const uint32_t *p
I'm not sure what you mean about trait names. The purpose of the Any trait is to make it possible to pass around values of any type and dynamically downcast them, as the documentation indicates. That is a safe analogue of casting a void pointer to another type.
fn example(foo: Any) -> u32 {
foo+55
}
It's the difference between dynamic language and language with synthetic type for reflections.
In any case, you're moving the goal post from "concrete type at compile time" to "can represent any type", which is inherently going to be specific to how the language defines types. This is not an especially useful type of dynamic representation so I'm not sure why it would be desirable.
Any talks about special traits in Rust are offtopic, while code I wrote as example can't be compiled in Rust and can perfectly work in Dart.
I wasn't trying to argue about words or terms, I was trying to say the gist: Dart has dynamic type, so you can send to your function any type and this function will just use it, without any downcasting - language will take care about it; and Rust doesn't have such type: you can't even compile code which is trying to work with variables like you can do in dynamic languages.
But then all of that useless arguing... It's really funny when I see how people are trying to prove that Rust has same dynamic type as Dart. The very nature of these languages is different.
let i: u32 = 1;
let p_imm: const u32 = &i;
Look at the const u32 in the type position.
The rust book even refers to const and mut pointers as types.
The rust book even refers to *const and *mut pointers as types. *const u32
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.
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.
[1] https://www.dartlang.org/faq#q-is-dart-a-statically-typed-la...
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.
There is no option in Dart 2; everything is the equivalent of strong mode, which eliminates ecosystem problems.
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.
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.
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.