Live data from Hacker News

Show HN: A tiny and fast reactive observables library via functions

github.com

31–40 of 41 posts

Re: Show HN: A tiny and fast reactive observables library via functions

#31

Looks interesting... One critique is "light/tiny/lightweight" whenever I read about software being "light" I cringe and get an eye-twitch(ok not really). But adding "light" or claiming your product is "light" means usually nothing other than its new . Sure it might start out as small/lightweight but usually this is because the software is new . Once you start adding in corner-cases (the ones you haven't even thought…

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.

Reminds me of https://suckless.org

Re: Show HN: A tiny and fast reactive observables library via functions

#32

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 :)

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

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...

Re: Show HN: A tiny and fast reactive observables library via functions

#34

Nice! I love these tiny libraries. Some random thoughts: - I like that the effect function returns a disposer. - 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. - Batching everything feels interesting, no "am I in a batch or not?" problems anymore, though I quite…

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.

Re: Show HN: A tiny and fast reactive observables library via functions

#36

Looks interesting... One critique is "light/tiny/lightweight" whenever I read about software being "light" I cringe and get an eye-twitch(ok not really). But adding "light" or claiming your product is "light" means usually nothing other than its new . Sure it might start out as small/lightweight but usually this is because the software is new . Once you start adding in corner-cases (the ones you haven't even thought…

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.

Did they really ??

Looking at latest version of Preact v 10.5.14.zip (887kb) vs Preact v8.5.0.zip(90kb). So that is almost a x10 size increase in two years.

Re: Show HN: A tiny and fast reactive observables library via functions

#37

Earlier quoted context omitted.

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.

Did they really ?? Looking at latest version of Preact v 10.5.14.zip (887kb) vs Preact v8.5.0.zip(90kb). So that is almost a x10 size increase in two years.

You're doing something wrong. I just tested now. Preact 8.5.0 is 3.2kb minified+brotlied. Preact 10.8.2 (latest) is 3.7kb. That's a very small increase.

Re: Show HN: A tiny and fast reactive observables library via functions

#38

Looks interesting... One critique is "light/tiny/lightweight" whenever I read about software being "light" I cringe and get an eye-twitch(ok not really). But adding "light" or claiming your product is "light" means usually nothing other than its new . Sure it might start out as small/lightweight but usually this is because the software is new . Once you start adding in corner-cases (the ones you haven't even thought…

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.

Re: Show HN: A tiny and fast reactive observables library via functions

#39

Earlier quoted context omitted.

Did they really ?? Looking at latest version of Preact v 10.5.14.zip (887kb) vs Preact v8.5.0.zip(90kb). So that is almost a x10 size increase in two years.

You're doing something wrong. I just tested now. Preact 8.5.0 is 3.2kb minified+brotlied. Preact 10.8.2 (latest) is 3.7kb. That's a very small increase.

I think you right. I just downloaded the "tagged software version" from github.

Re: Show HN: A tiny and fast reactive observables library via functions

#40

Nice! I love these tiny libraries. Some random thoughts: - I like that the effect function returns a disposer. - 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. - Batching everything feels interesting, no "am I in a batch or not?" problems anymore, though I quite…

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…

> 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.

Yes, but there's another ingredient missing, which is the important one: roots are not disposed of automatically when the parent computation is re-executed/disposed. That's unimplementable on top of other functions because they just don't have that property.

Post reply on HN