BrightFutures
DISCONTINUED
observable
Our great sponsors
BrightFutures | observable | |
---|---|---|
0 | 8 | |
1,899 | 507 | |
- | 3.2% | |
5.3 | 8.3 | |
over 1 year ago | 10 days ago | |
Swift | Bikeshed | |
MIT License | GNU General Public License v3.0 or later |
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.
BrightFutures
We haven't tracked posts mentioning BrightFutures yet.
Tracking mentions began in Dec 2020.
observable
-
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
What are some alternatives?
PromiseKit - Promises for Swift & ObjC.
FutureKit - A Swift based Future/Promises Library for IOS and OS X.
RxSwift - Reactive Programming in Swift
Bolts - Bolts is a collection of low-level libraries designed to make developing mobile apps easier.
ReactiveCocoa - Cocoa framework and Obj-C dynamism bindings for ReactiveSwift.
NoticeObserveKit - NoticeObserveKit is type-safe NotificationCenter wrapper.
then🎬 - :clapper: Tame async code with battle-tested promises
Observable - The easiest way to observe values in Swift.
When - :alarm_clock: A lightweight implementation of Promises in Swift
SwiftTask - Promise + progress + pause + cancel + retry for Swift.
Continuum
SwiftNotificationCenter - A Protocol-Oriented NotificationCenter which is type safe, thread safe and with memory safety