If your app is all made of reactive streams plugged to the DOM by your framework, it's a great architecture that deserves a fancy name.
We could call it "Streams Oriented Programming", as it captures its essence well.
What is this all about, exactly?
This is a novel programming paradigm in web development, evolving from principles of Functional, Reactive, Declarative and Dataflow Programming, in which, to put it in simple terms, you define everything (that can change) as a stream.
If you use Observables, their common communication language is subscribe/next/error/complete.
You can use other patterns, too, different than just Observables, such as Callforwards or Callbags, but Observables just happen to be by far the most popular, well known, and on their way to become a web standard.
Why is this good for you?
Think of LEGO bricks: you can compose them so easily that every kid can do it.
If your apps all implement a unified compositional model, it becomes trivial to build large, complex applications that display very high quality and maintainability properties in addition to a sharp reduction in the lines of code you'll have to deal with.
What is a Stream, exactly?
Reactive streams aren't any magic construct, just a particularly well designed pattern, conceived by top programming language designers.
Streams get data in, do some processing and then emit data out.
This could be either sync or async, doesn't matter.
Also, they can combine data from other streams or include smaller streams inside, which allow for nearly unlimited composability.
Some perfect examples of Streams are the Subject and BehaviorSubject used in RxJS.
Use cases
Big Data ETL pipelines have done this since the age of scalability in a more or less informal way.
UI development is an excellent candidate for streams-oriented programming because everything can be represented as a stream: from clicks on a button which you turn into text on a webpage, to navigation, views, sequences of dialog boxes (wizards).
In JavaScript, most UI libraries or frameworks are conceived for the imperative programming paradigm, so this paradigm is novel.
LEGO bricks vs Jigsaw puzzles
Which comparison fits this paradign in a fair way?
Lego bricks you can be attached in a quite disorderly manner. On the other hand, jigsaw puzzles take a long time, especially at the beginning, to find two matching pieces.
Having worked with 100% streams-based simple and large enterprise applications for several years, I would say both can apply. When apps are small and simple, it's really like playing with LEGO bricks. When creating complex enterprise apps, the unique shape of each piece in the puzzle helps you only connect compatible pieces together...
Working with Streams
Working with streams starts with defining them first and then letting the platform or framework do the necessary bindings, declaratively defined in your template, so that your streams can start interacting with the world:
const stream1 = Stream(/* with its logic */);
const stream2 = Stream(/* with its logic */);
const stream3 = Stream(/* with its logic */);
const template = rml`
<button onclick="${stream1}">click me</button>
<div>${stream2}</div>
<div class="${stream2}" onmousemove="${stream3}">
${stream3}
</div>
`;
And that's it. The core of the concept.
Streams in action
If you'd like to see it in action, check out Rimmel.js, the first Streams-Oriented JavaScript UI library.
Want to see concrete examples? Have a look at this Stackblitz collection or the full list of examples and experiments I published on this topic which illustrate a number of cases implemented in a streams-oriented style.
Happy coding!
Top comments (0)