Streams Oriented Programming: an introduction

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, 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 higher quality and maintainability properties, in addition to a sharp reduction in the amount of code you'll write.

What is a Stream, exactly?

Streams aren't a magic construct, just a particularly well designed one, conceived by top programming language designers.

Streams get data in, do some processing and spit data out. Either sync or async.
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 in general is a great candidate because it hasn't broadly adopted this model and it's a great fit because everything can be represented as a stream: from clicks on a button which you turn into text to show on a page, 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 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 looks like defining them first, then letting templates as a binding language to let the platform or framework deal with it.

const stream1 = Stream(/* with its logic */);
const stream2 = Stream(/* with its logic */);
const stream3 = Stream(/* with its logic */);

const template = `
  <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!

Learn More

	Event Adapters: a simple introduction
	How is Vanilla JS unscalable
	DOM Observables, Rx7, Rx8 and the observable that doesn't exist yet