The good, the bad and the ugly of GetX29 Mar 2024
The inspirtation for this article came from a tweet I saw on Twitter.
GetX is the most popular package. For a reason. I know getX is not liked but it doesn't matter. You SHOULD use GetX is YOU like it. You SHOULD use whatever YOU want in YOUR code. You're working in that code all day. Not the people telling you your toolset is "wrong"
I partially agree to it. It's totally dev's opinion on what state management should be used.
Click to view image in full screen
But is it the best thing that has happened to Flutter? I don't think so. In this article, I will be discussing the good, the bad and the ugly of GetX.
The Good
It's no brainer. GetX is super beginner friendly. That's why I've seen so many people using it. Most of the candidates who I've interviewed for Flutter roles have used GetX.
Simpicity is the key. GetX is super simple to use. You can use it for state management, navigation, dependency injection and many more. It's a one stop solution for all your needs. Let's compare few lines of code between Flutter and GetX.
Navigation:
// Out of solution provided by Flutter
Navigator.push(
context,
MaterialPageRoute(builder: (context) => const SomePage()),
);
// Using GetX
Get.to(SomePage());
As we can see it removes the boilerplate code that we have to write in Flutter and abstracts it in a simple method.
State Management:
Provider vs GetX since both are considered as beginner friendly.
// Provider
// Create a class and extends ChangeNotifier
class Counter with ChangeNotifier {
int _count = 0;
int get count => _count;
void increment() {
_count++;
notifyListeners();
}
}
// In Build Method
Consumer<Counter>(
builder: (context, counter, child) {
return Text("${counter.count}");
},
)
// GetX
// Create a class and extends GetxController
class Counter extends GetxController {
int counter = 0;
void increment() {
counter++;
update(); // use update() to update counter variable on UI when increment be called
}
}
// In Build Method
GetBuilder<Counter>(
init: Counter(), // INIT IT ONLY THE FIRST TIME
builder: (_) => Text(
"${_.counter}",
),
)
They also have a ton of other util methods that we can use, I'm not going to cover them in this article. But you get the idea, right? As a beginner, you can easily understand the code and start using it. It abstracts a lot of boilerplate code and complicated concepts that we come across in Flutter. This is the "good" part of GetX.
The Bad
As a Flutter dev, it's imperative to know how things work under the hood. It's not just about using the framework, it's about understanding the framework. GetX abstracts a lot of things. It's good for beginners but not for advanced developers. It's like a black box. You don't know what's happening inside. You just use it.
For example, if you take a simple navigation, you can see it abstracts BuildContext. A core concept which every Flutter dev should know. Not only it abstracts context while routing, but also while using snackbars, dialogs and many more. it's almost like you are coding in a different language.
This BuildContext is just a one example. We know Getx provides a lot of functionalities. Navigation, State Management, Dependency Injection, etc. It's like using a hammer for everything.
GetX has it's own way of doing things which deviates from how Flutter does things. It has became a meta-framework. It's a framework on top of a framework.
A tweet from Alessio Salvadorini sums it up perfectly.
It depends how you define 'bad'. It's easy, and in being easy it's wrong, disrespectful of the framework (Flutter). So you'll end up learning GetX and not learning Flutter. πππ x.com/ASalvadorini/sβ¦
... and our beloved Filip too, now that he can share his personal opinion! πππ Don't use GetX
The Ugly
The Ugly part of GetX comes from how it divided the Flutter community. Even people from Flutter's core team has voiced out on why GetX is not recommeded.
Check out this tweet from Filip HrΓ‘Δek.
I avoided saying anything about GetX while I was employed at Google because I didn't want my personal opinion confused with official stance. Now that I've quit: I don't like GetX. * It hides complexity. * Magic everywhere. * Not thought thru. Scott explains it more eloquently.
I've tried really hard to stay away from the whole subject of GetX for a lot of reasons, but one came up recently that I feel I have to mention. I'll try to say it as objectively as possible.
Also check out the thread which Filip has mentioned in the tweet. Check out the replies in which Scott goes in depth on why GetX is not recommended, especially for beginners.
I've tried really hard to stay away from the whole subject of GetX for a lot of reasons, but one came up recently that I feel I have to mention. I'll try to say it as objectively as possible.
Conclusion
As I said before, using a state management solution is totally dev's opinion. It's upto you to decide what to use. But as a Flutter dev, it's important to know how things work under the hood. If you are a beginner, don't use GetX only because it's easy to learn. Learn the basics of Flutter first. Understand how things work. Then you can start using GetX, if needed.
< Back