Easy-peasy: What are downsides of easy-peasy?

Created on 7 Apr 2020 · 6Comments · Source: ctrlplusb/easy-peasy

This library is lightweight and has less APIs and still manages to get the job done amazingly

_Just wondering what tradeoffs you made while developing this library_
Similar to https://github.com/preactjs/preact/issues/2199

Also thanks for this amazing library 🎉❤️

docs question 🧡help wanted 🧡

Source

nainardev

👍5

Most helpful comment

Hey @nainardev 👋

I'm glad to see you are taking such a keen interest in this library.

That's a great question, and I will try to answer it as honestly as I can. I may be blinded by my own bias so I welcome any other feedback from others to add to the list.

Ok, so the downsides, in a list form:

We are built on top of Redux. There are certainly trade offs that have been made here. We are bound to the API and capabilities of Redux under the hood. Redux is a very popular solution though and has been battle tested over many years, so I thought it was a fair trade to make. It allowed me to support a greater set of the tools / features that the Redux community have built, such as the Redux dev tools. It also saved me from having to write and learn all the hard lessons that were learnt during the development of Redux. We have a reliable engine.
Another point on being built on top of Redux. Whilst we abstract away Redux, the abstraction is leaky. There are many places you can observe, in terms of the design of our API, that knowledge of Redux would certainly help you have an even stronger understanding of how the library works. We've also specifically exposed the ability to extend the underlying Redux store, which is an even bigger leak. 😅Again, I felt like the benefits outweighed the trade offs, and by introducing some Redux specific APIs (like the reducer), and exposing the store, we have been given the ability to introduce a migration path for those whom are currently on a traditional Redux implementation.
It's not an official state management solution. You are introducing a 3rd party dependency into your application. That is always a risk. Apart from the possibility from it falling out of maintenance there is also the possibility it may not evolve with the architecture of React as it is based on assumptions about the current implementation of React. For example, there could be issues with the upcoming concurrent mode feature of React. This is a general issue for a lot of global state libraries though however, and the React team is introducing a useMutableSource hook which should allow this library and others to evolve into their next architecture model. So it's low risk for now, but I think it's a good example of the type of thing that could occur.
Increased bundle size. By adopting this library you no doubt will bump the size of your bundle. If you are serving communities with really slow internet speeds this should always be a consideration. Easy Peasy bundled with all it's deps is about 11kb gzipped right now. The next 3.4.0 version will likely be around the 9kb mark. Not crazy big, but still good to consider based on your needs.
You would also increase the learning curve for new developers to your application. Whilst we are certainly growing in adoption I think it is safe to say this is not Redux/MobX level in terms of popularity. So there will be a learning curve. That being said, a primary goal of this library was to create an API that is intuitive and easy, so hopefully the impact would be negligible.

That's all I can think of for now. The last few points are true for almost any lib, but I think it's always worth reiterating those. I'll add more as and when I think of them.

ctrlplusb on 12 Apr 2020

👍12 ❤9 🎉3 🚀2

All 6 comments

Hey @nainardev 👋

I'm glad to see you are taking such a keen interest in this library.

That's a great question, and I will try to answer it as honestly as I can. I may be blinded by my own bias so I welcome any other feedback from others to add to the list.

Ok, so the downsides, in a list form:

We are built on top of Redux. There are certainly trade offs that have been made here. We are bound to the API and capabilities of Redux under the hood. Redux is a very popular solution though and has been battle tested over many years, so I thought it was a fair trade to make. It allowed me to support a greater set of the tools / features that the Redux community have built, such as the Redux dev tools. It also saved me from having to write and learn all the hard lessons that were learnt during the development of Redux. We have a reliable engine.
Another point on being built on top of Redux. Whilst we abstract away Redux, the abstraction is leaky. There are many places you can observe, in terms of the design of our API, that knowledge of Redux would certainly help you have an even stronger understanding of how the library works. We've also specifically exposed the ability to extend the underlying Redux store, which is an even bigger leak. 😅Again, I felt like the benefits outweighed the trade offs, and by introducing some Redux specific APIs (like the reducer), and exposing the store, we have been given the ability to introduce a migration path for those whom are currently on a traditional Redux implementation.
It's not an official state management solution. You are introducing a 3rd party dependency into your application. That is always a risk. Apart from the possibility from it falling out of maintenance there is also the possibility it may not evolve with the architecture of React as it is based on assumptions about the current implementation of React. For example, there could be issues with the upcoming concurrent mode feature of React. This is a general issue for a lot of global state libraries though however, and the React team is introducing a useMutableSource hook which should allow this library and others to evolve into their next architecture model. So it's low risk for now, but I think it's a good example of the type of thing that could occur.
Increased bundle size. By adopting this library you no doubt will bump the size of your bundle. If you are serving communities with really slow internet speeds this should always be a consideration. Easy Peasy bundled with all it's deps is about 11kb gzipped right now. The next 3.4.0 version will likely be around the 9kb mark. Not crazy big, but still good to consider based on your needs.
You would also increase the learning curve for new developers to your application. Whilst we are certainly growing in adoption I think it is safe to say this is not Redux/MobX level in terms of popularity. So there will be a learning curve. That being said, a primary goal of this library was to create an API that is intuitive and easy, so hopefully the impact would be negligible.

That's all I can think of for now. The last few points are true for almost any lib, but I think it's always worth reiterating those. I'll add more as and when I think of them.

ctrlplusb on 12 Apr 2020

👍12 ❤9 🎉3 🚀2

Ok, no problem.

ctrlplusb on 12 Apr 2020

Just want to say I've had a much better time developing with this than MobX or Redux. This is an excellent piece of work.