Show HN: Connective – Large-scale reactive programming in Javascript/Typescript

> 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,

What does this mean?

> 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).

Isn't this just functions? I pass my Observables as arguments and variables, and use pipe() to create transforms.

---

Do you have Connective vs vanilla RxJS example to demonstrate?

With RxJS your hello world is

    fromEvent(a, 'input').pipe(
      map(() => a.value),
      filter(name => name != 'Donald'),
      map(name => 'hellow ' + name),
    ).subscribe(msg => p.innerHTML = msg);

I see you have https://connective.dev/docs/connective-v-rxjs

I will look at that.

This is wrong. The "pipe()" operator allows you to reuse parts of an Observable flow in RxJS. For example the following function can be used in many different Observable flows:

    import { pipe } from 'rxjs/operators';
    
    function checkAuthPipe() {
      return pipe(
        doSomething(),
        runAnotherPipe(),
        map(out => out.isAuth)
      )
    }

Good work with the library though, like the documentation and the concept behind the framework, we won't know if something's better until we try it.

.NET's ObservableCollection<T> is an example of doing this well.

Regardless of the quality of API design, reactive programming (and by extension RxJS) does indeed require a different mental model, as it is a different model for the flow of a program.

> You’ll notice most of the popular and highly successful abstractions all share the common trait of being easy and quick to pick up.

That is subjective. I remember how many people found node's async callback style unintuitive and confusing on first sight, and I personally find (at least the core abstractions of) RxJS pretty intuitive.

> If the author’s haven’t factored in ease of use and uptake it’s already failed at its first principles.

Yes this is part of the goal with CONNECTIVE, to bridge the gap between the description of a reactive flow (the code) and the most intuitive way to think about it (a directed graph), so that the end-result would be much more easily readable and intuitive code. I would love to hear if you have any more specific feedback on this front.

You can find it used widely in every successful company, and equally used by hobbyists and non-IT people around the world.

It's called "spreadsheet".

So, at least the root idea of the approach is viable.

I think it is theoretically possible to mostly deprecate VDOM with this paradigm, leading to better overall performance and control.

> 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.

Even for the backend though, specifically for concepts like message brokers (or any similar construct based on application) I would think the paradigm is quite useful.

> 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.

I personally tend to believe that the ideal DSL (representation) for flow diagrams is a graph (as it encapsulates both the logical and the execution flow), which means in the end of the day any textual representation would be sub-optimal (as any textual representation of any directed graph is sub-optimal and less intuitive compared to drawing the graph itself).

this is typically untrue. the genesis of libraries like RxJS is encapsulating repeated code responsible for properly handling async resources/transformations. without them, you would either repeat similar code everywhere, or end-up writing your own version for the organization. you don't need to take my word for it though, try replicating some of the examples on the website (or on learnrxjs.io) to see this for yourself.

> Locked into a libraries way of doing logic chains

this is a valid concern, though the other side of this coin is not using anything like express, angular, react, etc as they all have the same effect. the design of such libraries should typically be pretty flexible to be more facilitating than restricting, and its always a bonus if they are smartly restricting (discouraging programmers from making mistakes and taking away cognitive load of making choices that can be mostly decided beforehand, etc). core concepts of RxJS for example are so basic that there are serious ECMA proposals to adopt them into the language itself (Observables), much like Promises before them (which were initially promoted by libraries that are still around).

> Steep learning curve for new team members

this is specifically true about libraries targeting reactive programming. the issue is not actually with the libraries but with the paradigm itself, as it requires a different mental model of the flow of the code. this is part of the reason CONNECTIVE exists to begin with, to offer an interface reflecting a more intuitive mental model of reactive flows compared to RxJS, though still it would be a different mental model compared to traditional synchronous programming.

this learning curve however is something that I personally believe is unavoidable in the long run. you already need to adopt it if you want to be competent at prominent frontend frameworks like React or Angular, the latter of which incorporates and utilizes RxJS extensively and the former borrows a lot of the concepts. we already had to go through such a curve with transition to NodeJS for backend, where before you would mostly write fully sync one-request at a time instance codes and compensate by paying extra for the hardware, but now-a-days that extra learning-curve is no longer considered a deterrent.

I've love some of the texts books that has small hints of the authors political attitudes hidden in the examples. It gives character to the work.

Especially in open source I believe this is important to have this freedom. Companies usually do not openly express political prefs (unless it's widely accepted, as in gay-pride rainbows when the fight for equality is largely won). Many opensource projects are not run by corps, but by individuals: and that individual decide to tag a message to the product he/she delivers.

This has always been done, it's form of activism, and I believe it is a good thing. Otherwise we would only encounter political statements in the places we expect it (media, which is largely paid for) and much of us have already chosen to ignore.

My main point: please do not be dismissive of politics as that only helps the lobbyists (and the corps/ultra-rich they represent), and at this point we need to free "our" democracies (means: people rule) from them. Shutting people up by telling them not to discuss politics is not going to help.

Politics can no longer be kept out of any field whatsoever, because this is "a politically-charged era," in the argot of the day, but it might be more accurate to describe it as business-as-usual for a large Europe-derived civilization. Remember the Hundred Years War?

The post-war period of stability and consensus is an anomaly and has ended. Buckle up.

https://en.wikipedia.org/wiki/Donald_Duck

the second one being offering abstractions for re-use of partial graphs.

and it is notable that though CONNECTIVE takes away the worry of multi-casting in (hopefully) a lot of the cases, it is actually pretty conservative on that front and will in a number of cases default to not-multicasting, which might mean that you can get some unexpected behaviors if you are completely unaware of the concept. the plan is to expand the situations that it will make a good default decision for you on that front overtime based on how it is actually used.

EDIT: also thanks, yes as I mentioned somewhere else I actually started doing this for a super-efficient frontend framework (that effort epically failed), so I ended up being extra careful about a lot design choices (and to be fair, carefully delegating a lot of such choices to RxJS as it is a really brilliantly designed library itself).

it is not featured on the main page since the atomic process is not essentially different (neither from RxJS nor from any other library you might want to use to do that, though the ease of just plugging in any other library for that perhaps is different from RxJS).

if you mean "how I got to doing this?" well I was thinking of writing a piece on it, but short story is that I was trying to extend what I was working on before (connect-platform.com) to front-end in a really efficient manner (as I realized the paradigm shift on front-end means much less need for constant performance overhead of mechanisms like VDOM) and hence ended up here.

and about the docs, thanks, I am perhaps going to also independently publish the code responsible for generating it on github pages as an NPM package alongside my next project.