I have been using GetX for a week so far. I have not found any error at all. Obx is amazing. Its builder is wrapped into it. It is more of a listener. Was thinking of using hooks but hooks is not compatible wity GetX. That is one issue. I feel like GetX is still growing. All it needs is a supportive community and soon Bloc will be second best. Lol
Great detailed analysis! In Russian community segment, they organized debates about GetX. People talked about it for 2 hours and didn't say anything helpful or worthy. You put in 20 minutes video more useful information. Thoughts: 1:50 - it's not similar to Provider (it doesn't use context lookup), but it's a clone of get_it package (service locator). It's not a singleton as it still allows providing abstractions: Get.put(Cat()) 4:30 - looks like you didn't found the documentation, it's hidden well in the repository "documentation" folder. It explains many things. An author decided not to document the API but to describe it in the .md files in his repository. 7:30 - it's an old way of creating controllers. GetX provides Bindings, allowing you to bind your controllers to routes (with autodispose on route close) 8:35 - you should use you should use Get.put, not Get.create, and GetView, not GetWidget, to lookup the registered instance. Get.create / GetWidget are used in pair only for list entry controllers. 20:00 - wow, you found my issue :)
@@flutter--help8127 the biggest pain of GetX that it still doesn't support Navigator 2.0. He has only small example with strange RouterOutlet and rootDelegate things. And it isn't documented at all. He promised to write a manual since last summer and still didn't. That's the main reason why I left GetX.
I never liked Getx just because it tries to do so much for no good reason. And never did I feel comfortable using it. This plugin is trying to redefine Flutter and doing a very bad job at it.
thank you for the useful and detailed analysis of this package, I want to convince our manager not to use GetX, since he believes that GetX is very easy to use, but practice shows that this ease will be followed by big problems that will be very difficult to get rid of
I'm in the middle of a very complex app using GetX for state management and dependency injection. I'm contemplating moving to riverpod but get his does what I want it to do with less code. I only compile those two functionalities therefore no problems with the size. What I like most about GetX is, the fact that I'm able to create and manage Animation Controllers within the View Controllers. That is much easier than Hooks or any other solution. Another thing I like about it is how it enable you to create and work with View Controllers. Regardless the use of GetX when using for state management and dependency injection is so minimal it should be easy to replace it with another framework.
Is it performant as it claims? It seems to make some aspect of Flutter very easy to work with. It is true that the documentation is lacking but it has original translation for many languages that might be more useful for somebody.
I did not do any of my own research but found a couple strange github threads. github.com/jonataslaw/getx/issues/789 github.com/jonataslaw/getx/issues/243 I think there's a big difference between EASIER and BETTER. It's true GetX gets people up and going almost instantly and is incredibly easy to start off with. But after doing some digging through issues and reddit I've found several posts now where devs with a large and complex app are finding it become spaghetti code or even running into gotcha's with GetX, completely blocking them.
Really great video. Helped me a lot. I've been using Flutter for 3 years now and just had a brush with GetX. Can you explain to me who uses GetX and why? I suspect it's people who started with GetX and never worked with straight Flutter. I can't imagine anyone working with Flutter for a couple years and then going to GetX. Is that accurate or am I missing something?
I started flutter without any state management package. Used setState() everywhere. But eventually my code got messy, and often I get loss in a big project. Then I saw getx, use it, and find my code cleaner than ever. So yeah you're missing a lot of things, not about getx but about different people's different comfort zone. Although I agree it's all-in-one package, and it may be consuming too much memory, but I am not interested in going back to those old days. If there is something lightweight then getx and makes my code organize, then I will consider switching.
Your comparison with others is not fair. GetX does more than 10 things, and you're comparing it with Riverpod, Provider, BLoC that so only state management ! You should only compare them with only GetX state management.
I dont understand though, most issues i've see is the dialogs/some UI element. So if you dont use the built in dialogs, you can still use the default way where you fully code up a dialog. So why is that so bad compared, to the normal way? I've always felt this unsettling feeling that getx is bad, but I cant really justify it because it allows me to build up the app fast and most issues I've faced usually result in a quick search to get a solution. I believe there are.quite a large base of ppl using, therefore there are many "solutions"
Or maybe there are few questions, because few applications use it? many serious companies use REDUX. and secondly, the most important thing in GetX is little code, really little, for me personally this is the most important thing
@@rudiansyahalpontianaky8356 in brief, GetX lacks of Actions, Computed (which present in MobX), has numerous bugs (`append` in StateMixin does not work at all, dialogs are buggy). Translations are based on outdated `easy_localization`. `slang` is much better. `update()`-notifications are based on some "mini-streams" which are 3.5x times slower than standard `notifyListeners` (proven by independent testers). And the main problem, it does not support Navigation 2.0 (more than a year passed since then!). Also, it looks abandoned by its creator (600+ issues which likely won't be resolved). GetX tried to be all-purpose sole package, and does it bad.
@@sergey_molchanovsky where i can get detail of reviewing like this and more things in getx maybe article or else ? i want to see result test of observable . obs too,and else ?
Indeed, this is a consequence of showing dialogs and snack bars without a build context. A build context describes a widgets existence and without it they cannot react to the GetX snack bar. GetX snack bars and dialogs are effectively hacked+stacked on to the screen due to the lack of build context.
people who use provider are college students who are forced to use it because their professors asked it as a requirement.. companies wants native and real programmers use getx for their clients project but told peers they use bloc or riverpod ^^
GetX is the perfect example of "why you shouldn't try to do everything at once " .
but isn't that flutter do?
I have been using GetX for a week so far. I have not found any error at all. Obx is amazing. Its builder is wrapped into it. It is more of a listener. Was thinking of using hooks but hooks is not compatible wity GetX. That is one issue. I feel like GetX is still growing. All it needs is a supportive community and soon Bloc will be second best. Lol
y
Great detailed analysis! In Russian community segment, they organized debates about GetX. People talked about it for 2 hours and didn't say anything helpful or worthy. You put in 20 minutes video more useful information.
Thoughts:
1:50 - it's not similar to Provider (it doesn't use context lookup), but it's a clone of get_it package (service locator). It's not a singleton as it still allows providing abstractions:
Get.put(Cat())
4:30 - looks like you didn't found the documentation, it's hidden well in the repository "documentation" folder. It explains many things. An author decided not to document the API but to describe it in the .md files in his repository.
7:30 - it's an old way of creating controllers. GetX provides Bindings, allowing you to bind your controllers to routes (with autodispose on route close)
8:35 - you should use you should use Get.put, not Get.create, and GetView, not GetWidget, to lookup the registered instance. Get.create / GetWidget are used in pair only for list entry controllers.
20:00 - wow, you found my issue :)
Oh man it's been since December 2021 and that PR still isn't merged! Brutal
@@flutter--help8127 the biggest pain of GetX that it still doesn't support Navigator 2.0. He has only small example with strange RouterOutlet and rootDelegate things. And it isn't documented at all. He promised to write a manual since last summer and still didn't.
That's the main reason why I left GetX.
@@sergey_molchanovsky what about now ?
I never liked Getx just because it tries to do so much for no good reason. And never did I feel comfortable using it. This plugin is trying to redefine Flutter and doing a very bad job at it.
thank you for the useful and detailed analysis of this package, I want to convince our manager not to use GetX, since he believes that GetX is very easy to use, but practice shows that this ease will be followed by big problems that will be very difficult to get rid of
I'm in the middle of a very complex app using GetX for state management and dependency injection. I'm contemplating moving to riverpod but get his does what I want it to do with less code. I only compile those two functionalities therefore no problems with the size.
What I like most about GetX is, the fact that I'm able to create and manage Animation Controllers within the View Controllers. That is much easier than Hooks or any other solution. Another thing I like about it is how it enable you to create and work with View Controllers.
Regardless the use of GetX when using for state management and dependency injection is so minimal it should be easy to replace it with another framework.
Getx is best. don't listen these dumb people.
Is it performant as it claims? It seems to make some aspect of Flutter very easy to work with. It is true that the documentation is lacking but it has original translation for many languages that might be more useful for somebody.
I did not do any of my own research but found a couple strange github threads.
github.com/jonataslaw/getx/issues/789
github.com/jonataslaw/getx/issues/243
I think there's a big difference between EASIER and BETTER. It's true GetX gets people up and going almost instantly and is incredibly easy to start off with. But after doing some digging through issues and reddit I've found several posts now where devs with a large and complex app are finding it become spaghetti code or even running into gotcha's with GetX, completely blocking them.
Unfortunately no.
There are some tests, showing GetX custom realization of notifiers are x3.5 times slower, than Flutter built-in notifiers.
Really great video. Helped me a lot. I've been using Flutter for 3 years now and just had a brush with GetX. Can you explain to me who uses GetX and why? I suspect it's people who started with GetX and never worked with straight Flutter. I can't imagine anyone working with Flutter for a couple years and then going to GetX. Is that accurate or am I missing something?
I started flutter without any state management package. Used setState() everywhere. But eventually my code got messy, and often I get loss in a big project. Then I saw getx, use it, and find my code cleaner than ever. So yeah you're missing a lot of things, not about getx but about different people's different comfort zone. Although I agree it's all-in-one package, and it may be consuming too much memory, but I am not interested in going back to those old days. If there is something lightweight then getx and makes my code organize, then I will consider switching.
@@glitchlover260 have you tried Riverpod v2.0 ?
I was learn and use setState, after that provider, last project using GetX its ok
Great video!!! Thank you very much.
excellent reviews thanks!
I'm a getx girl here but i find this discussion to be interesting.
Your comparison with others is not fair. GetX does more than 10 things, and you're comparing it with Riverpod, Provider, BLoC that so only state management ! You should only compare them with only GetX state management.
That's exactly another problem with it. It's trying to take over Flutter essentially
@@k4ba has Laravel taken over PHP ? It's there to simplify the work. That's the same thing with GetX : simplification !
@@francisndubanumbi648 preach brother preach
stop complaining if you think lack of documentation go and help them to create proper documentation
This is an analysis video... don't get mad buddy.
But yeah, basically... screw GetX
I dont understand though, most issues i've see is the dialogs/some UI element. So if you dont use the built in dialogs, you can still use the default way where you fully code up a dialog. So why is that so bad compared, to the normal way? I've always felt this unsettling feeling that getx is bad, but I cant really justify it because it allows me to build up the app fast and most issues I've faced usually result in a quick search to get a solution. I believe there are.quite a large base of ppl using, therefore there are many "solutions"
Or maybe there are few questions, because few applications use it? many serious companies use REDUX.
and secondly, the most important thing in GetX is little code, really little, for me personally this is the most important thing
I though big companies use Bloc
Getx for me is a new framework on top of flutter
Getx makes your life simpler.. some developers dont like peace .. they like problem .. only such people use bloc 🤣🤣
Use mobx + get_it + auto_route + slang - and you will have the same instruments as getx, but better, stable and without performance issues.
@@sergey_molchanovsky can i get what's the issues on getx ?
@@rudiansyahalpontianaky8356 in brief, GetX lacks of Actions, Computed (which present in MobX), has numerous bugs (`append` in StateMixin does not work at all, dialogs are buggy). Translations are based on outdated `easy_localization`. `slang` is much better. `update()`-notifications are based on some "mini-streams" which are 3.5x times slower than standard `notifyListeners` (proven by independent testers). And the main problem, it does not support Navigation 2.0 (more than a year passed since then!). Also, it looks abandoned by its creator (600+ issues which likely won't be resolved).
GetX tried to be all-purpose sole package, and does it bad.
@@sergey_molchanovsky where i can get detail of reviewing like this and more things in getx maybe article or else ? i want to see result test of observable . obs too,and else ?
@@rudiansyahalpontianaky8356 don't spend your time, bro. GetX is a pure garbage.
Considering Performance and resource consumption, can I use Getx for quite a large apps or not??
You are using it the wrong way, don’t even try if you don’t want to learn how to use it…
Make Video On Riperpod😎✌️
Gets Worst
Wait... the snackbar doesn't push up the FAB using a Scaffold with GetX?! LOL
Indeed, this is a consequence of showing dialogs and snack bars without a build context. A build context describes a widgets existence and without it they cannot react to the GetX snack bar.
GetX snack bars and dialogs are effectively hacked+stacked on to the screen due to the lack of build context.
People who Support Getx is Noob🤣
That's not cool man
people who use provider are college students who are forced to use it because their professors asked it as a requirement.. companies wants native and real programmers use getx for their clients project but told peers they use bloc or riverpod ^^
This guy has no clue of what he's talking 🤣🤣 its sure that hez a noob
@@subrotoxing8214 accurate xD