The Object⏩to⏩Stream mindset shift

Source: Dev.to

Introduction

If you took programming lessons, chances are they taught you classes, inheritance, encapsulation — the usual stuff of Object‑Oriented Programming (OOP). Perhaps it made even sense: wrap data and behaviour together, send messages between instances, and build a system that models a crystal‑clear vision of the world.

But what happens when we move away from the world of things and into the world of workflows? In the real world, everything changes, all the time, right?

That’s where Stream‑Oriented Programming (SP) comes in. Instead of thinking of “objects holding state,” we think in terms of “information / data / values flowing through time”.

And if you’ve worked with RxJS before, you already know that streams let you model async data in a very natural way. The next step is to stop bolting them onto OOP frameworks and instead build the UI itself as a graph of streams.

Why objects feel comfortable

Let’s look at a very familiar OOP pattern. Imagine a simple counter:

class Counter {
  private count = 0;

  increment() {
    this.count++;
    this.render();
  }

  render() {
    return `Click me (${this.count})`;
  }
}

const counter = new Counter();

document.body.innerHTML = counter.render();
document.body.addEventListener('click', () => counter.increment());

The Counter object holds state, has methods, and updates the DOM whenever something changes.

The mindset here is:

• I have an object.
• The object has state.
• The object has behaviour.
• When behaviour is triggered, the object mutates itself (or, in worst cases, the rest of the world).

How Are Streams Different?

Now let’s look at SP, using Rimmel.js:

import { BehaviorSubject, scan } from 'rxjs';
import { rml } from 'rimmel';

const count = new BehaviorSubject(0).pipe(
  scan(x => x + 1)
);

const App = () => rml`
  <button>
    Click me (${count})
  </button>
`;

document.body.innerHTML = App();

The mental shift

• I don’t have an object.
• I have a stream.
• That stream represents state over time.
• Events are also streams, merged into the same flow.
• Rendering isn’t a method call — it’s just describing how streams connect.

No explicit render() call, no mutable this.count. The button is “subscribed” to the count stream, and the DOM updates automatically whenever count changes.

OOP vs SP, side by side

Example 2: Live search

In OOP, a live search usually means:

1. Grab an input field.
2. Add a keyup listener.
3. Cancel pending timers manually.
4. Fire off fetch requests.
5. Update a result list.

In SP with Rimmel.js, the same logic is expressed declaratively:

// Helper that renders a single list item
const item = (str: string) => rml`- ${str}`;

// Observable that debounces the input, fetches data, and formats the result
const typeahead = new Subject<string>().pipe(
  debounceTime(300),
  switchMap(q => ajax.getJSON(`/countries?q=${q}`)),
  map(list => list.map(item).join(''))
);

// Component that wires everything together
const App = () => rml`
  <input
    type="text"
    placeholder="Search…"
    on:input="${typeahead}"
  />
  <ul>${typeahead}</ul>
`;

Basic Typeahead example

${typeahead}

Try it on StackBlitz. Keystrokes are a stream. Debouncing is just an operator. Fetching is a transformation. Rendering the results is another subscription. No manual cleanup, no “mutable query field”.

Example 3: Form validation

OOP approach

• Each input is tied to a property.
• Each property has flags like isValid.
• Validation runs imperatively on every change.
• A form object aggregates results.

SP approach with Rimmel.js

const App = () => rml`
  const submit = new Subject();

  const valid = submit.pipe(
    map(({ email, password }) =>
      ALL(
        email.includes('@'),
        password.length >= 6
      )
    )
  );

  const invalid = valid.pipe(
    map(v => !v)
  );

  return rml`
    <form on:submit=${submit}>
      <input type="email" name="email" placeholder="Email" />
      <input type="password" name="password" placeholder="Password" />
      <button disabled=${invalid}>Submit</button>
    </form>
  `;
`;

document.body.innerHTML = App();

Validation logic and the enabled/disabled state are expressed purely as a composition of streams.

Where to go from here

If you’re curious, Rimmel.js is a great playground to explore this mindset further. It’s lightweight, RxJS‑friendly, and built around streams from the ground up.

👉 Try it out: Rimmel.js on GitHub

And next time you’re about to spin up a class with a render() method, ask yourself: what would this look like if it were a stream?

Learn more

Stream‑Oriented Programming — An introduction

Creating Web Components with a simple Function

From callbacks to callforwards: reactivity made simple?