who would think, huh?
;-)

Would love to collaborate on plugging RippleJS into github.com/angular/web-...

We did quite a bit of Angular syntax fine-tuning + using the tool to drive design of some new DSLs (with some the ideas very similar to RippleJS).

@devagr.bsky.social was also toying with it for SolidJS.

Interested?

A good opportunity of writing a series of follow up articles, the whole "Perils of alternative X" saga :-)

More seriously, the article does a great job of pointing out some friction points with signals. But IMO those are easier to live with when compared to friction points of alternatives.

It is a popular opinion, at least in my circles :-)

My main reasoning is that library-agnostic widgets need to compromise to fit into different frameworks and not making full advantage of the ecosystem.

Plus "generic" design is often harder, makes lib iterations slower etc.

In general:

- APIs that are confusing for humans tend to be confusing for LLMs;
- APIs that are not flexible enough are more prone to hallucinations;

There are so many interesting techniques for using LLMs as user-study participants of sorts. A true LLM-driven design workflow.

I would _love_ to read a high-level overview focusing on:

a) your initial motivations (dissatisfaction with the mainstream? something else?)
b) main ideas / initial story;
c) why it got abandoned / what was the insight leading to that decision.

Hmm, this wouldn't be my immediate conclusion.

For one, after refactoring many apps, I see RxJS overused - where a simpler approach (signals, promises etc.) would work great.

Also, the upcoming Observables spec my change how we think about events processing and integration with signals.

Actually, this one of the thing that we very much do NOT want to address with signals - this is because signals are not meant to model those (eventing) situations.

This requires adjustment in thinking but a reactive graph should describe relation between data and not a sequence of events.