I think developers often want to find a “one true cross platform toolkit for all cases” and I don’t believe that will ever exist. It depends so much on both your app/market but also the skills and experience within your team. No 1 priority is move quickly.
Flutter is brilliant, and probably the way to go, for some apps. A great example of a successful Flutter app is the Sonos app, relatively simple and responsive ui talking to an api. No “rich” or user supplied content. Although they haven’t replaced their desktop app with the flutter app, my guess is that it is the plan.
I think Flutter is brilliant for that type of IOT app, banking/crypto/utilities also the sort that would work well. I don’t think it’s best placed if you want to start using WebViews for some content, when I was last looking at it a year ago there were serious problems.
If you are building a social media app, either Native or React Native (or a combination) is probably the best way to go. You are aiming high so need the best performance and ux.
If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.
For an e-commerce app I would probably go Iconic/Capacitor too, the Amazon app for example is mostly webviews.
Productivity apps are much more difficult to recommend for as you probably need large native components.
I've been wondering why webviews with native page transitions aren't a more commonly used thing. It improves the UX a lot by dealing with the abrupt navigation changes of regular web apps. There was a plugin for Cordova that did this (https://github.com/Telerik-Verified-Plugins/NativePageTransi...) but it's abandoned.
You render your mobile web view like normal, wire up a JavaScript handler (formerly known as Turbolinks), and push native screens on iOS. It works really well for CRUD and "boring" SAAS apps with little interaction outside of forms. And when you need higher fidelity dropping down to SwiftUI or UIKit is straightforward.
To make things even simpler, I built Jumpstart iOS, which takes care of all of the Swift boilerplate. Navigation, authentication, and push notifications all work out of the box after adding a few endpoints to your server.
Same here, it’s something I wish Capacitor supported.
Last year I experimented with using NativeScript in a Capacior app to open native modals with a second webview. Since then Ionic have released “Capacitor Portals” which brings all the native apis available within the Capacitor webview to native apps, effectively allowing you to embed capacitor views in another app. I wander if there is the potential to combine the two to get the native view transitions.
Edit:
Just to elaborate a little further on my experiment. Effectively what you ended up with was the two webviews being able to communicate with each other as though you had used the window.open or frames JavaScript api in the browser.
> If you are building a social media app, either Native or React Native (or a combination) is probably the best way to go. You are aiming high so need the best performance and ux.
I'd also add that from a business perspective if your product heavily depends on or is entirely mobile-based then it often makes sense to go native and remove an extra party, you don't want to be stuck waiting for upstream fixes or features to land months after they've been released.
Agree! I have been building a React/Next capacitor application for a Dutch e-commerce with a colleague.
Up until now everything is fine for our purposes and performance is near native. Usually similar e-commerce apps require multiple teams, or at least 5+ employees, to release an app on web, Android and iOS. Due to the fact that we have just one single codebase, we can still manage it with the 2 of us.
I also recommend the Capacitor community on Discord in case you need help getting started.
>If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.
Honestly nowadays with Expo I would never suggest doing a hybrid app anymore unless you have a large existing JS codebase you want to leverage. Expo makes React Native development so ridiculously simple from the point of scaffolding your app all the way through the app store submission process that there's really no productivity loss anymore vs. doing an Ionic app. The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.
> The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.
Agreed. I would even say in these past 3 years or so, React Native development has smoothed itself out. The experience of setting up an app and being productive in it coming in as a web developer is phenomenal. One thing is that the community support is still small compared to native or even React itself. Peformance too is lacking. I've been waiting for the new architecture Fabric to come in replacing JSC with JSI but it's taking quite a long time. There still isn't a clear estimate on it's release yet.
For mobile, if you ask me, the only sane cross-platform strategy is what Kotlin Multiplatform Mobile [1] intends to do: portable business logic, and leave the UI aspects to each platform, keeping them native.
Both Android and iOS have been making strides in simplifying DX for composing expressive UIs. It only makes sense to use those new Android Studio/XCode features as they come.
While I agree where Kotlin is going with their multi platform tooling is great, I do think it’s just one more option in an already good bag of options. And a strong one at that.
My one observation though is that for many (the majority?) of mobile apps the UI layer is the vast majority of the app, easily 70-80%. Especially for apps where the business logic is calling a http api, which most CRUD type apps are. For these a cross platform toolkit that abstracts away ui differences so you only have to build it once is a massive plus.
I've been waiting for the right opportunity to use it and for it to mature a little more. I really wish we could go the other way since we have a bunch of existing Swift packages and our team is much stronger on iOS than Android.
The myth that Ionic is slower than react native (android native - > skia ) or flutter (skia) has to stop. The evidence isn't just there anymore, chromium is the open source library with the most human resources on earth (mlre than 1 million commits) and therefore has more optimization resources than any competitor. The addition of edpressivity through new features in newer releases does not slow the browser despite the very infantile and hand wavey idea of "bloat" that many HN readers share.
In fact Ionic should be even faster than Electron since it embed many modern optimization practices inside the UI framework. Unfortunately it seems people have zero interest doing serious benchmarking of similar tasks on multiple GUI renderers so the myth stay pervasive. What is sure is that you will never actually have significant performance issues in Ionic or otherwise you're doing something wrong.
Still the myth allows react native and flutter to survive relevancy despite their major ergonomics and expressive inferiority, but for how long? People are used to experience that Electron apps are usually better and faster. The smartphones double standard will break.
Not my experience, and I'm not talking benchmarks. That said I barely use my phone and I'm thinking mainly about desktop applications. Mac-native apps are universally faster and more responsive than Electron-based equivalents.
Doing more work costs more resources than doing less work, and it's hard to beat JITing Javascript and manipulating and rendering HTML+CSS for wasteful computation, no matter how much you optimize it.
That said, I've used phone apps that were essentially some webpage in webview that were highly responsive and pleasant to use, so it's certainly possible to have a good experience with webapps.
Reducing the amount of Javascript and using simpler HTML+CSS would also probably go a long way to make these apps fasters and lighter. I remember using AJAX-based chat websites in the 2000s that ran perfectly fine on hardware far weaker than even a 5 year old phone, so how the heck does Slack have such poor performance? That's the real problem.
Completely agree with you on performance, certainly on any mobile device with less than 5yo tech. I think there are still a few performance problems on older/low-end hardware, that’s why for social media type apps I would recommend native. You would have the same perf problems with Flutter and React Native on that hardware.
I have only one significant complaint that effects Capacitor on iOS and it’s a WebKit bug (Ionic can’t fix it). With WebKit on iOS if you have an overflow:scroll with a text input of any kind (basically any app you build) the text cursor or selection highlight will remain visible outside the overflow area when you scroll. So for example if you select text in an input and scroll the view so the input is under a fixed toolbar, the selection highlight or cursor is visible infront of the toolbar. It looks very messy, I wish Apple would fix it. The minute you see it you know it’s not a native app.
> Still the myth allows react native and flutter to survive relevancy despite their major ergonomics and expressive inferiority, but for how long? People are used to experience that Electron apps are usually better and faster.
My concern with Ionic/React native isn't speed (I'm sure it's good enough), it's maintainability. I've been burned enough by the JS ecosystem to stay away from it when I can. It usually takes around 1 hour to update 6 months worth of Flutter framework & packages updates, I can't say the same about the javascript ecosystem.
On paper it looks awesome, in practice I just don't want to deal with those maintenance issues anymore.
There is obviously no correct answer here, very good arguments on both sides.
Personally I prefer an opinionated framework, I don’t have to research library’s and tooling. It all just works and I have a single set of docs for reference.
Ionic is a html/javascript/css mobile ui framework using web components, with bindings for Angular, React and Vue. You can build PWAs, mobile web apps, or with Capacitor actual mobile apps with it.
Capacitor is a mobile app toolkit for building apps with web technologies in a webview. Effectively the successor to Cordova/PhoneGap. It’s built and maintained by the same team/company as that behind the Ionic framework.
Some opinions about good choices here, over a year of app development:
* Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised.
* There were a couple of storage plugins like hive that claimed to be better because they be native to the platform and not SQL. As with all platforms, that's bull. SQLite is available, so use that.
* The routers are a clusterfuck, the recent addition of declarative routing by the flutter team was a step in the wrong direction. However, the go_router (in the list) that's based on that looks actually nice.
* Evade everything with code generation, it hinders a good development workflow and the related plugins for that regularly break. For JSON-serialization that's hard though, I make an exception here, since there are many DTOs to manage.
* Flutter theming is a mess. An example that says it all: If you set a colorScheme with a primaryColor, Theme.of(context).primaryColor is not automatically that color. The results of the new ColorScheme.fromSeed() were awful in my test. flex_color_scheme solves that. Be prepared for significant changes here when Material 3 gets fully introduced to Flutter (the recent release 2.10 started with that).
Some things to keep in mind despite plugins: Flutter is not ready for the web (and the sites it would produce are JS abominations, so it will never be suited for the web if the approach does not change) and while the framework seems more stable than native app development, there are still breaking changes, both in the core and even more so in the plugin ecosystem. Selecting plugins based on a good stability is hard (as it's not obvious), but worthwhile.
Despite its shortcomings and Google connection Flutter is really nice to build iOS and Android apps with one code base, and I'd prefer it even for just an Android app by now.
GetX is a very high-level API for Flutter, it works for simple things, but as you go on you will realize how restricting it is. It abstracts away details not meant to be abstracted away. It's just bad design, and it's anti-patterns will bite you.
Just learn how to do things the proper way, because it's not that hard, and much more expressive and clean.
If you go for Flutter job it's best to not mention GetX either.
It works perfectly for us - in a professional app nonetheless - and has not been restricting at all. No bad design or anti-pattern bit us, and it does not get cleaner or more expressive than Obx with a controller. This is unlikely to change, the process where our app got more and more complicated has already stopped.
> If you go for Flutter job it's best to not mention GetX either.
I wouldn't work for an employer that does not let me pick the right tool for the job, so there is no danger there.
This is terrible advice. GetX is great for rapid prototyping but nothing more.
Once you reach a certain point you will need to re-code your entire app to get rid of this.
If you choose GetX, you are no longer building a flutter app, you are building a GetX app, and you will want GetX developers to work with the code and at some point it will becomes unsustainable and you will need to start over.
GetX is bottom of the barrel flutter development, and is only valuable for people who churn out large amounts of apps for customers that have no idea what they want.
Flutter team has already stopped developing for mobile, leaving a lot of things unfinished or missing: integration testing, location, iOS dark mode, iOS keyboard dismiss, iOS detail cell and other common iOS widgets, material date+time picker, navigator documentation, and others.
The page is called "Awesome Flutter" but it should be called "Third-party Flutter code to fill some of the holes in Flutter".
> Don't get confused by the myriads of state management solutions...
> Evade everything with code generation...
It is funny to see this theme getting repeated in various domains: at the same time, you will get users who complain that there are not enough choices for them in domain X, while others complain that there are too many choices in the same domain X. And usually there is no single best solution to rule them all.
E.g. in these specific items, I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.
> I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.
YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression.
We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything.
It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.
> Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised.
Saying this doesn't help anyone. There are many alternatives and as you say, they compete fiercely for Github stars. GetX is popular package, but it has it's drawbacks: maintainer and bloat.
- Maintainer: he's been known to make wild claims about his package, and target other alternatives with strong unbacked opinions.
- Bloat: it tries to do a lot of things. Integration with other packages, concepts and tools don't work well - certainly doesn't integrate easily.
That's exactly what I mean - none of this matters. The maintainer does his job well and GetX does solve the problems it claims to solve nicely. Use Obx with a GetX controller and you are done. The other parts of the project, like the routing, are an option if it fits to your app.
And sorry, I really think this stated clearly is helpful. It's not worth your time to even look at alternatives. Sure, that could change in the future if the plugin gets abandoned, but it has seen good maintenance so far and zero breakage. Everything else to my eyes is FUD.
>Despite its shortcomings and Google connection Flutter is really nice to build and Android apps with one code base, and l'd prefer it even for just an Android app by now.
Have you tried building android apps with Compose? It's significantly better than the old view system in android.
Indeed I have not, its 1.0 release came after I had moved on from that job. Does not look as nice to me, from a first glance, but that might be misleading. Thanks for the hint.
Loving Flutter to bits. It's been such a tremendous help publishing a fast, reliable and good looking app cross platform. It can't really be compared to anything else. The regular updates are awesome as well. There is always performance improvements and other things to look forward to.
It's always been dart that put me off. For flutter apps supposedly compiling to native code, I don't like using a language that was apparently designed to live within the constraints as a web-based language. There are many other languages that I would rather use instead.
I suspect that mid term this is going to be changing. There is currently a big behind the scenes push to move the web target to Wasm (dependent upon Wasm GC landing in some kind of reasonable timeframe).
At that point I suspect you will see the importance of compiling to JS declining rapidly.
Side note: The other major push that seems relevant to some of the other comments here is they are also looking to redo the shader pipeline from scratch and make that AOT compiled as well because right now it tries to just JIT all of that and it isn’t always very predictable as a result. [1]
So combining that along with a WASM target I actually feel super bright about the future of Flutter as a tech choice on web, desktop, mobile etc…
They have some more detail about both of these things in their Roadmap [2] if you’re interested.
I am not a programmer by trade, but I do build apps occasionally.
Dart is a relatively simple language and you'll get the hang of it quite quickly.
The widget-tree framework of flutter makes it easy for you to just have small amounts of code that all chain together, and it becomes easier to find your mistakes and grow your platform.
I was surprised to see how janky the gallery demo app is on mobile, especially considering Dart is AOT compiled. Apparently Flutter is single threaded too and has a feature called "Isolates" but I'm not sure if they can be used to paint animations off the main thread
The gallery demo app is janky on old Android devices with bad GPU drivers, and janky on iOS because of Metal, but those issues are being solved. The main issue with iOS and Metal is the shader compilation jank, for which the workaround is shader warm-up that can be automated, but requires an effort from the developer.
Dart is single threaded, but the event loop is better than threads for most things, except heavy calculations, but that's what isolates are for. This is probably the best way to do it even in C when latency is important. CPU schedulers tend to leave you with less control over latency when there is underutilization or yielding.
When I tried it a couple of weeks ago on an old Android device (Pixel 3A) there was a little jank. Then I tried a couple apps bundled with Android and was surprised to find a comparable amount of jank.
I think they should give up on Flutter for Web and just focus on mobile and desktop (and maybe extend use on Smart Watches, Smart TV, embedded instead). Too many people still remember Java Applets, google's GWT, Flash/Flex and how it ended. They are out of focus trying to support Web as well.
I had also higher expectation regarding Dart FFI - I think with their ffigen we are still only in ctypes like python bindings territory. Nowhere near something like pybind11 [0] for c++ bindings yet.
Expo has been making unbelievably rapid progress with tooling, documentation, consistent, high quality API's and general improvements. Evan Bacon + team are really impressive to watch
There is no clear winner here yet. Every solution has pros and cons.
1) Need mostly cross platform desktop and using hardware extensively (bluetooth, camera, audio, nfc, sensors, etc.) -> Qt
2) Have web expertise or need easily to find well paid job and need mostly web, android, ios app -> React Native
3) Need only iOS, Android app that is mostly custom UI with some smooth animation mostly for some side project (not many jobs in the market comparing to React Native or iOS/Android Native) -> Flutter
I love the idea of Flutter, as I think it's a more stable approach than what React Native tries to do. But I hate Material Design with a passion, and I'm not sure why they tied it so closely to Flutter. Even the functional packages you import into your Flutter project are labeled "material".
I'll give it a chance when it has algebraic data types and pattern matching. The fact that they post these as examples of language features they don't want means I don't want to touch it with a ten-foot pole. I look at Option, Either, and functor in dartz and I can see that the ergonomics are so bad and noisy to read. Semicolons required in a modern language is the cherry atop this ‘nope’ dessert.
Dart is like Java, Kotlin or Swift with the runtime model of JavaScript, there is nothing weird about it. It takes an hour to learn it if you know either of these.
The language fades into background in my experience. There are some gotchas (like overuse of Dynamic) but on the whole, tooling works really well, and can get stuff done.
Why is Dart weird for you? I've seen people getting to know Dart from various backgrounds (be it from Java, JavaScript, C# or Python), and so far everybody got productive in a short amount of time.
You can learn new language in short time but standard library and tools not that fast - especially if they dont exist. You will have to google e.g. how to parse Date etc. People enjoy big ecosystem of libraries and tools.
Just to give you example In many ways I prefer Ruby than Python as a language but Python is just swiss army knife and in many cases you are one PIP install away to finding library that solves your problem. Maybe Python doesn't have such a nice web framework as Ruby on Rails but ruby is not much used elsewhere.
I think people complaining about Dart as a chosen language not because of it's features but because
1) you have to learn and/or redevelop new SDK for it,
2) language doesn't have good interrop with any other languages (like Kotlin -> Java, Swift -> Objective-C, TypeScript -> JavaScript, Objective-C -> C++, Rust -> C, C++ -> C)
Readit News
Flutter is brilliant, and probably the way to go, for some apps. A great example of a successful Flutter app is the Sonos app, relatively simple and responsive ui talking to an api. No “rich” or user supplied content. Although they haven’t replaced their desktop app with the flutter app, my guess is that it is the plan.
I think Flutter is brilliant for that type of IOT app, banking/crypto/utilities also the sort that would work well. I don’t think it’s best placed if you want to start using WebViews for some content, when I was last looking at it a year ago there were serious problems.
If you are building a social media app, either Native or React Native (or a combination) is probably the best way to go. You are aiming high so need the best performance and ux.
If you are building a b2b SAAS app I would probably reach for something like Ionic/Capacitor. You can share almost all you codebase with your web/PWA/desktop (electron) apps and can achieve it all with a tiny team. If you need a little more native functionality then adding in NativeScript to a Capacitor works very well.
For an e-commerce app I would probably go Iconic/Capacitor too, the Amazon app for example is mostly webviews.
Productivity apps are much more difficult to recommend for as you probably need large native components.
You render your mobile web view like normal, wire up a JavaScript handler (formerly known as Turbolinks), and push native screens on iOS. It works really well for CRUD and "boring" SAAS apps with little interaction outside of forms. And when you need higher fidelity dropping down to SwiftUI or UIKit is straightforward.
https://github.com/hotwired/turbo-ios
To make things even simpler, I built Jumpstart iOS, which takes care of all of the Swift boilerplate. Navigation, authentication, and push notifications all work out of the box after adding a few endpoints to your server.
https://jumpstartrails.com/ios
Last year I experimented with using NativeScript in a Capacior app to open native modals with a second webview. Since then Ionic have released “Capacitor Portals” which brings all the native apis available within the Capacitor webview to native apps, effectively allowing you to embed capacitor views in another app. I wander if there is the potential to combine the two to get the native view transitions.
Edit:
Just to elaborate a little further on my experiment. Effectively what you ended up with was the two webviews being able to communicate with each other as though you had used the window.open or frames JavaScript api in the browser.
I'd also add that from a business perspective if your product heavily depends on or is entirely mobile-based then it often makes sense to go native and remove an extra party, you don't want to be stuck waiting for upstream fixes or features to land months after they've been released.
Up until now everything is fine for our purposes and performance is near native. Usually similar e-commerce apps require multiple teams, or at least 5+ employees, to release an app on web, Android and iOS. Due to the fact that we have just one single codebase, we can still manage it with the 2 of us.
I also recommend the Capacitor community on Discord in case you need help getting started.
Honestly nowadays with Expo I would never suggest doing a hybrid app anymore unless you have a large existing JS codebase you want to leverage. Expo makes React Native development so ridiculously simple from the point of scaffolding your app all the way through the app store submission process that there's really no productivity loss anymore vs. doing an Ionic app. The tooling has come so far in the last 10 years that you can just easily develop a native iOS app in Javascript like it's a web app now.
Agreed. I would even say in these past 3 years or so, React Native development has smoothed itself out. The experience of setting up an app and being productive in it coming in as a web developer is phenomenal. One thing is that the community support is still small compared to native or even React itself. Peformance too is lacking. I've been waiting for the new architecture Fabric to come in replacing JSC with JSI but it's taking quite a long time. There still isn't a clear estimate on it's release yet.
Both Android and iOS have been making strides in simplifying DX for composing expressive UIs. It only makes sense to use those new Android Studio/XCode features as they come.
[1] https://kotlinlang.org/lp/mobile/
My one observation though is that for many (the majority?) of mobile apps the UI layer is the vast majority of the app, easily 70-80%. Especially for apps where the business logic is calling a http api, which most CRUD type apps are. For these a cross platform toolkit that abstracts away ui differences so you only have to build it once is a massive plus.
Not my experience, and I'm not talking benchmarks. That said I barely use my phone and I'm thinking mainly about desktop applications. Mac-native apps are universally faster and more responsive than Electron-based equivalents.
Doing more work costs more resources than doing less work, and it's hard to beat JITing Javascript and manipulating and rendering HTML+CSS for wasteful computation, no matter how much you optimize it.
That said, I've used phone apps that were essentially some webpage in webview that were highly responsive and pleasant to use, so it's certainly possible to have a good experience with webapps.
Reducing the amount of Javascript and using simpler HTML+CSS would also probably go a long way to make these apps fasters and lighter. I remember using AJAX-based chat websites in the 2000s that ran perfectly fine on hardware far weaker than even a 5 year old phone, so how the heck does Slack have such poor performance? That's the real problem.
I have only one significant complaint that effects Capacitor on iOS and it’s a WebKit bug (Ionic can’t fix it). With WebKit on iOS if you have an overflow:scroll with a text input of any kind (basically any app you build) the text cursor or selection highlight will remain visible outside the overflow area when you scroll. So for example if you select text in an input and scroll the view so the input is under a fixed toolbar, the selection highlight or cursor is visible infront of the toolbar. It looks very messy, I wish Apple would fix it. The minute you see it you know it’s not a native app.
My concern with Ionic/React native isn't speed (I'm sure it's good enough), it's maintainability. I've been burned enough by the JS ecosystem to stay away from it when I can. It usually takes around 1 hour to update 6 months worth of Flutter framework & packages updates, I can't say the same about the javascript ecosystem.
On paper it looks awesome, in practice I just don't want to deal with those maintenance issues anymore.
Personally I prefer an opinionated framework, I don’t have to research library’s and tooling. It all just works and I have a single set of docs for reference.
Capacitor is a mobile app toolkit for building apps with web technologies in a webview. Effectively the successor to Cordova/PhoneGap. It’s built and maintained by the same team/company as that behind the Ionic framework.
* Don't get confused by the myriads of state management solutions. Just use GetX, it's a sane solution that works as advertised.
* There were a couple of storage plugins like hive that claimed to be better because they be native to the platform and not SQL. As with all platforms, that's bull. SQLite is available, so use that.
* The routers are a clusterfuck, the recent addition of declarative routing by the flutter team was a step in the wrong direction. However, the go_router (in the list) that's based on that looks actually nice.
* Evade everything with code generation, it hinders a good development workflow and the related plugins for that regularly break. For JSON-serialization that's hard though, I make an exception here, since there are many DTOs to manage.
* Flutter theming is a mess. An example that says it all: If you set a colorScheme with a primaryColor, Theme.of(context).primaryColor is not automatically that color. The results of the new ColorScheme.fromSeed() were awful in my test. flex_color_scheme solves that. Be prepared for significant changes here when Material 3 gets fully introduced to Flutter (the recent release 2.10 started with that).
Some things to keep in mind despite plugins: Flutter is not ready for the web (and the sites it would produce are JS abominations, so it will never be suited for the web if the approach does not change) and while the framework seems more stable than native app development, there are still breaking changes, both in the core and even more so in the plugin ecosystem. Selecting plugins based on a good stability is hard (as it's not obvious), but worthwhile.
Despite its shortcomings and Google connection Flutter is really nice to build iOS and Android apps with one code base, and I'd prefer it even for just an Android app by now.
Just learn how to do things the proper way, because it's not that hard, and much more expressive and clean.
If you go for Flutter job it's best to not mention GetX either.
> If you go for Flutter job it's best to not mention GetX either.
I wouldn't work for an employer that does not let me pick the right tool for the job, so there is no danger there.
This is terrible advice. GetX is great for rapid prototyping but nothing more.
Once you reach a certain point you will need to re-code your entire app to get rid of this.
If you choose GetX, you are no longer building a flutter app, you are building a GetX app, and you will want GetX developers to work with the code and at some point it will becomes unsustainable and you will need to start over.
GetX is bottom of the barrel flutter development, and is only valuable for people who churn out large amounts of apps for customers that have no idea what they want.
The page is called "Awesome Flutter" but it should be called "Third-party Flutter code to fill some of the holes in Flutter".
It is funny to see this theme getting repeated in various domains: at the same time, you will get users who complain that there are not enough choices for them in domain X, while others complain that there are too many choices in the same domain X. And usually there is no single best solution to rule them all.
E.g. in these specific items, I've found bloc + freezed-based code generation to do state works much better for me than any alternatives. ymmv.
YMMV definitely applies :) Since I have some experience with exactly that alternative: I see bloc + freezed as the antithesis to GetX. "Clean" abstraction over "simple" code. There might be more extreme example for both sides of course, but this has been my impression.
We do use bloc + freezed for some specific flows in the app where the abstraction just fit better. A better fitting abstraction is a big plus on its own for those usecases. On the other hand, bloc had a bunch of breaking changes (nicely visible in https://pub.dev/packages/flutter_bloc/changelog), and that especially in combination with hydrated bloc has given us a bunch of grief. I hate breaking changes more than anything.
It might still be a better solution - so really, YMMV - if your goal is maximum abstraction to be able to change frameworks (or in this case, I assume it would be about state management solutions), after all that's where the solution is coming from. For me, that was an anti-goal, abstraction = complexity, while minimal complexity with maximal development speed was what we needed. GetX fit perfectly for that. Admittedly, ignoring some things to learn with lists and at the beginning strange issues with Obx change detection, but the latter got better, either with bug fixes or experience. If Obx misbehaves now it has always been a clear fault on our side.
Saying this doesn't help anyone. There are many alternatives and as you say, they compete fiercely for Github stars. GetX is popular package, but it has it's drawbacks: maintainer and bloat.
- Maintainer: he's been known to make wild claims about his package, and target other alternatives with strong unbacked opinions.
- Bloat: it tries to do a lot of things. Integration with other packages, concepts and tools don't work well - certainly doesn't integrate easily.
And sorry, I really think this stated clearly is helpful. It's not worth your time to even look at alternatives. Sure, that could change in the future if the plugin gets abandoned, but it has seen good maintenance so far and zero breakage. Everything else to my eyes is FUD.
Have you tried building android apps with Compose? It's significantly better than the old view system in android.
Keep going!
At that point I suspect you will see the importance of compiling to JS declining rapidly.
Side note: The other major push that seems relevant to some of the other comments here is they are also looking to redo the shader pipeline from scratch and make that AOT compiled as well because right now it tries to just JIT all of that and it isn’t always very predictable as a result. [1]
So combining that along with a WASM target I actually feel super bright about the future of Flutter as a tech choice on web, desktop, mobile etc…
They have some more detail about both of these things in their Roadmap [2] if you’re interested.
[1] https://github.com/flutter/impeller
[2] https://github.com/flutter/flutter/wiki/Roadmap
Dart is a relatively simple language and you'll get the hang of it quite quickly.
The widget-tree framework of flutter makes it easy for you to just have small amounts of code that all chain together, and it becomes easier to find your mistakes and grow your platform.
I recommend going for it if you have an interest.
Dart is single threaded, but the event loop is better than threads for most things, except heavy calculations, but that's what isolates are for. This is probably the best way to do it even in C when latency is important. CPU schedulers tend to leave you with less control over latency when there is underutilization or yielding.
When I tried it a couple of weeks ago on an old Android device (Pixel 3A) there was a little jank. Then I tried a couple apps bundled with Android and was surprised to find a comparable amount of jank.
I've heard it's worse on iOS though.
I had also higher expectation regarding Dart FFI - I think with their ffigen we are still only in ctypes like python bindings territory. Nowhere near something like pybind11 [0] for c++ bindings yet.
[0] https://github.com/pybind/pybind11
[1] https://github.com/mozilla/uniffi-rs
Expo has been making unbelievably rapid progress with tooling, documentation, consistent, high quality API's and general improvements. Evan Bacon + team are really impressive to watch
1) Need mostly cross platform desktop and using hardware extensively (bluetooth, camera, audio, nfc, sensors, etc.) -> Qt
2) Have web expertise or need easily to find well paid job and need mostly web, android, ios app -> React Native
3) Need only iOS, Android app that is mostly custom UI with some smooth animation mostly for some side project (not many jobs in the market comparing to React Native or iOS/Android Native) -> Flutter
https://github.com/dart-lang/language/issues/783
Just to give you example In many ways I prefer Ruby than Python as a language but Python is just swiss army knife and in many cases you are one PIP install away to finding library that solves your problem. Maybe Python doesn't have such a nice web framework as Ruby on Rails but ruby is not much used elsewhere.
I think people complaining about Dart as a chosen language not because of it's features but because
1) you have to learn and/or redevelop new SDK for it,
2) language doesn't have good interrop with any other languages (like Kotlin -> Java, Swift -> Objective-C, TypeScript -> JavaScript, Objective-C -> C++, Rust -> C, C++ -> C)
3) ecosystem is small