Live data from Hacker News

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

github.com

11–20 of 41 posts

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

#11

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

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

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

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

const $a = $observable(42)

const $b = () => $a()

IMO “use after dispose” should crash to make it easier to detect bugs. Also dispose should error when it texts a request to dispose something that still has a dependency. It is unlikely this is intended as it would likely lead to a “use after free” or memory leak.

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

#15

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…

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.

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

#16

I don’t understand the purpose of effect. Seems like compute can be used in all cases since you can dispose compute as well. Couldn’t read only be replaced with wrapping an observable in a closure? const $a = $observable(42) const $b = () => $a() IMO “use after dispose” should crash to make it easier to detect bugs. Also dispose should error when it texts a request to dispose something that still has a dependency. It…

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

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

#19
So I just started a new side project, and I'm using JS without a framework for the first time in over 5 years.

I poured over several state management libraries before just deciding to write a naive solution on my own. I've got a very simple stateful class - the data model itself is private, and it has a custom getter/setter for access. The setter broadcasts a custom event for each top-level key that changed.

Super simple, easy to understand, and the limitation forces me to keep my state as shallow as possible.

Am I missing something? I expected to run into trouble but so far it's been easy breezy.

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

#20
Cool! This reminds me of S.js [0] which I've used a decent amount to great effect, but it seems about half the size. I'll have to look at how they compare (though if someone knows off the top of their head that'd be appreciated). S.js is nice because it has a helper library (surplus) for dom things.

[0]: https://github.com/adamhaile/S

Post reply on HN