Zedux vs Jotai

[VCasecnikovs]

Jotai and Zedux are both atomic state libraries. I’d really like to understand the key differences between them — and in which cases one would be a better fit than the other.

[bowheart]

Thanks for asking @VCasecnikovs. I'll make a code-level comparison in the docs soon. Here are some high-level advantages of each solution.

But first, I want to say Jotai is a great tool. Zedux exists because of Jotai's shortcomings, but if one or two things were different, we'd be using Jotai today.

I'll be assuming Zedux v2 for most of this to keep it relevant since that'll be officially released soon.

Zedux Pros

• Speed. Zedux v1 is 2-3x faster than Jotai. V2 is 10x faster. Latest benchmark:

  lib   , test                 , time    , gcTime
  Jotai , avoidablePropagation , 3125.36 , 557.17
  Jotai , broadPropagation     , 6266.12 , 777.25
  Jotai , deepPropagation      , 2280.85 , 285.27
  Jotai , diamond              , 3528.33 , 494.18
  Jotai , mux                  , 2576.21 , 214.02
  Jotai , repeatedObservers    , 420.67  , 58.51 
  Jotai , unstable             , 822.00  , 92.29
  
  Zedux , avoidablePropagation , 121.69  , 6.57  
  Zedux , broadPropagation     , 667.13  , 12.90 
  Zedux , deepPropagation      , 152.62  , 4.26  
  Zedux , diamond              , 319.41  , 9.90  
  Zedux , mux                  , 280.77  , 4.05  
  Zedux , repeatedObservers    , 32.17   , 0.49  
  Zedux , unstable             , 80.42   , 3.27  
  

  It might look impressive, but this usually doesn't matter. We tested Jotai and deemed it fast enough, even for our data-intensive fintech apps. Still, the peace of mind knowing that Zedux is well beyond fast enough is at least something.

• More stress tested. Jotai v2.9 isn't able to complete several of our benchmarks due to a stack overflow (I omitted these from the above benchmark output):

  const readAtomState = (pending, atom2, force) => {
                        ^
  
  RangeError: Maximum call stack size exceeded
  

  The latest Jotai version (v2.12) can't run any of the benchmarks due to an error:

  # Fatal error in , line 0
  # Fatal JavaScript invalid size error 144998948 (see crbug.com/1201626)
  #
  #
  #
  #FailureMessage Object: 0x16fdaf7a8
  

  I'm sure Jotai can fix these, but it demonstrates how much more importance Zedux places on handling extreme duress.

• No WeakMap. This means Zedux isn't reliant on object reference matching, making it compatible with other instances of Zedux in other realms (child windows, iframes, workers, the server). It also means Zedux is able to find your state, enabling the next bullet:

• Cache management. Unlike all other atomic or signals libraries, Zedux is a cache manager like React Query. It has ecosystem.findAll to query your cache and ttl to intelligently handle automatic cleanup. Jotai's WeakMap makes it difficult to find and globally track your state.

  Jotai plugins and even some Jotai features have to bypass the WeakMap - storing atoms manually - in order to provide better DX than Jotai's model allows. This defeats the purpose of the WeakMap and makes Jotai just as prone to memory leaks as anything else. And, I'd argue, even more so since Jotai doesn't help find leaked nodes.

• String keys. This enables global cache management, state snapshotting/restoring for persistence and SSR, and (much) better DX.

• Update tracing. Zedux's ecosystem.why() is a lifesaver in complex debugging situations.

• Events. Zedux v1's stores can be consumed as both streams of state and streams of user-defined actions. Zedux v2's signals can be used to emit and listen to state change and other, user-defined events.

  This makes interop with observables and sockets easy. It also unlocks a reactivity escape hatch. React's reactivity model is way too slow for some data. We use ag grid, which can be updated outside React renders. Zedux's custom events can be used to shuttle updates directly to the grid, boosting update speed by several orders of magnitude. However, this is a brittle pattern compared to React's "UI is a function of state" model. Use sparingly.

• Easy to extend. Zedux doesn't have very many addon packages. But that isn't a big deal because customizing Zedux behavior is as easy as customizing React behavior - just make a custom injector. This is extremely approachable for any React dev who knows hooks.

  I know Jotai pretty well, but even with the new internals stuff they're working on, I usually find writing plugins for it to be daunting.

• Maintained by a fintech company as part of our own software (but MIT licensed, don't worry). That basically means I get paid to immediately fix any problems with Zedux.

Jotai Pros

• The WeakMap. This prevents memory leaks by default. If used incorrectly, Zedux is capable of leaking memory (though, as mentioned above, Jotai is too). Zedux's cache management features ensure the memory is never unreclaimable, but it's still something to be aware of.

• Bundle size. At least initially. Zedux is twice the size of Jotai's core. However, it's an unfair comparison since Zedux contains the features of jotai, jotai-effect, bunshi, and some of jotai/utils. This almost closes the gap - see here vs here.

  If it were possible to implement all of Zedux's features for Jotai, the resulting bundle size would be bigger.

• Async atoms. These are so convenient and I regularly revisit the possibility of bringing them to Zedux. Solid has shunned the concept since async leaks into everything that uses it. Doesn't matter IME. I will probably add some native support for async selectors, but atoms will have to wait for the async context proposal.

  This is just a convenience; Zedux doesn't actually lack any functionality for working with promises or triggering suspense. It's just more verbose with Zedux.

• Readonly atoms. Zedux's selectors are readonly, but atoms - even derived atoms - can't be made readonly. Seems weird, but it doesn't really matter - you won't find yourself trying to set derived atoms in Zedux.

  Jotai and Recoil also have a pattern for capturing updates of derived atoms and forwarding them elsewhere. I find this too implicit, contrived, and unnecessary. Zedux's atom exports are much cleaner IMO.

• Daishi. Man's a beast.

• Community packages. There are so many jotai addons - forms, persistence, ssr, history, location. There are also lots of integrations - tRPC, React Query, XState, etc.

So When Should You Use Which?

I'd say this is 90% preference. The only scenario where one approach wins outright is ours, the one that prompted the creation of Zedux: Fintech apps with multiple windows, sockets, or just lots of moving data will very possibly be unable to use Jotai. Zedux is made for apps like this.

Beyond that, the true best choice depends on too many factors and the outcome is too close to call. Both are powerful tools that can handle every situation. Some REST-API-powered SPAs may find Jotai's async atoms more convenient than Zedux's manual promise forwarding. Apps that need both UI state and server cache management, especially where performance is a concern, will find Zedux's combined model more convenient and several orders of magnitude faster than using Jotai with React Query.

Generally, simpler apps will probably be happier with Jotai. Zedux is a safer bet for more complex apps. I'm happy to break down pros and cons for any specific scenarios.

[VCasecnikovs]

You said that because of the lack of Weakmap it is possible to share zedux state across different pages and states.

Is it possible to have easily the same state across extension, webpages and injected data on some pages?

[bowheart]

Yes. It can be as simple as this (Zedux v2 code):

// propagate updates in this realm to other realms:
myEcosystem.on('change', event => {
  if (
    event.source instanceof AtomInstance &&
    // prevent circular updates:
    event.newState !== myEcosystem.hydration[event.source.id]
  ) {
    // or `chrome.runtime.sendMessage` or whatever sends events to other realms in your setup:
    postMessage({
      type: 'zedux-update',
      update: { [event.source.id]: event.newState },
    })
  }
})

// propagate updates in other realms to this realm:
window.addEventListener('message', event => {
  // Note: check `event.origin`/`event.source` to prevent XSS in this case

  if (event.data?.type === 'zedux-update') {
    myEcosystem.hydrate(event.data.update)
  }
})

You'll typically want additional checks to avoid propagating unnecessary changes. And this doesn't handle the race condition of an atom updating simultaneously in two realms. That can require some complex conflict merging. There are whole libraries dedicated to that. Though, depending on your setup, that may never really happen.

A more sophisticated setup that avoids that problem would be to make one realm's ecosystem the "source of truth" - e.g. the ecosystem in the background process of a chrome extension. All updates in other realms are then either:

• "optimistic updates" that wait for state to be propagated to the "source of truth" realm and back
• sent as events directly to the "source of truth" realm that are translated into state updates there which are then propagated back to the originating realm.

Zedux v2's new mutate events can also be used to efficiently propagate a list of transactions that describe a state change rather than the entire new state itself. Though that's an advanced use case I haven't documented yet.