[rahim_alwer]

Hey everyone! I put together a functional reactivity library that uses observable functions as it's primitive for tracking state and changes. It's super tiny (850B), fast, only re-computes the dirty parts of a computation tree, batches updates via a scheduler on to the microtask queue, and works in both browsers and Node. Love any feedback :)

[fabiospampinato]

Do you have an implementation of the cellx benchmark? [0] It'd be interesting to see how it will perform there.

[0]: https://codesandbox.io/s/oby-bench-cellx-s6kusj?file=/lib.js

[rahim_alwer]

Thanks for sharing that, I just put together one [0] but hard to extract meaningful data without running at least an average across X (~1k?) attempts. Nonetheless, it seems to perform extremely well based on surface metrics.

[0]: https://codesandbox.io/s/maverick-js-observables-bench-cellx...

[leeoniya]

  $a(); // read
  $a.set(20); // write (1)
  $a.update((prev) => prev + 10); // write

why not $a(20) and $a(prev => prev + 10)?

[fabiospampinato]

It may be as a safety measure, it's much less likely to misuse the setter if it's divided into two different functions. If it's just one function you need to constantly ask yourself "wait, am I setting a function or not?", unless you always want to write `$a(() => value)`, which would be pretty ugly.

[rahim_alwer]

I started with that but then I thought about what if a callback or some other function is stored as an observable (i.e., like `useCallback`). Also, as fabiospampinato mentioned it's a cleaner seperation of get/set which makes it much easier to differentiate at a quick glace. You can't easily mess it up. I'm still debating whether to achieve what you're after. Maybe I have something mentally twisted and it's easier than I think.

[MH15]

I agree, this would make it a lot cleaner.