The Marketplace tab in the FB app is written in React Native. The Ads Manager app is written in React Native. The Instagram app is written in React Native. The entire FB app is not written in React Native yet, but overtime I'd expect more things to be. The statement that FB "abandoned react native on mobile" is demonstrably false.
It seems unlikely that FB would give up on Litho, which is extremely performance focused, to use react native instead. Not for their bread & butter flagship news feed anyway https://fblitho.com/
First, both Litho and React Native build on Yoga so there's a fair amount of code sharing.
Second, they serve different purposes. Litho will be used for FB scale optimization of certain intensive views. React Native is used for fast developer productivity. I'd wager that RN will be used in most places and Litho is used in hot spots sparingly.
Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better,…
I was thinking MAUI(rebranded Xamarin) might be somewhat useful with .NET6 coming out. I've been playing with it the last week or so, it's quite nice.
For what it’s worth Dart is hands down the nicest OOP language I’ve ever used in my opinion. It’s like they took all the good things about JS and Java and cut out all the bad parts. What’s left is basically Dart.
I think the decision of which cross platform technology to use mostly depends on a team's preferred tech stack. C++ -> QT C#/.NET -> MAUI/Blazor JS/Web -> React.Native/Electron Dart -> Flutter This is what I think is holding back Flutter -- that it wasn't built on an incumbent technology. Because Dart doesn't have quite the following, it has to evangelize itself a bit more than the other options.
Qt has some pretty good bindings for other languages other than C++.
> Flutter is by definition a canvas optimised framework Not really, flutter has not the resources to develop their own 2D renderer so they use the chromium renderer for drawing. (Skia). It is canvas-like, everything is canvas-like at low level. But flutter like browsers implement retained mode rendering which is necessary for being jank free and have low energy consumption. Flutter on web canvas cannot properly do re…
CanvasKit still renders to canvas (maybe that's what you meant by "canvas-like", but it is still directly drawing to an HTML canvas), it just enables Flutter to utilize a more advanced feature set than the DOM canvas API. It also comes with a 2MB or so download (which is why by default it's off on mobile last I checked).
you did not understand my point, canvaskit is skia but slower, over wasm. It output to an HTML canvas and HTML canvas are immediate mode, they do not have retained mode rendering (display lists, occlusion, caching, etc).
Besides I don't think canvaskit is faster than regular HTML canvas. Even if canvaskit might avoid some compute that would normally be done at the HTML canvas level, canvaskit could implement retained mode rendering but 1) it does not 2) it would not really be appropriate because of the unstructured API (unlike DOM), 3) the final HTML canvas would still behave immediately.
As I said, it's important to realize that you are rendering skia (html canvas) on skia (canvaskit wasm) the amount of overhead and rendering duplication is in theory crazy.
In case any Flutter engineer/PM is watching this thread, any update on when the Material 3 components will be released? I have an iOS Flutter app that's getting pretty popular in its niche, but I'm waiting on the Material 3 components to be there to release an Android version.
That was part of the release today I believe.
Maybe I missed it? It seems like they got some working but got a bunch on their roadmap still [0]. I just talked to someone over there and all he could say is that they're working on it.
Doesn't appear to based on the website, which is just sad considering it's almost zero effort to create an Android build as well. I'd consider using this app also.
I could indeed build it for Android, but since I'm using the Cupertino components, it would look and feel like an iOS app. As I said replying to the parent comment, I'm currently waiting on the Material 3 components to be available before I do that.
Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better,…
> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't enjoy using it. All anecdotal: I've only met one person who was excited to work with Dart, huge Google fanatic/fanboy. Otherwise it's sorta seen as a unique language choice that makes other devs go, "oh..." The Java/ECMA ergonomics are weird, it's hard to find devs who have experience with the…
As an early Flutter adopter, the ecosystem was a big problem, and while it seems to have progressed, it's still pretty anemic compared to other language's ecosystems.
People being pleased with Dart is only because they have not tasted better, everything is relative. Kotlin is miles ahead.
Yes, of course, everyone who disagrees with me is just an idiot who doesn’t know better. Excellent discourse.
That's right, my discourse has no argumentative value. I do not advance any substance allowing you to agree or disagree. It's just a difference at the premise level, I have experienced dart and I have experienced Kotlin. Learn boths properly (reading the kotlin guide is sufficent and can be done in an afternoon) and then you will be able to judge if I was wrong or not. From experience, the difference is huge and affect every aspects/features of the language, without even talking about the JVM ecosystem interop.