Moving away from Zustand

When I started this project, I wanted to throw a lot of new tech at it that I had yet to try my hand at. For state management, I am very comfortable with redux toolkit, so I forced myself into giving zustand a try, just so that I could check that box off my list.

Starting out, I was quite pleased with its interface. It was easy to use, required no boilerplate setup and seemed to cover all my technical needs as the app was still in its very early stages of development. After spending some time with it however, it started to dawn upon me that zustand is just not extensible enough for an app to scale properly. For new developers that are just starting out with state management, I can see the appeal of zustand as it avoids a lot of the up-front complexities that come with redux. The second you need to extend zustand beyond its very basic demoed functionality, you will quickly discover that it wasn't so easy after all. Just take a look at the zustand typescript guide guide for yourself.

I should probably cut zustand some slack though. Comparing it to redux is like comparing a bicycle to a truck. They will both get you from A to B, but they are not designed to handle the same type of challenges to begin with. Redux is a much more feature-rich library that does not only aim at managing state alone, but also gives you the tools to create a whole application around it that scales well and is highly flexible. Some of the things that come with redux can feel a little bit bloated, but when having to spend energy on sifting through an ocean of npm packages, learning how to integrate them with zustand through countless GitHub and StackOverflow discussions and ironically having to write more boilerplate code than what was promised on the label, you get a sense of appreciation for how this has been tailored into the redux experience.

I created a table of reference that lists the availability of features in both libraries to highlight this.