jonataslaw / getx

Open screens/snackbars/dialogs/bottomSheets without context, manage states and inject dependencies easily with Get.
MIT License
10.33k stars 1.62k forks source link

QUESTION: Is getx good for production app? #2631

Closed Helocominc closed 1 year ago

Helocominc commented 1 year ago

Thanks @jasonlaw for this great package.

I use getx to build apps for learning purposes and tutorials and it's really nice.

I want to build a big app for production. Unfortunately, I have been seeing so many people talking bad and giving poor reviews about getx, saying it's bad for production apps and not recommended for use. I would like to confirm this from the owner to know if getx is good for heavy apps? Is it good to use in building production apps?.

Mohdx commented 1 year ago

No. Use flutter_bloc or simply provider

Helocominc commented 1 year ago

No. Use flutter_bloc or simply provider

Can you give a reason?

Mohdx commented 1 year ago

Can you give a reason?

GetX is easy to use for your hello world application, that's why it has a lot of likes! When your app grows and gets more complicated and needs caching etc. GetX lead to bad performance and implementations (your app literally will become slow).

GetX is not a state management, more like a complete library for everything, almost copy past from all libraries on pub.dev (that you won't even need to use), copied to GetX without giving credit to people who implemented these libraries.

It has some flaws in architecture decisions and if you read, "use something without context" is always a RED flag. 🚩

Evgentret commented 1 year ago

Thanks @jasonlaw for this great package.

I use getx to build apps for learning purposes and tutorials and it's really nice.

I want to build a big app for production. Unfortunately, I have been seeing so many people talking bad and giving poor reviews about getx, saying it's bad for production apps and not recommended for use. I would like to confirm this from the owner to know if getx is good for heavy apps? Is it good to use in building production apps?.

GetX is production ready. Performance of 4.6.5 is great (5.0.0 not tested yet). I'm using it on big apps with a lot of screens and it works stable. GetX has no side dependencies. You can use it on any complicated app, don't listen those who even don't trying it except hello_world project. No slowdowns on big applications. GetX is perfect state management, and it also can do many things. But this fact, that GetX also router and translation manager is not canceled the state management feature. So, don't react on somethings emotions.

Also, if you hear from some semi-literate persons who mix a lot of terms in one muddy stream of consciousness, that "something without context is bad" - okay, the Flutter itself let you navigate without context easily through GlobalKey. This is not mystical "something", this is one of correct way to navigate. If you don't want to use such type of navigation - ok, you can use GetX only as a state management. Why not? But architecture of common GetX target app is implies bindings, so why do you should use context in that way? It's only architecture question.

jonataslaw commented 1 year ago

GetX is used in a multitude of production applications around the world. Usually people talk bad to get relevance or likes (since talking bad about what people use will generate more likes or clickbaits), but you can enter the profile of these people who surely don't work in the area (or if they do, they are involved in other state management projects).

About using context or not, this is an architectural question. With Navigator1 you could navigate without context using a globalKey. Using the Navigator2, as long as you get access to your delegate, you can access navigation from anywhere.

If you're worried about performance I'd say you shouldn't, if you're worried about architecture, study architecture, you should be able to use any package without coupling using clean architecture, and the GetX Pattern gives a good idea for anyone who wants to use a common architecture.