Beyond the Hype: The Untold Truth About GetX and Its Downsides for Flutter Development
What You Need to Know Before Choosing GetX for Your Next Flutter Project
in this article, I’ll be sharing some insights into the challenges you may encounter when using GetX for Flutter development, Our purpose is just to identify some of the challenges with GetX and how that might affect your Flutter apps.
If you’d like a quick and easy explanation, watch this video:
let’s start with the first disadvantage is,
Getx Provide Simplicity
The simplicity of GetX’s access approach is appreciated, but it comes at the expense of understanding important topics. There are significant differences between using GetX and using pure Flutter when it comes to managing routing, for instance,
similarly, this is how you change theme and flutter versus,
how it’s done in GetX the code is simple but it’s eliminating the usage of BuildContext arguably the most important concept in Flutter there’s magic all around there are many beginner Flutter developers who use GetX they think they don’t have to deal with build context and will be able to build and ship apps faster.
they avoid many important topics that a Flutter developer should know. For example, many users switched to GetX because they didn’t have to worry about build context when using GetX, whether it was while navigation, changing themes, managing the state, or showing alert dialogues or snack bars. It is easy to use because developers can do whatever they want from wherever they are.
but this comes at the cost of knowing more about important topics if a GetX developer starts working on a real-life project that doesn’t use GetX they’ll be confused about what’s happening this brings me to the second disadvantage which is,
GetX force to replacing Flutter
When GetX is added to a Flutter project, many of its components are replaced, including the material router. As a result of this replacement, if the Flutter team updates some properties in the material router, GetX might take a while to incorporate the changes due to the need to completely rewrite the Get material router.
another example is when the snack bar is displayed it neither has a material design nor Cupertino Design This is a point of the third disadvantage which is,
GetX tends to use anti-patterns
as already mentioned it neither follows material design nor Cupertino design when displaying the snack bar it also violates the unidirectional data flow principle which means that the data will flow in only one way when being transferred to different parts of the app to put it more simply for developers.
its have a higher probability of going against architectural patterns like MVC and MVVM when using get X using GetX promoter principles might be easier and will work fine in the beginning but remember the quote from the clean code book,
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
so if you continue to use their decks you need to continuously ensure that you’re following the right principles when using it it’s quite easy to go off track because of the solution it provides let’s shift to the fourth disadvantage
GetX tries to do everything
Management of state is just one aspect of a Flutter app, which also includes routing, dependencies, validation, internationalization, storage, theming, etc. While relying on a single plugin like GetX for all these tasks might seem convenient, it’s worth noting that it’s often developed by an individual developer or a small community without corporate backing or funding. If the developer can no longer maintain the plugin and no one takes over, its users might encounter compatibility issues as Flutter evolves and introduces new features or removes existing ones. Thus, relying on a single package can be risky. the fifth disadvantage and probably the biggest one is that
The level of documentation for GetX needs improvement.
According to pub.dev 753 out of 2138 which is 35.1 percent of the total API elements have documentation comments
to give you perspective bloc has 94.2 riverpod 93.1 and provider a 87.7 percent it’s unfair to compare GetX with State Management tools because GetX is more than just a state management tool however the point is that documenting the code is quite important for packages there are many hidden features as a result of lack of documentation the code base is Big with many classes variables methods not having comments these things matter because it’s quite difficult for a new developer to contribute to this package if these things are absent this is probably why most of the commits to the GetX package are by the author himself
this is not a good indication because bringing new changes to this package gets slower when the majority of the work is done by just one person the situation gets a lot more serious when we associate the points already discussed this package has many features and it replaces many flutter components every time some property is added or deleted by flutter team in some component there’s a possibility of GetX either breaking the code or not being compatible with the flutter version this can be fixed but only one person doing it slows down the process and might affect production ready apps a lot the last disadvantage point is that,
The Unusual Number of API Elements in GetX
if you only want a state management portion of GetX you will still get all of the extra functions and utilities get X has in comparison to GetX 2153 API elements riverpod has 726, provider 204, and bloc 155, it’s quite strange for a package to have so many API elements.
so in conclusion, whether or not to use GetX ultimately depends on your specific project requirements. While every package has its own set of advantages and disadvantages, GetX has a lot of beneficial features that make it a popular choice among developers. Its state management system, dependency injection, routing capabilities, reactive programming, and developer tools are all highly regarded and can help make your app development process more efficient and streamlined. However, it’s important to evaluate your needs and determine if GetX aligns with your project goals before deciding to incorporate it into your codebase, also all the information I took it from many websites as some research if you find any wrong info or misdirected, please point out or comment below.
If you got something wrong? Mention it in the comments. I would love to improve. your support means a lot to me! If you enjoy the content, I’d be grateful if you could consider subscribing to my YouTube channel as well.
I am Shirsh Shukla, a creative Developer, and a Technology lover. You can find me on LinkedIn or maybe follow me on Twitter or just walk over my portfolio for more details. And of course, you can follow me on GitHub as well.
Have a nice day!🙂
