This is wicked, somehow very similar to zustand but yet seems even simpler indeed. Would be nice to see how types work on typescript and how more complex state works too, for instance if you have several variables and a few set/get functions like the usual zustand drill.
That's great to hear! Prop drilling can definitely be a nightmare lol, it's so easy to lose track of things once your app gets the slightest bit complex
Nano store is awesome as well.. it's small reactive and works with react, solid ,native js or any famous framework. Great fit for. Small to medium size projects. If you use nano store with Astrojs the store you can be shared between frameworks.. you can make a change in solid component and react component will re-render if needed
Congrats. You now made your app infinitely harder to test and debug. Global State is a problem. In fact, it was such a big problem a whole programming paradigm was created to address it.
great video! I like that you get to the point! I tried to like zustand but it felt weird and cumbersome however jotai seems like a way better fit for me!
Big agree! They both provide a ton of value, and you could actually use them together if you wanted to. In Jotai's docs there's a guide on how to hook it up with Zustand
@@viktor_zhurbin but these libraries were created by a single person and he is called Daishi Kato. He even created a third library called Valtio. So Zustand, Jotai and Valtio were all created by the same person. All are state management libraries, but built on different principles.
React devs have forgotten the best state management library of them all, the U R L. I love this library, however I only use it in cases where I don't want to expose state to the user like setting a navbar's sticky state. Everything else goes into the URL bar in our projects.
I do think storing state in the URL is something people completely forget about and don't utilize as much as they could. However, some might say that even with a routing library, the URL still exists outside of the React ecosystem/lifecycle since it's part of the browser, making it less pure React, as opposed to something like Jotai that is 100% tied to the React DOM. This definitely can have upsides though depending how you look at it. Ultimately I think it is best to choose what works best for you :)
That's a great point! I haven't used Zustand a ton yet (still testing it out) but in my opinion Zustand would likely be a better choice if your app is highly complex. Not quite as cut and dry as Jotai, but it has the capability to do more. After all both Jotai and Zustand are made by the same person, for that exact reason
That's a great question. React does technically have support for global state, using contexts. You can wrap your app (or subtree of the app) in a context provider, and then React components within that subtree can access the state. The problem is, if you state gets a bit more complicated or needs to not be so rigid, contexts are not always the best solution. You end up having to wrap your App with multiple, sometimes dozens (yes I've actually seen this) of context providers, and it can get really messy and hard to track. The reason for libraries like Jotai, Zustand, Redux, etc, popping up is to try and offer a better and more flexible way to manage global state. It's a bit unfortunate that so many libraries exist because it complicates things. It's also worth mentioning that React is a library while Svelte is a framework. React is great at doing what React does, but it stays pretty unopinionated about things like global state management and routing, whereas vanilla Svelte is a bit wider than vanilla React. I think both cases are good in their own way, part of what makes React good is that since it stays unopinionated, it meshes well with almost any library and is super flexible!
@@AustinDavisTech "part of what makes React good is that since it stays unopinionated, it meshes well with almost any library" is that really true though? with svelte, I can use vanilla js libraries directly without having to write wrappers. and svelte isn't built on a vdom, so i can access the dom directly
@@anxpara Whether it is true or not, it depends on the person. I personally like having multiple choices on what technology stack I want to use for development. For example in many frameworks everything you need to develop an app is pretty much included. In React you might have to decide between Tanstack Query vs RTK Query vs SWR, for remote state, and what it is good for is that imo it pushes the industry forward with people always trying an improving on certain libraries. Like when context and redux were pretty much the only tools used for state management, pretty much everyone agreed that to manage state in react was a pain in the ass, specially classic redux. Now you have many options to choose from. Its true its hard to keep up with all of them, but I personally just find it better than just using a framework. But I feel like it is personal preference at the end of the day. Many people like full fledged frameworks a lot more. Pros and Cons to both
Jotai seems really easy to use, with absolutely no boilerplate. But i do not think it will scale well in more complex applications. Zustand will be a better fit in that case. Great video BTW
@@darthvader4899 My previous comment was based solely on what was shown in the video (this was my first time seeing the library). So, thinking of integrating it with some complex apps I've worked with, scalability seemed problematic. But going through its docs, my opinion of Jotai has changed. I believe its atom-based architecture allows for an application to be highly modular, consequently improving its scalability.
I agree, a while back I cross shopped jotai v zustand v redux toolkit and of the 3 zustand seemed to be the most flexible. Zustand can be nearly as atomic as jotai, but then built out to be as complex as redux. Zustand has the concept of a store, which helps organize global state into an obvious spot. I was concerned with jotai not having an organizing principle. For truly app wide global state, we use react context. That handles things such as app theme, app authority etc. Other than that, we don't have a need for truly app wide global state. We use zustand for global module/feature level state. Zustand allows module state to be as simple, or complex as that feature requires.
I get your point, and I think a lot of people would probably agree with you about Zustand. However I do think you may be underestimating Jotai a bit, as I have seen it scale very well so long as it's handled responsibly. Two solutions that are created by the same person and great in their own ways!
@@BoonBoonitube Im not really sure but imho better to use zustand for app wide state because of not requiring context provider, thus it will only trigger re-render on component that use that specific state. afaik the cons of using context is that triggers rerender to the providers children
It's global state by default unless you scope it then it only exists within its own scope (similar to how regular variables are scoped). Vanilla Jotai doesn't have thunk functionality like Redux, but that's also part of the beauty as to how simple it is
Jotai seems very easy to use, with not much of a setup. But having a bunch of global states worries me for the performance. Personally, I like useImmer and useImmerReducer. I don't mind setting up the reducer function once, and Immer helps with the immutability problem that native reducer had.
This really looks fantastic! But... 1. Maintenance may end up becoming a nightmare in large scale production apps - especially in companies where PR reviews are not done "properly". 😉 2. I am curious what the performance is like in medium and large scale apps. 🤔 Thank you making this video though. Best thing I learnt today!
I've been actually working with jotai for quite sometime now, and yeah number 1 is a really valid point i didn't benchmark it with other state management solutions but it seems like it's working fine
That's a great point! Because it's so simple it certainly could be easy to abuse on apps that are super large or complex. My company uses Jotai however and we've never had an issue with it to my knowledge. But to your point, I think something like Zustand is a valid use case when this concern pops up! In terms of performance I have not officially benchmarked it or seen official benchmarks versus other solutions/libraries, however I can say in my experience with both medium scale apps (my personal projects) and large scale apps (my companies codebase) it's been just as fast as normal React state or contexts!
Ive sucessfuly migrated to jotai, an app which has big amount of data (air traffic over US) which is updated with few seconds interval. With jotai, its generalny easier to avoid rerenders, than eg. using redux. In terms of jotai performance overhead - its marginal, I recommend having a look at their codebase. The not so great part is that you need to get used to different data model, and atoms itself have some uncomfortable (for me) quirks. Theres some complexity while dealing with promises, or synchronizing state from outside source. 😊
@@AustinDavisTech I'll try to find a way to measure the performance of these state management solutions. Not sure how to begin, but I'm sure I'll enjoy the process of learning new things. 🙂
Btw, even though I have been working on React projects for many years now, I feel like I know very little. Videos such as this one will definitely be the push that I need to get good. 😛
I don't know the official benchmarks of Jotai, but I will say my company uses it pretty extensively on a large application, and performance has never been an issue. Expect it to run at the same speed as normal React state + contexts
Zustand seems really powerful, and I'll probably be making a video here on it soon once I get more experience with it. But if you want an extremely simple, out-of-the-box solution then Jotai is your guy :)
It's always been incredibly fast for me! It should be comparable in speed to useState/React contexts so long as you're not initializing atoms INSIDE React components and not causing unnecessary state changes & re-renders
an problem with Valtio is it's not very suited to store complex objects (e.g a MediaStream) because it uses Proxies, whereas Zustand and Nanostores doesn't have issues with them
State managers based on atoms are good only on examples or when they are simple. But having many atoms, on medium or large projects, can make the state management code realy messy. Especially when you read code after a few months xD
Not knocking signals at all but this is a gross oversimplification. Jotai is not bloated in the slightest AND is more "react-y" than signals are. Signals are cool and may have their place, but this kind of comparison doesn't do it justice
Much better than props drilling, love it. That's what I expected React.Context to actually work like, nice
Great video, great library! Thanks for the tip! This makes things really easier
This is wicked, somehow very similar to zustand but yet seems even simpler indeed.
Would be nice to see how types work on typescript and how more complex state works too, for instance if you have several variables and a few set/get functions like the usual zustand drill.
Wow! I’ve always hated handling state in react. I always used prop drilling, but this makes me want to get back into coding again! Great video!!
props is react with hard labour
That's great to hear! Prop drilling can definitely be a nightmare lol, it's so easy to lose track of things once your app gets the slightest bit complex
Nano store is awesome as well.. it's small reactive and works with react, solid ,native js or any famous framework.
Great fit for. Small to medium size projects.
If you use nano store with Astrojs the store you can be shared between frameworks.. you can make a change in solid component and react component will re-render if needed
I'll have to check this out!
Congrats.
You now made your app infinitely harder to test and debug.
Global State is a problem. In fact, it was such a big problem a whole programming paradigm was created to address it.
Exactly, that's what my biggest concern was
THIS CHANGES EVERYTHING! 🙃
great video! I like that you get to the point! I tried to like zustand but it felt weird and cumbersome however jotai seems like a way better fit for me!
For sure! Unless your project is super complex, I think simpler is generally better :)
zustand and zotai developed by the same person so both have place
Poimandres is a dev collective, not a person
Big agree! They both provide a ton of value, and you could actually use them together if you wanted to. In Jotai's docs there's a guide on how to hook it up with Zustand
@@viktor_zhurbin but these libraries were created by a single person and he is called Daishi Kato. He even created a third library called Valtio. So Zustand, Jotai and Valtio were all created by the same person. All are state management libraries, but built on different principles.
@@viktor_zhurbin Daishi Koto made both...
React devs have forgotten the best state management library of them all, the U R L.
I love this library, however I only use it in cases where I don't want to expose state to the user like setting a navbar's sticky state. Everything else goes into the URL bar in our projects.
I do think storing state in the URL is something people completely forget about and don't utilize as much as they could. However, some might say that even with a routing library, the URL still exists outside of the React ecosystem/lifecycle since it's part of the browser, making it less pure React, as opposed to something like Jotai that is 100% tied to the React DOM. This definitely can have upsides though depending how you look at it. Ultimately I think it is best to choose what works best for you :)
what about zustand it feels like it works like jotai would but the setter and state is dynamic and we can add extra methods using zustand
That's a great point! I haven't used Zustand a ton yet (still testing it out) but in my opinion Zustand would likely be a better choice if your app is highly complex. Not quite as cut and dry as Jotai, but it has the capability to do more. After all both Jotai and Zustand are made by the same person, for that exact reason
Why does react need n +1 state management libraries when svelte has built-in state management?
That's a great question. React does technically have support for global state, using contexts. You can wrap your app (or subtree of the app) in a context provider, and then React components within that subtree can access the state. The problem is, if you state gets a bit more complicated or needs to not be so rigid, contexts are not always the best solution. You end up having to wrap your App with multiple, sometimes dozens (yes I've actually seen this) of context providers, and it can get really messy and hard to track. The reason for libraries like Jotai, Zustand, Redux, etc, popping up is to try and offer a better and more flexible way to manage global state.
It's a bit unfortunate that so many libraries exist because it complicates things. It's also worth mentioning that React is a library while Svelte is a framework. React is great at doing what React does, but it stays pretty unopinionated about things like global state management and routing, whereas vanilla Svelte is a bit wider than vanilla React. I think both cases are good in their own way, part of what makes React good is that since it stays unopinionated, it meshes well with almost any library and is super flexible!
@@AustinDavisTech "part of what makes React good is that since it stays unopinionated, it meshes well with almost any library"
is that really true though? with svelte, I can use vanilla js libraries directly without having to write wrappers. and svelte isn't built on a vdom, so i can access the dom directly
@@anxpara Whether it is true or not, it depends on the person. I personally like having multiple choices on what technology stack I want to use for development. For example in many frameworks everything you need to develop an app is pretty much included. In React you might have to decide between Tanstack Query vs RTK Query vs SWR, for remote state, and what it is good for is that imo it pushes the industry forward with people always trying an improving on certain libraries. Like when context and redux were pretty much the only tools used for state management, pretty much everyone agreed that to manage state in react was a pain in the ass, specially classic redux. Now you have many options to choose from. Its true its hard to keep up with all of them, but I personally just find it better than just using a framework. But I feel like it is personal preference at the end of the day. Many people like full fledged frameworks a lot more. Pros and Cons to both
jotai is the best
Jotai seems really easy to use, with absolutely no boilerplate. But i do not think it will scale well in more complex applications. Zustand will be a better fit in that case.
Great video BTW
why? why would zustand scale not jotai?
@@darthvader4899 My previous comment was based solely on what was shown in the video (this was my first time seeing the library). So, thinking of integrating it with some complex apps I've worked with, scalability seemed problematic.
But going through its docs, my opinion of Jotai has changed. I believe its atom-based architecture allows for an application to be highly modular, consequently improving its scalability.
I agree, a while back I cross shopped jotai v zustand v redux toolkit and of the 3 zustand seemed to be the most flexible. Zustand can be nearly as atomic as jotai, but then built out to be as complex as redux. Zustand has the concept of a store, which helps organize global state into an obvious spot. I was concerned with jotai not having an organizing principle.
For truly app wide global state, we use react context. That handles things such as app theme, app authority etc. Other than that, we don't have a need for truly app wide global state. We use zustand for global module/feature level state. Zustand allows module state to be as simple, or complex as that feature requires.
I get your point, and I think a lot of people would probably agree with you about Zustand. However I do think you may be underestimating Jotai a bit, as I have seen it scale very well so long as it's handled responsibly. Two solutions that are created by the same person and great in their own ways!
@@BoonBoonitube Im not really sure but imho better to use zustand for app wide state because of not requiring context provider, thus it will only trigger re-render on component that use that specific state.
afaik the cons of using context is that triggers rerender to the providers children
So it's just global state? Does it have anything similar to Thunk in Redux? Even if it does not, I can see where Jotai will be useful.
It's global state by default unless you scope it then it only exists within its own scope (similar to how regular variables are scoped). Vanilla Jotai doesn't have thunk functionality like Redux, but that's also part of the beauty as to how simple it is
Can you show us your code? I wanna learn it more detail especially the code inside component
That’s great. Simple explanation. But it doesn’t have any vulnerable issue right that’s my only concern.
Jotai seems very easy to use, with not much of a setup. But having a bunch of global states worries me for the performance. Personally, I like useImmer and useImmerReducer. I don't mind setting up the reducer function once, and Immer helps with the immutability problem that native reducer had.
This really looks fantastic! But...
1. Maintenance may end up becoming a nightmare in large scale production apps - especially in companies where PR reviews are not done "properly". 😉
2. I am curious what the performance is like in medium and large scale apps. 🤔
Thank you making this video though. Best thing I learnt today!
I've been actually working with jotai for quite sometime now, and yeah number 1 is a really valid point
i didn't benchmark it with other state management solutions but it seems like it's working fine
That's a great point! Because it's so simple it certainly could be easy to abuse on apps that are super large or complex. My company uses Jotai however and we've never had an issue with it to my knowledge. But to your point, I think something like Zustand is a valid use case when this concern pops up! In terms of performance I have not officially benchmarked it or seen official benchmarks versus other solutions/libraries, however I can say in my experience with both medium scale apps (my personal projects) and large scale apps (my companies codebase) it's been just as fast as normal React state or contexts!
Ive sucessfuly migrated to jotai, an app which has big amount of data (air traffic over US) which is updated with few seconds interval.
With jotai, its generalny easier to avoid rerenders, than eg. using redux. In terms of jotai performance overhead - its marginal, I recommend having a look at their codebase.
The not so great part is that you need to get used to different data model, and atoms itself have some uncomfortable (for me) quirks.
Theres some complexity while dealing with promises, or synchronizing state from outside source. 😊
@@AustinDavisTech I'll try to find a way to measure the performance of these state management solutions. Not sure how to begin, but I'm sure I'll enjoy the process of learning new things. 🙂
Btw, even though I have been working on React projects for many years now, I feel like I know very little. Videos such as this one will definitely be the push that I need to get good. 😛
Nice , very niceee
Is it like recoil lite?
From my understanding it's pretty similar to recoil, although I'm not extremely familiar with that library so it's hard for me to say for certain
From my understanding Jotai was done looking at Recoil. But Recoil was a little more complex. Still, such a shame Fb stopped Recoil development.
isn’t this just recoiljs? Also Solid has this built in
Nice , but what about performance 😊
I don't know the official benchmarks of Jotai, but I will say my company uses it pretty extensively on a large application, and performance has never been an issue. Expect it to run at the same speed as normal React state + contexts
Zustand is just a this with more bells and whistles.
Zustand seems really powerful, and I'll probably be making a video here on it soon once I get more experience with it. But if you want an extremely simple, out-of-the-box solution then Jotai is your guy :)
God this is beautiful.
Wow. Like a zustand
I think preact signals makes it much more simpler than this. This is a nice state management library tough...
it's same principal as signals
It’s simple but it could get difficult to handle if you have many levers
i used it but it's too slow. it updates atom very slowly, i can't use more than 4 atoms after that it become very slow.
It's always been incredibly fast for me! It should be comparable in speed to useState/React contexts so long as you're not initializing atoms INSIDE React components and not causing unnecessary state changes & re-renders
Valtio is even crazier. It's also another poinandres react state manager
I'll have to try that out!
an problem with Valtio is it's not very suited to store complex objects (e.g a MediaStream) because it uses Proxies, whereas Zustand and Nanostores doesn't have issues with them
State managers based on atoms are good only on examples or when they are simple. But having many atoms, on medium or large projects, can make the state management code realy messy. Especially when you read code after a few months xD
This has saved me from so much pain 😹
Great to hear! :)
Its something like signal
This is same as recoil
you 360 no scoped this tut
Isn't this just signals with extra steps?
not really, Jotai and signals are very similar in a lot of ways, but ultimately behave differently behind the scenes
it is just using createcontext behind the scenes.
It can out be. It doesn't require you to wrap your app within a Provider.
@@tusharsnx Unfortunately, jotai-scope is using a context within the implementation of ScopeProvider.
@@realderek You're correct. To create a scoped atom you need context provider.
Preact signals is much better and less bloated.
Not knocking signals at all but this is a gross oversimplification. Jotai is not bloated in the slightest AND is more "react-y" than signals are. Signals are cool and may have their place, but this kind of comparison doesn't do it justice
nah, valtio is better. no boilerplate like this
Is the boilerplate in the room with us?
@@AustinDavisTech 😹😹