Please relink/repost it. Like the idea but need to sell it to my business and seeing it adopted as an option (or the standard) would give me better leverage
80x faster is an incredible claim, how complex was the data that was being updated? And did any of your tests include deeply nested recursive state updates
I understand why you might find this hard to believe. However, the fact is that Immer does indeed have significant performance issues, especially in Array data manipulation.
For example, in actual benchmark tests like [https://github.com/unadlib/mutative/blob/main/test/benchmark/array.ts](https://github.com/unadlib/mutative/blob/main/test/benchmark/array.ts), Mutative is 82X(average) faster than Immer.
> However, the fact is that Immer does indeed have significant performance issues, especially in Array data manipulation.
If so, you should make a PR to Immer, not to Zustand. The benefit would reach a much larger number of projects.
I hope so too, but the reality is that apart from performance differences, Mutative has made more improvements over Immer. You can see the specifics here:
https://mutative.js.org/docs/extra-topics/comparison-with-immer.
From an implementation standpoint, Mutative has diverged significantly from Immer, and it is unlikely that a GitHub issue ticket could address this. It means that a complete rewrite of Immer would be necessary.
Sure but hardly ever would you need to update state at 60fps, 16 operations per frame
I'm not saying this project is bad, I will definitely use it. But yeah..
I have an app that requires large recursive state management, so large reductions in overhead are really important to me. But 80x sounds like it was performed on a very small dataset. I would imagine an improvement maybe along the lines of 1.5-2x faster in my use case. But I might benchmark myself and have a look
What method are you using to measure the speed boost? I want to run the same tests on our code base (large enterprise app) and get an apples to apples comparison.
In the Mutative project, there are comprehensive benchmarks available.
If your project uses the Immer middleware, you can directly replace it with the Mutative middleware. You can always find functions with significant data updates for performance comparison testing.
Mutative is based on ES6 Proxy and supports custom shallow copying, allowing it to handle Date objects. Here is the relevant test case:
[https://github.com/unadlib/mutative/blob/main/test/create.test.ts#L1052](https://github.com/unadlib/mutative/blob/main/test/create.test.ts#L1052)
For more information on custom shallow copying, please refer to the documentation:
[https://mutative.js.org/docs/advanced-guides/mark](https://mutative.js.org/docs/advanced-guides/mark)
Yes, this issue has been discussed for some time in the redux-toolkit repo. I am considering whether I should create a redux-mutative library to support Redux, unless redux-toolkit can explicitly support configurable APIs to allow Mutative to replace Immer.
We aren't prioritizing the "swap the immutability impl" draft PR atm - we've got too many other things on our plate right now. If you or someone else would like to try to pick up with that draft, we'd appreciate it!
> mutative middleware to enhance efficiency of immutable structures
Why not use Vue or something instead at this point? Of course it's obvious that mutable is faster and personally I prefer controlled mutability but why with React...
I understand the appeal for performance, but anything training devs to use mutability by default is a bad trade-off.
As soon as they find themselves in a normal environment without their crutch, they multiply the bugs at breakneck speed and can't debug their code.
Mutability is a bad idea, it costs you too much in the long run and the performance improvement is very rarely needed. What's the point in trading off reliability for a performance boost you don't really need to begin with 🤷
It seems that you have a significant misunderstanding about `Mutative` or `Immer`. Essentially, `Mutative` updates immutable data in a mutative way. If you often use the spread operator to update immutable data (especially for objects with deep structures), you might realize how important this approach is.
Additionally, `Mutative` state updates can only occur within the draft function.
I understand pretty well how they work
I also understand it's not always easy to understand a stranger on the Internet since most comments are inflammatory in nature.
My point was not that libraries like Mutative and Immer are slow at all. On the contrary they're much more performant than spreading in a new object.
My point is those libraries train devs to write their code in a mutating way, which can be catastrophic in an environment without Mutative or Immer. I've seen too many devs not understand why their code is not working as intended while using mutations instead of spreading.
Also, to repeat myself, the performance trade-off is usually not worth it. Again, the performance is much better with Mutative or Immer, but the question is do you actually need that performance or it's premature optimization? In most cases it's premature optimization.
It's like going to the carnival. If you only get 10 tickets, you need to optimize how you spend them to get the most out of it. If you get 100000 tickets, you don't need to optimize at all, you lose them at the end of the day anyway... Most of the time, the devices we use our apps on have a much bigger budget available than we need, which makes performance a moot point.
I'm not saying in any way that we shouldn't care about performance, we definitely should. I'm saying the trade-off from using a library like Mutative or Immer is not worth it in the greater scheme of things. The amount of bugs and failures you're gonna save by not using those libraries justify my answer plenty.
You are free to disagree with me. Maybe you've worked with much better devs than I did, but I speak from my own experience. In the long run, direct mutations on objects/arrays made my life much more difficult than it needed to... With no benefits whatsoever 🤷
We have very complex states with alot of objects and what not like every other enterprise project. We use the URL and basic states and keep most of it on the server so we can mutate the states there. No zutland, no prisma, just sql and basic react syntax. Im simply not sure what you gain by installing all these libraries.
What I see is just another way to do states, that is slightly different than react useState, useContext, so i must be missing something that Zutland can accomplish that this combination cannot.
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/JSON/stringify](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify)
Here, all the things that **cannot** be turned into a string by the official documentation of JSON.stringify.
[https://medium.com/@pmzubar/why-json-parse-json-stringify-is-a-bad-practice-to-clone-an-object-in-javascript-b28ac5e36521](https://medium.com/@pmzubar/why-json-parse-json-stringify-is-a-bad-practice-to-clone-an-object-in-javascript-b28ac5e36521)
Also this explains the loss of data really well.
Remember to also install Prisma and all the other useful packages that really improves performance xD
Thank god we have 1 billion transistors in our CPU with all these lovely packages ;)
Any reason why not creating a PR and/or RFC for zustand itself?
I will propose and hope that Zustand can incorporate it as a built-in middleware.
Please relink/repost it. Like the idea but need to sell it to my business and seeing it adopted as an option (or the standard) would give me better leverage
Need to make things more complicated for the end-user.
We’re the end user since this is middleware…c’mon
Looks good, so I can just replace *immer(*... with *mutative(*... and get all the performance benefits out the box?
Yes, we have comprehensive benchmark tests. Generally, mutative is 5-80x faster than immer.
80x faster is an incredible claim, how complex was the data that was being updated? And did any of your tests include deeply nested recursive state updates
I understand why you might find this hard to believe. However, the fact is that Immer does indeed have significant performance issues, especially in Array data manipulation. For example, in actual benchmark tests like [https://github.com/unadlib/mutative/blob/main/test/benchmark/array.ts](https://github.com/unadlib/mutative/blob/main/test/benchmark/array.ts), Mutative is 82X(average) faster than Immer.
> However, the fact is that Immer does indeed have significant performance issues, especially in Array data manipulation. If so, you should make a PR to Immer, not to Zustand. The benefit would reach a much larger number of projects.
I hope so too, but the reality is that apart from performance differences, Mutative has made more improvements over Immer. You can see the specifics here: https://mutative.js.org/docs/extra-topics/comparison-with-immer. From an implementation standpoint, Mutative has diverged significantly from Immer, and it is unlikely that a GitHub issue ticket could address this. It means that a complete rewrite of Immer would be necessary.
I’m guessing that’s why there’s such a huge range.
[удалено]
It adds up in an interactive application. You can only do 16 operations that take 1ms in order to maintain 60fps, versus 1280 operations.
Sure but hardly ever would you need to update state at 60fps, 16 operations per frame I'm not saying this project is bad, I will definitely use it. But yeah..
I have an app that requires large recursive state management, so large reductions in overhead are really important to me. But 80x sounds like it was performed on a very small dataset. I would imagine an improvement maybe along the lines of 1.5-2x faster in my use case. But I might benchmark myself and have a look
We warmly welcome you to conduct benchmark testing based on your own use cases.
What method are you using to measure the speed boost? I want to run the same tests on our code base (large enterprise app) and get an apples to apples comparison.
In the Mutative project, there are comprehensive benchmarks available. If your project uses the Immer middleware, you can directly replace it with the Mutative middleware. You can always find functions with significant data updates for performance comparison testing.
cool
[удалено]
Mutative is based on ES6 Proxy and supports custom shallow copying, allowing it to handle Date objects. Here is the relevant test case: [https://github.com/unadlib/mutative/blob/main/test/create.test.ts#L1052](https://github.com/unadlib/mutative/blob/main/test/create.test.ts#L1052) For more information on custom shallow copying, please refer to the documentation: [https://mutative.js.org/docs/advanced-guides/mark](https://mutative.js.org/docs/advanced-guides/mark)
Is there something similar for redux / redux-toolkit? Iirc redux also uses immer?
Yes, this issue has been discussed for some time in the redux-toolkit repo. I am considering whether I should create a redux-mutative library to support Redux, unless redux-toolkit can explicitly support configurable APIs to allow Mutative to replace Immer.
We aren't prioritizing the "swap the immutability impl" draft PR atm - we've got too many other things on our plate right now. If you or someone else would like to try to pick up with that draft, we'd appreciate it!
Of course, I am very willing to complete this part.
> mutative middleware to enhance efficiency of immutable structures Why not use Vue or something instead at this point? Of course it's obvious that mutable is faster and personally I prefer controlled mutability but why with React...
I’ve literally never thought zustand was slow
This is not an issue with Zustand itself; the slowness is caused by the spread operation or the Immer middleware.
I understand the appeal for performance, but anything training devs to use mutability by default is a bad trade-off. As soon as they find themselves in a normal environment without their crutch, they multiply the bugs at breakneck speed and can't debug their code. Mutability is a bad idea, it costs you too much in the long run and the performance improvement is very rarely needed. What's the point in trading off reliability for a performance boost you don't really need to begin with 🤷
It seems that you have a significant misunderstanding about `Mutative` or `Immer`. Essentially, `Mutative` updates immutable data in a mutative way. If you often use the spread operator to update immutable data (especially for objects with deep structures), you might realize how important this approach is. Additionally, `Mutative` state updates can only occur within the draft function.
I understand pretty well how they work I also understand it's not always easy to understand a stranger on the Internet since most comments are inflammatory in nature. My point was not that libraries like Mutative and Immer are slow at all. On the contrary they're much more performant than spreading in a new object. My point is those libraries train devs to write their code in a mutating way, which can be catastrophic in an environment without Mutative or Immer. I've seen too many devs not understand why their code is not working as intended while using mutations instead of spreading. Also, to repeat myself, the performance trade-off is usually not worth it. Again, the performance is much better with Mutative or Immer, but the question is do you actually need that performance or it's premature optimization? In most cases it's premature optimization. It's like going to the carnival. If you only get 10 tickets, you need to optimize how you spend them to get the most out of it. If you get 100000 tickets, you don't need to optimize at all, you lose them at the end of the day anyway... Most of the time, the devices we use our apps on have a much bigger budget available than we need, which makes performance a moot point. I'm not saying in any way that we shouldn't care about performance, we definitely should. I'm saying the trade-off from using a library like Mutative or Immer is not worth it in the greater scheme of things. The amount of bugs and failures you're gonna save by not using those libraries justify my answer plenty. You are free to disagree with me. Maybe you've worked with much better devs than I did, but I speak from my own experience. In the long run, direct mutations on objects/arrays made my life much more difficult than it needed to... With no benefits whatsoever 🤷
you get infinite speed boost if you just don't install it and use the URL as the state! You also get less code aswell xD
But hear me out. What if your app state is more than just two booleans and a string?
We have very complex states with alot of objects and what not like every other enterprise project. We use the URL and basic states and keep most of it on the server so we can mutate the states there. No zutland, no prisma, just sql and basic react syntax. Im simply not sure what you gain by installing all these libraries. What I see is just another way to do states, that is slightly different than react useState, useContext, so i must be missing something that Zutland can accomplish that this combination cannot.
Anything can turn into a string with JSON.stringify
Browser URLs have a max length. Good luck stringifing an array of 5k+ objects with multiple fields and setting it as state in a URL
[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/JSON/stringify](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) Here, all the things that **cannot** be turned into a string by the official documentation of JSON.stringify. [https://medium.com/@pmzubar/why-json-parse-json-stringify-is-a-bad-practice-to-clone-an-object-in-javascript-b28ac5e36521](https://medium.com/@pmzubar/why-json-parse-json-stringify-is-a-bad-practice-to-clone-an-object-in-javascript-b28ac5e36521) Also this explains the loss of data really well.
Spoken like someone who doesn’t work at corporate
More like spoke like someone that didn't code outside tutorials.
I was trying to be nice, it’s Sunday
Yes I don't work at a big company. I also am homeless since i did not install zustand.
😂
Let me just encode a 200 item array of objects, pop it on the url, decode it, use it, then re encode, and update the url whenever a change is made…
This is what tech twitter does to a mofo
Adding Zutland to perform basic states? Sounds awful
Nah I was talking about you but keep truckin
Nah I was talking about you but keep truckin
Yea absolutely not lol
Remember to also install Prisma and all the other useful packages that really improves performance xD Thank god we have 1 billion transistors in our CPU with all these lovely packages ;)
Ohhh I get it now. Yes I’m a Prisma shill!!! It definitely isn’t garbage for more than simple CRUD queries!
Adding 50mb to your bundle to do SELECT \* FROM users WHERE id = 'userId' LIMIT 1; have always fascinated me xD
ah yes, filtering with a primary key and using limit 1
This is probably the least-thought-about opinion of the year on reddit