ok a bit of background:

I have been working on my off time for some time now to bring reactive programming to the fore-front of web development, as I think it best captures the essence of the logic in those domains, which is basically an event/data flow graph. Current languages and tools are built around the traditional sequential flow of a program, and this mismatch makes it pretty hard to properly adopt the paradigm without proper libraries/tooling.

RxJS is one of the best such libraries, though it lacks some essential features for being properly used at scale:

- It models the flows with inverse event/data flow trees, which though an improvement over the sequential flow still limits how larger flows are described,

- It does not provide any abstraction for re-use of reactive flows, which is essential to large-scale codes based on the paradigm (imagine coding without functions).

CONNECTIVE is a thin library on top of RxJS that addresses those issues. It is designed to be complementary to RxJS, boosting its flexibility and scalability without limiting its potential. You can read the following entry on the docs section for more info about these issues and how CONNECTIVE addresses them:

https://connective.dev/docs/connective-v-rxjs

The problem with these libraries are significant ramp up time. Unlike what the authors are claiming it’s not because it’s a difficult or greatly different mental model to grasp, it’s because the API is clunky and poorly designed. You’ll notice most of the popular and highly successful abstractions all share the common trait of being easy and quick to pick up.

It should be a red herring to anyone these days when they see demo code that looks completely unintuitive which purports to make something easier. If the author’s haven’t factored in ease of use and uptake it’s already failed at its first principles.

This reminds me Cycle.js. I would definitely think stream paradigm is very useful to front-end.

The essential difference in front-end, is the programmer is dealing with continous, realtime signals, and transform it into the graphical interface. This is very different from most request/response style back-end. And the stream is obviously a proper abstraction for modeling this.

However, I found it's tedious to work with RxJS or other stream libraries, not because the design itself, it's just JavaScript lack of flexible DSL machanism like macro. If you invent a DSL for a stream flow diagram, you can get a lot of very neat equations between source and sink, but for JavaScript it's very hard to abstract away the stream context syntactically.

My issue with these libraries is the overheads.

- Steep learning curve for new team members - More lines of code to do the same logic chains - Locked into a libraries way of doing logic chains

You can get the same functionality without the library in less lines of code, in a clearer functional or OOP way.

Am I missing something? This is much harder to introduce to organizations / teams.

I just went away, learned all about RxJS, and then about Connective, and I think I'm in love.

This is a simple, pure, and elegant way of expressing complex systems. The site makes a whole lot more sense when you catch up with the reactive paradigm and see what RxJS does and what Connective provides that it doesn't.

I'll use this for my next project.

Not gonna lie I wish we kept politics out of software

It looks like you put a lot of thought into this!

Connective allows users to create graphs between sources and sinks flexibly (i.e., not only source to sink ala typical RxJS), without needing to worry about multicasting.

Is this a fair way to describe this library's benefit?

I was missing an example of an async operation with Connective. Like fetch()ing something from an API based on a username.

I've been recently using @grammarly/focal for state management and reactive flow programming.

It also uses rxjs behind the scenes, which I really like has gained some ground with Angular lately.

very nice and i wanted to say i appreciate your docs :)

is there a personal “why” story writeup somewhere? i dont have a need for it but i’d love to learn more about what made you work on this

'large scale'

They need an editor for their marketing copy first.