observable
Future
Our great sponsors
| observable | Future | |
|---|---|---|
| 9 | 0 | |
| 512 | 121 | |
| 2.5% | - | |
| 8.3 | 0.0 | |
| 6 days ago | about 8 years ago | |
| Bikeshed | Swift | |
| GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
observable
- Proposal: Signals as a Built-In Primitive of JavaScript
-
What We Need Instead of "Web Components"
> especially since Observables have been widely available and actively worked on for a long time, without seeing wide adoption
Take a look at "Userland libraries" section [0] of the proposal (almost certainly written by Ben). He argues that observables get reinvented in the userland in various libraries over and over again. It is a primitive, like a Promise, only better.
[0] - https://github.com/WICG/observable?tab=readme-ov-file#userla...
> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem
Now that everyone seems to be in love with signals, there is work going on in the web components community group to prepare a spec for a signal (or observable, not sure what they are trying to call it) primitive [0]. It seems that they are getting ready to bring it to TC39 as a proposal.
(In the meantime, the Observable primitive from rxjs been given a go-ahead for browser implementation. There is a proposal ready [1], and I think I heard that it may already be in Chrome behind a flag [2].
So yeah; it's gonna be fun. Especially if both groups call their primitive Observable :-)
0 - https://github.com/webcomponents-cg/community-protocols/issu...
-
You Don't Need to “Learn” Svelte: Embracing the Simplicity of JavaScript
Perhaps this falls into the repetitive boilerplate category you referred to, but if you want framework-agnostic domain objects that still work well with Svelte, create your own using the observer pattern.
Create an object with a subscribe method and whatever other methods make sense for updating its state. Svelte will treat it like one of its stores, and it will work with the $ syntax. It can be used with React via its `useSyncExternalStore` hook. It can be used with SolidJS via its `from` utility.
If you don't want to handle the set-up boilerplate, you could use another library like Effector or RxJS, but of course, that means another dependency. There is a gradual move to make something like this a part of the platform[1], but who knows when or if it will land.
- Observable API Proposal
Future
We haven't tracked posts mentioning Future yet.
Tracking mentions began in Dec 2020.
What are some alternatives?
Observable - The easiest way to observe values in Swift.
ReactorKit - A library for reactive and unidirectional Swift applications
RxSwift - Reactive Programming in Swift
ReactKit - Swift Reactive Programming.
FutureKit - A Swift based Future/Promises Library for IOS and OS X.
ReactiveCocoa - Cocoa framework and Obj-C dynamism bindings for ReactiveSwift.
PromiseKit - Promises for Swift & ObjC.
Reactor - Powering your RAC architecture
OpenCombine - Open source implementation of Apple's Combine framework for processing values over time.
Safe
When - :alarm_clock: A lightweight implementation of Promises in Swift
Katana - Swift Apps in a Swoosh! A modern framework for creating iOS apps, inspired by Redux.