Stream Oriented programming is a rediscovered paradigm evolving from principles of Reactive, Declarative and Dataflow programming in which, to put it in simple terms, you define everything (=your state) as a stream.
Streams themselves can be created using a variety of imperative or functional primitives, such as Observables, Signals, Callbags, Callforwards, plain functions, to name a few.
Observables are by far the most mature and feature-rich primitive on their way to become a web standard.
Why is this good for you?
Streams are infinitely composable: group them together in a larger stream, and use that as a higher-level piece of reusable functionality that will still talk the same language and observe the same contract. Data in, data out.
If each of your apps implements the same unified compositional model, it becomes trivial to build large, complex applications that display impeccable 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?
A reactive stream isn't any magic construct, just a particularly well designed pattern.
Streams get data in, optionally do some processing and then optionally emit data out.
This could be either sync or async, doesn't matter.
Also, they can combine data from other streams.
Some perfect examples of Streams are the Subject and BehaviorSubject used in RxJS.
Use cases
Big Data pipelines have done this since the age of scalability in a more or less informal way.
Cloud-native development is an example of stream-oriented programming, just generally at a higher level enough to actually be an architectural concern.
UI development is an excellent candidate for this paradigm because everything naturally fits a stream: from clicks on a button which you turn into text on a webpage to navigation, views, sequences of dialog boxes (wizards), to the most complex workflows.
A mouseover is a stream, a dialog box is a stream, a whole app is a stream.
In JavaScript, most UI libraries or frameworks are conceived for the imperative programming paradigm, so this paradigm is novel.
When not to use streams
You should only avoid streams if you want to build old-school programs that constantly repeat the most boring parts of an application:
target1.data = source1.data
target2.setData(source2.data)
source3.on('data', data => target.doSomethingWith(data))
The beauty of reactive streams is you can get rid of this clutter forever, connect point-free streams in-and-out with the certainty they will just work.
A large surface of bugs comes from imperative programming moving data from source to destination.
Working with Streams
Working with reactive 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 the core of the concept: reactive streams first, combined together in a template that declare their bindings to the outside world.
Streams in action
To see it in action, check out Rimmel.js, the first Stream-Oriented UI library for JavaScript.
Looking for examples? This Stackblitz collection or this collection of examples and experiments I published on this topic illustrate streams-oriented programming in over a hundred examples.
Now, if you like what you've seen here please don't forget to leave a Star in Github ⭐ so we can continue evolving it for you!
Happy coding!
Top comments (0)