Surprising no one mentioned here about https://github.com/staltz/xstream
Creaed by Andre Staltz, the creator of cycleJS and other interesting reactive libraries in JS.
xstream is powerful and also much smaller in size. Give that a try.
Show HN: A tiny and fast reactive observables library via functions
21–30 of 41 posts
Re: Show HN: A tiny and fast reactive observables library via functions
#22Nice! 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…
> 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
Re: Show HN: A tiny and fast reactive observables library via functions
#23Surprising no one mentioned here about https://github.com/staltz/xstream Creaed by Andre Staltz, the creator of cycleJS and other interesting reactive libraries in JS. xstream is powerful and also much smaller in size. Give that a try.
Much smaller than ~800B? It looks like ~5kb min+gzip according to bundlephobia (https://bundlephobia.com/package/xstream@11.14.0).
Re: Show HN: A tiny and fast reactive observables library via functions
#24So... S.js[0]?
Re: Show HN: A tiny and fast reactive observables library via functions
#25So 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 si…
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/...
Re: Show HN: A tiny and fast reactive observables library via functions
#26Another notable reactivity lib is Vue's reactivity parts.
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().
Re: Show HN: A tiny and fast reactive observables library via functions
#27You might also be interested in my microlibrary trkl.js, a Knockout-like observables library that's just 383 bytes minified and gzipped:
https://github.com/jbreckmckye/trkl
I've used this for production sites where bytes down the wire is a hard constraint.
Re: Show HN: A tiny and fast reactive observables library via functions
#28Looks 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.
Re: Show HN: A tiny and fast reactive observables library via functions
#29Hey 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 :)
$a(); // read $a.set(20); // write (1) $a.update((prev) => prev + 10); // write why not $a(20) and $a(prev => prev + 10)?
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.
Re: Show HN: A tiny and fast reactive observables library via functions
#30Looks 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…
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.