Show HN: A tiny and fast reactive observables library via functions (opens in new tab)

Preact, Mithril, Zod, etc. There are plenty of projects that have remained relatively light by saying “no” repeatedly to things which are outside their scope or would introduce unwarranted bloat.

Thanks and love the feedback. I know the dev space is full of cliche and overused terms. It's tough to not use them even when you're aware. I don't see it as a hard rule to avoid them and I think in some cases it's okay.

For example, if the core goal of the library is to achieve <2kB and you've predetermined a tight API scope (most likely based on existing references) then IMO it's okay to call it tiny/lightweight. It works out with libraries that are a providing a set of primitives to solve a generalized problem. I'm sure some people appreciate like I do when a library clearly indicates a core goal that was achieved (i.e. size) right in the top-level description.

I'm not sure that's really true for something like this, I've been working on something similar myself in these past few months, it got to about 5kb min+gzipped with all things included, and there's _a lot_ included, but if you only include the functions provided by this tiny library I wouldn't expect it to be much much larger than it, maybe a 2x or something? That's still small, fixes and performance optimizations tend to cost something, but you will never have to pay 10kb to use those 6 functions basically, the rest will be tree-shaken off.

I still don't mind people calling it light if it is though; maybe it gets removed later, however when it (still) is light, it makes it easy for me to search for so I can prevent overall project bloat.

This is only 850B, to me that was useful info that was mentioned in the headline. Yes it might get larger in the future or it might not.

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

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

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

> I don't entirely understand what it means to dispose of observables, is that just an internal optimization for cleanups basically?

In MobX there are various things that have to be manually cleaned up at different times to avoid memory-leaks, since reactive systems like this involve a lot of cross-references. I could imagine eg. that cleaning up an observable in this library releases references to all memoized values that were derived from it

Thanks for all the feedback, love it!

> I don't entirely understand what it means to dispose of observables, is that just an internal optimization for cleanups basically? Exposing an API for this feels a bit risky, like it feels easy to misuse.

It's a cleanup function that ensures that the observable can be garbage collected by clearing references to it in the dependency sets. It also marks the observable as disposed so that it's no longer reactive and ensures no new references can be made. I think brundolf gave a really good use-case for this API but you're right people can and will definitely misuse it... ¯\_(ツ)_/¯

> I personally prefer to opt into batching only sparingly and for performance reasons.

I'll definitely look at providing an API to provide a custom scheduler. I have to be careful not to bump up size in doing so _might_ be tricky.

> A function for creating roots seems missing, I think that's important.

I don't think it's needed here because it can be created with an `$effect`. It returns a `stop` function that can be called with `true` to dispose of all inner computations. I think I should provide a `$root` function that's just sugar for the mentioned.

> "isComputed" feels like a weird function to have

Ye I agree. I'll remove it and expose `isObservable` and `isReadonly` functions.

> I've made something similar myself, also inspired by Solid and Sinuous...

`oby` is super cool. It's so feature packed that it's going to take some time to dig through all of it. I love finding libraries like these, thanks for sharing it.

Much smaller than ~800B? It looks like ~5kb min+gzip according to bundlephobia (https://bundlephobia.com/package/xstream@11.14.0).

I made a library in which state management started the same way. A simple approach is great for performance-sensitive parts and it's easy to write, but there is very little helpful structure to it. Reactivity fails very easily, consider a dependency graph like this: a -> b a -> c b,c -> d In this case, updating `a` would cause d to be calculated (and reactions run) twice. Also, update batching is absolutely necessary for anything non-trivial.

At least for what I made, I don't think it's too complex for what it provides. It transparently integrates with the event loop and only runs what it needs to, at the cost of (min-brotli) 432 bytes at the moment. Compare the "naive" SimpleReactive with the complete FunctionalReactive version here: https://github.com/Technical-Source/bruh/blob/main/packages/...

> I don’t understand the purpose of effect. Seems like compute can be used in all cases since you can dispose compute as well.

Not OP, but:

- You could just use computeds instead of effects, but:

  - Effects don't have an internal observable, so they are cheaper to make and to keep in memory.

  - If OP will implement something like Suspense they'll probably want to pause the execution of effects, but not the execution of computeds.

  - OP didn't implement this, but potentially you could support returning a cleanup functions inside effects, you can't do the same for computeds.

> Couldn’t read only be replaced with wrapping an observable in a closure?

Yes, internally it's probably just a `$computed( $observable )`. The differences are that one is just a function and the other is an observable, which is a detectable difference that may matter, but also potentially the utility function could return you always the same observable if it has already a reference to a read-only version of the one you give it, which may consume less memory (1 function to keep around rather than N), though this is a bit of an edge case.

Vue's is especially nice in that it handles deep and imperative updates.

For example: you have an observable foo, and it has an array bar. You can read foo.bar directly instead of needing a wrapper getter function. You can also update foo.bar = … instead of needing a setter function. You can also call foo.bar.sort() and Vue will pick this up.

I see lots of small reactive libraries but a lot of them will not pick up something like foo.bar.sort().

Thanks damsta!