DEV Community: Dario Mannu

Composable UI contracts and an algebraic approach to layout, style and interaction

Dario Mannu — Mon, 05 Jan 2026 13:30:00 +0000

Experienced frontend developers already know the uncomfortable truth: UI complexity does not come from CSS syntax or framework choice. It comes from implicit responsibility. Who owns spacing. Who controls size. Who is allowed to style descendants. Who captures input. What happens when text grows. What breaks when layouts switch at a breakpoint.

Most UI systems rely on conventions, reviews, and experience to keep this under control. That works, until it doesn’t. Deep nesting, design system growth, accessibility requirements, theming, responsiveness, and motion all push the same weak spots.

This article proposes a different approach.

Not a framework. Not a CSS methodology. Not a component library.

A compositional model for UI, where layout, style, and interaction are treated as explicit contracts that can be reasoned about, composed safely, and eventually formalised.

N.B.: When we use the term Algebraic UI, we’re not referring to algebraic effects, UI state machines, or functional control flow.
We’re using “algebraic” in the structural sense: UI paradigms are treated as composable algebraic objects with explicit compatibility rules, identity elements, and substitution laws.

The core idea: UI as responsibility contracts

Instead of thinking in terms of HTML elements and CSS rules, we model UI as a tree of responsibility zones.

Each zone makes explicit promises:

what it controls
what it forbids
what it expects from its parent
what it guarantees to its children

Composition becomes safe when:

a child’s requirements are satisfied by its parent’s guarantees

This simple rule turns layout bugs into type errors.

Paradigms, not properties

A paradigm is a stable bundle of rules that govern responsibility.

Paradigms are not visual patterns.
They are laws.

Examples people already recognise intuitively:

stack
grid
overlay
modal
card
button

What changes here is that each paradigm is defined explicitly, not socially.

Concerns: the dimensions of responsibility

Instead of ad-hoc rules, each paradigm is defined as a vector over a small number of concerns. Each concern has a closed set of allowed values.

Layout concerns (example set)

Flow: none | block | inline | axis(horizontal|vertical) | grid | overlay
Spacing ownership: parent | child | shared | forbidden
Spacing propagation: inherit | isolate | reset
Sizing authority: intrinsic | constrained | imposed
Margin emission: allowed | forbidden
Boundary strength: transparent | soft | hard
Text growth tolerance: flexible | bounded | fixed
Adaptivity: static | adaptive | responsive

These do not describe how layout is implemented. They describe who is responsible.

Style as authority, not decoration

Style is not just colour and typography. Style is visual authority.

Style paradigms answer questions like:

who may style whom
how far styles propagate
whether tokens may be overridden
whether the cascade participates or is isolated

Style concerns (example set)

Style scope: self | children | subtree
Inheritance: inherit | block | explicit
Token dependency: none | consume | override
Visual authority: parent | component | shared
Cascade participation: isolated | layered | global
Reset behaviour: none | partial | full

Once these are explicit, subtree styling stops being an accident.

Interaction and animation as contracts

Interaction is not business logic. It is input and time responsibility.

Animation is not decoration. It is temporal state change.

Interaction and motion concerns (example set)

Input capture: none | child | parent | exclusive
Event propagation: bubble | capture | intercept | isolate
Interaction ownership: component | container | shared
Temporal authority: self | parent | external
Interruptibility: non-interruptible | interruptible | reversible
Reduced-motion sensitivity: insensitive | adaptive

This makes modals, sliders, drawers, and carousels first-class citizens instead of special cases.

Components vs layout paradigms

A core distinction:

Layout paradigms organise children
Component paradigms define a single interactive unit

A Stack and a Button are not competing abstractions. They are orthogonal.

A real component combines them:

external contract: element-level
internal implementation: layout paradigms sealed behind boundaries

This cleanly handles components that are both layout and element internally, such as sliders or tabs.

Schemes and themes: separating meaning from values

Design systems fit naturally once responsibilities are explicit.

Schemes define semantic slots and what can be changed
Themes assign concrete values

Typography, spacing scales, colour roles, motion curves all live here.

Paradigms never care about values. They care about tolerance.

A layout does not decide font size. It decides whether text growth is allowed to affect structure.

Accessibility as an invariant, not a feature

Accessibility is not a separate paradigm.

It is a set of constraints that must hold across layout, style, and interaction:

focus must be reachable
motion must be interruptible or adaptive
contrast must meet thresholds
text must remain readable under scaling

ARIA attributes and semantic tags become implementation details, not design crutches.

If the contracts hold, accessibility follows mechanically.

Responsive design = paradigm substitution

Breakpoints are not layout logic.

They are context signals.

Responsive behaviour becomes:

substitute paradigm A with paradigm B
when condition C holds
provided external contracts remain valid

Grid → Stack
Sidebar → Overlay drawer
Cluster → Flow

No half-states. No accidental overrides.

A model to create design systems and frameworks

This model is not a framework. It does not prescribe:

HTML structure
CSS syntax
JavaScript framework

It defines:

contracts
compatibility
forbidden states

So, frameworks can be built on top of it.

What this enables

Automatic validation of UI composition
Deep nesting of elements, components or blocks
Safe theming and scaling
Predictable accessibility
Refactoring without visual regressions

What comes next

This article describes the model informally. These are the next steps:

define paradigms as algebraic objects, formally
define compatibility
define composition and substitution operators
identify the most useful settings for key concerns and build a conceptual paradigm on top
build a design system modelled after that
build a tiny example application using the above

Learn More


	Web Components with one Simple Function
	Do you think Observables suck? Read this first!
	A Web Developer's guide to Stream-Oriented Programming

HTML strings vs the DOM API: from a small benchmark to a surprising result

Dario Mannu — Tue, 25 Nov 2025 09:36:42 +0000

Which of the following do you think is faster?

direct DOM API calls (createElement, appendChild)
assigning HTML strings to innerHTML

Chances are you'll say the former is faster and most people would agree.
This belief is so deeply rooted in popular culture that even many framework authors chose to base their entire architecture around DOM API calls.

Now, critical thinking to the rescue. Is this really, really true?

At the end of the day, browsers have been optimised around parsing HTML for decades and writing HTML feels better than the raw DOM API, so... true or not, is is worth it at all?

Thought it's time to test assumptions and hypotheses, both in extreme and more realistic scenarios. An extreme scenario is one where you render a view tens of thousands of times on a page. In a realistic scenario, you render a view once.

The setup

Two simple functions on the scene. One builds the view by hand with createElement, setAttribute, appendChild, the other generates the same structure with a single HTML template string.

// DOM API version (shortened)
const domFn = () => {
  const container = document.createElement('div');
  target.appendChild(container);
};

// HTML template version (shortened)
const htmlFn = () => {
  target.innerHTML = `
    <div>
      <header><h1>Dashboard</h1></header>
    </div>
  `;
};

Next, rinse and repeat. Render 1, 2, 4, 8, up to 1024 times.

First-run: surprise surprise!

Before we get to which method is faster when we render many, many times, here is the shocking part: if you only set innerHTML once, it's nearly always faster than building the DOM structure one createElement at a time!

It's not just an opinion, it's hard numbers in various scenarios.

These links run on Stackblitz and show slighly different values than a local build. Feel free to download these projects and run the code yourself. The difference will be even more apparent on local.

Before you get too excited, look at the numbers, though. We're still talking less than 1ms difference, which is totally negligible for an end user.

This probably happens because HTML parsing is one of the most well optimised code paths in the browser. Turning a string into DOM nodes is fast. Meanwhile the DOM API version makes many small JavaScript calls before the engine has had time to optimise the function.

So for the first render the HTML version comes out ahead.

After that everything flips

As soon as the test repeats the operation more than once, the DOM API becomes faster.

This is where the JavaScript engine steps in. Once the DOM-building function has run a couple of times the engine fully optimises it. The series of createElement and appendChild calls becomes predictable and efficient.

The HTML version cannot use the same advantage. It always has to parse the whole template again. So from two runs onwards the DOM API pulls ahead and keeps widening the gap as the number of runs increases.

The same pattern shows up locally and on StackBlitz. The exact numbers shift, but the behaviour is identical.

What this means in practice

HTML strings are not slow. Quite the opposite. Browsers can parse a view so quickly that the first render can match or beat manual DOM calls. This is useful because typical applications build a view once, not hundreds of times in a loop.

For repeated updates or very frequent re-renders the DOM API becomes the better choice. Once the engine optimises the function it avoids parsing costs and becomes more stable.

In most real apps the difference is small enough that the choice comes down to clarity. If a view is easier to express as a template string, it is a perfectly reasonable approach. You are not paying a penalty for using it.

Learn More


	Web Components with one Simple Function
	Do you think Observables suck? Read this!
	A Web Developer's guide to Stream-Oriented Programming

Is your JS Framework slowing you down when you render something complex? Rimmel.js allows you to create Custom Sinks to render anything you want the exact way you want https://stackblitz.com/edit/rimmel-table-powersink

Dario Mannu — Tue, 04 Nov 2025 15:16:12 +0000

stackblitz.com

Working with WebSockets? No, it's never been simpler than this, ever! https://stackblitz.com/edit/simplest-chat-app-deno-rimmel

Dario Mannu — Tue, 28 Oct 2025 21:22:24 +0000

stackblitz.com

Workinng with WebSockets? No, it's never been simpler than this, ever! https://stackblitz.com/edit/simplest-chat-app-deno-rimmel

Dario Mannu — Tue, 28 Oct 2025 21:21:08 +0000

stackblitz.com

Rediscovering Effect Management with Effect Maps

Dario Mannu — Tue, 28 Oct 2025 18:54:20 +0000

Many programming paradigms revolve around a single idea — whether that’s composition, purity, dataflow, or state isolation. But there’s one recurring question that keeps surfacing in every new language or framework: how do we manage effects?

Effects are the unavoidable “real world” part of computation. They’re what make your program do something rather than just describe something. Logging, rendering, HTTP calls, I/O, and even user interaction — all are effects.

Functional programming tried to solve this decades ago. Imperative programming ignored the problem entirely. Stream-Oriented Programming (SP) does something different: it turns effects into maps.

The Problem with Traditional Effect Management

If you’ve ever written pure functional code, you know that separating logic from effects isn’t as simple as it sounds. In theory, functions should be pure and side-effects handled by monadic constructs such as IO, Task, Future, or similar abstractions. In practice, the code often turns into a tangled web of type constructors and continuations, all just to print a line or fetch data.

The monad pattern elegantly expresses effectful computation as data, but it also forces you to wrap and unwrap effects through chained continuations. Free and freer monads attempted to improve this by deferring interpretation — allowing you to “describe” effects and then interpret them later — but this only moves the complexity around. The price is boilerplate and a significant gap between your logic and what it actually does.

The essence of the problem: you have to manually organise and synchronise effects.

This is the hidden cost of functional purity. You must either:

Thread effects explicitly through monadic bind chains (flatMap/>>=), or
Defer them into abstract syntax trees (via Free/Freeer monads), or
Manage continuations to preserve purity across asynchronous boundaries.

That’s a lot of ceremony just to say “print this after reading that”.

HTML: The Most Powerful Effect Language Ever Created

Web developers, ironically, have been dealing with effects all along — effortlessly.

Every <button>, <input>, and <img> in HTML is an effect declaration. Each element describes what the program should do in the world — display text, handle clicks, submit forms — while keeping logic and structure separate.

HTML doesn’t execute effects, it declares them. That’s the key.

Stream-Oriented Programming builds on this insight. Instead of separating logic and effects through abstract monadic constructs, SP integrates them using Effect Maps — templates that directly describe how streams (logic) connect to the world (effects).

In this view, HTML isn’t just a markup language — it’s an Effect Declaration Language. Every element, attribute, and event handler is an entry in the global effect map of your program.

From Functions to Streams

In SP, logic isn’t built from functions, it’s built from reactive streams. Streams are continuous values over time — observable sequences that represent both data, relationship and transition.

The major conceptual shift is this:

Instead of passing functions around, you pass streams that continuously receive and emit values.

That means composition happens naturally. When you connect two streams, their relationship over time defines the behaviour — without rigidly defined "continuations".

So while in functional programming you might see something like:

readLine()
  .then(input => input.toUpperCase())
  .then(println)

In SP, you’d simply declare:

stream echo = pipeline(
  map(source => `You said: ${source}`)
)

effects`
  stdin=${echo}
  stdout=${echo}
`

What Is an Effect Map?

An Effect Map is a declarative structure that connects both ends of your streams to the external world. Think of it as a topological description of your application’s I/O system.

Each key in an effect map corresponds to an effect endpoint — for instance, a DOM element, a console output, or a cloud event stream. Each value corresponds to a stream that feeds or reacts to that endpoint.

Why It Works So Well

SP defines state and logic as streams, which removes the need for continuations entirely. There’s no “after this, do that” — there’s just data flowing through pipelines and their intrinsic relationships naturally define what happens before or after (think of RxJS operators like merge, withLatestFrom, combineLatest).

So, effects are synchronised not by explicit control flow, but by the natural composition of streams. When one emits, another reacts. When nothing emits, nothing happens.

This makes SP radically simpler for effectful programs: you get a model that is both reactive and declarative, with even more structural clarity than ever.

Comparing to Free and Freer Monads

Free and freer monads aim to separate effect description from effect interpretation. You define an algebra of effects (e.g., Read, Write, Delay), build a program as a tree of these, and then provide an interpreter that executes them.

Example (simplified pseudocode):

data Console a
  = Read (String -> a)
  | Write String a

type Program = Free Console

program = do
  line <- liftF (Read id)
  liftF (Write ("You said: " ++ line))

In SP, the same idea collapses into something simpler:

// pseudo language
main {
  stream echo = pipeline(
    map(source => `You said: ${source}`)
  )

  return nativeml`
    stdin=${echo}
    stdout=${echo}
  `
}

The `(inputs) => Template Maps` Pattern

At its core, every SP program follows the same structure:

(inputs) => Template Maps

Inputs are parameters or streams from the outside world — user events, messages, data feeds. The template map declares how these inputs feed into the application’s reactive logic, and how their results feed back out.

This can scale from a trivial echo example to full reactive systems, web apps, or distributed services. The underlying concept stays the same: every program is a composition of streams mapped onto effect templates.

That means an SP runtime for native, cloud, or server environments can use an HTML-like template syntax to describe effect connections — stdin, stdout, file, socket, topic, db — without needing to reinvent the language each time.

HTML already solved the hard part: declaratively describing what should happen and where.

Generalising Beyond the Browser

Imagine defining a microservice using the same principles:

stream users = pipeline(
  query("users")
)

stream active = users.pipe(
  filter(u => u.active)
)

apiml`
  <http method="get" path="/api/users" handler="${users}" />
  <stdout>${active}</stdout>
`

If you swap out the apiml template for another environment, the same logic runs elsewhere — in a CLI, a worker, or a serverless endpoint.

This is what makes the model portable. The HTML-like language isn’t tied to the DOM; it’s just a declarative schema for effects.

Why This Matters

We’ve reached a point where logic is easy, but effects are hard. In most modern systems, the actual business logic of a program is tiny compared to the infrastructure code needed to orchestrate events, side-effects, and state synchronisation.

Stream-Oriented Programming cuts through that by collapsing effect management into its natural form — a mapping between streams and their destinations. You no longer “manage” effects; you describe them.

This has several implications:

Composability: effect maps compose just like HTML fragments.
Transparency: every effect is visible in the template; nothing hidden in callbacks.
Portability: the same logic can target browser, server, or native backends.
Testability: streams can be simulated and observed without touching real I/O.
Extensibility: new effect types can be declared simply by extending the template vocabulary.

From Templates to Topologies

Effect maps aren’t just about syntax — they’re about topology.
They describe how data flows through a system, not just what functions run. This allows compilers or runtimes to visualise, optimise, or even distribute the system automatically.

An SP compiler could, for instance:

Detect if two streams form a feedback loop and isolate them.
Parallelise independent streams automatically.
Move effects to edge nodes or client devices dynamically.

Once the program is a map, the runtime can reason about it.
That’s something monadic chains can’t do, because the structure is hidden inside control flow.

The Future of Effect Languages

HTML’s accidental genius was that it separated description from execution. SP borrows that insight and extends it to all domains. Whether it’s rendering UI, running cloud workers, or wiring hardware, the same idea applies: effects are declared, not controlled.

As programming continues to shift toward reactivity and distribution, the need for clear, declarative effect systems grows. Stream-Oriented Programming offers a novel model that is not only simpler, but more general: an architecture where every effect is a node in a living map, every logic is a stream, and every application is the composition of both.

Closing Thought

Effect Maps aren’t an abstraction over effects; they’re an expression of them.
By treating logic as streams and using templates as maps, Stream-Oriented Programming eliminates one of the oldest dichotomies in computer science — between pure logic and messy side-effects — and replaces it with a single, flowing system that simply says:

inputs → streams → effects

And perhaps that’s all we ever needed.

Learn More


	From callbacks to callforwards: reactivity made simple?
	State Management and the Mixed Wastewater Problem
	A Web Developer's guide to Stream-Oriented Programming

Contrarian JavaScript Frameworks: The Top 3

Dario Mannu — Wed, 22 Oct 2025 14:30:00 +0000

Every Friday morning, some junior developer trying to get noticed drops yet another “Top JavaScript Frameworks” list.

Same line-up every time: Angular, React, Vue, Svelte, maybe Solid if they’re feeling bold. It’s like Groundhog Day for frontend devs.

So let’s break the loop, shall we?

Here are three frameworks/UI libraries that don’t quite play by the rules. Each one does things in a surprisingly different way that's worth a note.

To run a comparison, we’ll pick a random UI task and see what their approach is like: let's create two buttons that, when both clicked, enable a third one.

HTMX — The Antiscript

Some people believe HTMX is here to kill JavaScript, but what it really wants is to stop you writing it.

Instead of functions and event listeners, you describe behaviour directly in your HTML using attributes like hx-get, hx-trigger, and hx-swap. It lets HTML talk to your backend — no scripts, no build tools, just markup that acts.

Here’s how the same two-buttons-unlock-third example would look in HTMX’s world:

<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/htmx.org@1.9.10"></script>
</head>
<body>
  <div id="app" hx-get="/buttons" hx-trigger="load" hx-swap="outerHTML"></div>
</body>
</html>

And on the server, you’d have something like this (using Express for simplicity):

import express from 'express';
const app = express();

let clicked1 = false;
let clicked2 = false;

function renderButtons() {
  const bothClicked = clicked1 && clicked2;
  return `
  <div id="app">
    <button hx-post="/click1" hx-swap="outerHTML" hx-target="#app">Button 1 ${clicked1 ? '✔️' : ''}</button>
    <button hx-post="/click2" hx-swap="outerHTML" hx-target="#app">Button 2 ${clicked2 ? '✔️' : ''}</button>
    <button ${bothClicked ? '' : 'disabled'}>Button 3</button>
  </div>`;
}

app.get('/buttons', (req, res) => {
  res.send(renderButtons());
});

app.post('/click1', (req, res) => {
  clicked1 = true;
  res.send(renderButtons());
});

app.post('/click2', (req, res) => {
  clicked2 = true;
  res.send(renderButtons());
});

app.listen(3000);

Each button click sends a small POST request to the server, which updates its state and sends back the new HTML fragment. The browser replaces the old section automatically.

That’s the real spirit of HTMX: make HTML dynamic again, by letting the backend do the work.

Hyperscript — Like plain English

From the same folks behind HTMX comes Hyperscript.
If HTMX is "HTML that acts", Hyperscript is "HTML that talks".

You literally write scripts in plain English:

on click add .active to me`, `wait 2s`, `remove @disabled from #btn3`

Readable, no build step, no imports, no framework gymnastics.

It’s imperative, surprisingly expressive, and kind of brilliant in its simplicity.

<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/hyperscript.org@0.9.12"></script>
</head>
<body>
  <div id="app">
    <button id="btn1" _="on click add .clicked to me then call check()">Button 1</button>
    <button id="btn2" _="on click add .clicked to me then call check()">Button 2</button>
    <button id="btn3" disabled>Button 3</button>
  </div>

  <script type="text/hyperscript">
    def check()
      if #btn1.hasClass("clicked") and #btn2.hasClass("clicked")
        remove @disabled from #btn3
      end
    end
  </script>
</body>
</html>

Run on Stackblitz

That’s HTML that reads like English and behaves like JavaScript.
It doesn’t try to abstract your logic — it just makes it human-readable.

Rimmel — The Stream-Oriented Pioneer

Third on the list comes Rimmel, and it’s playing quite the opposite game.

Rimmel is built on the idea that "everything is a stream", based on Stream-Oriented Programming: a novel paradigm with no state objects, no "actions" and no virtual DOM, only pure dataflows that describe how your app logic behaves over time.

If you’ve ever worked on large and complex applications with RxJS (eg in Angular), you may be surprised to see how simpler it is in comparison.

import { BehaviorSubject, combineLatest, map } from "rxjs";
import { rml } from "rimmel";

const Component = () => {
  const first = new BehaviorSubject(false);

  const second = new BehaviorSubject(false);

  const disabled = combineLatest({first, second}).pipe(
    map(({first, second}) => !(first && second))
  );

  return rml`
    <div>
      <button onclick="${first}">Click</button>
      <button onclick="${second}">Both</button>

      <button disabled="${disabled}">To enable</button>
    </div>
  `;
};

document.getElementById('app').innerHTML = Component();

Run on Stackblitz

There’s no diffing, no re-rendering, no setState. Just events and data flowing.
It’s pioneering a novel paradigm — Stream-Oriented Programming — which reduces the whole process of software development to a mere composition of streams.

Which One Fits You

If you like HTML doing the heavy lifting you may have a very good time with HTMX.
If you want to try the breeze of scripting in plain English, perhaps you're writing something for non-developers, Hyperscript is genuinely refreshing.
If you can think of events and data in terms of streams, if you want total control and you're creating complex applications, you may rely on Rimmel's strong computational model.

The Small Print

HTMX keeps HTML front and centre, but it only gets you so far — real logic still needs scripting and your users better have a fast, reliable internet connection that's always on.
Hyperscript bridges that gap in a surprisingly natural way, though it’s best for small to medium projects. Complex logic is still complex logic. Don't expect everyone to understand it just because it's English.
Rimmel shines for its sound computational model. It's simple to start, it's rock-solid at scale, but you need to learn how streams and RxJS work if you haven't already, which aren't exactly as simple as plain English.

So, now we found a few frameworks that don’t try to be “the next React”. They’re doing their own thing, greatly challenging the status quo — and that’s what makes them worth knowing.

Can you suggest other frameworks/UI libraries that break all rules and bring something truly different to the scene?

Learn More


	Reactive Streams: Functional vs Imperative
	Do you think Observables suck?
	Vanilla JS is unscalable. Here is why

A Web Developer's guide to Stream-Oriented Programming

Dario Mannu — Wed, 15 Oct 2025 14:30:00 +0000

So you're interested or curious about Stream-Oriented Programming (SP).

SP is a novel programming paradigm that makes it easy to create complex applications with advanced sync+async interactions.

An architectural mental model

There is a core mantra in this paradigm: "Everything is a Stream".

Obviously we still have strings, numbers, booleans and functions, but it's a mental model which allows us to focus on the building blocks of an application and their relationship rather than their shape and nuances.

What is a Stream?

A Reactive Stream is a high-level data construct that can:

(optionally) listen to events/messages
(optionally) apply some transformations
(optionally) emit data.

There are various implementations of reactive streams. In the JavaScript world the most well-known, mature, battle-tested and ubiquitous implementation is RxJS.

Other incarnations of streams could be used, including Callbags, Callforwards and you can create your own, but we'll stick with RxJS in this guide for practical purposes.

N.B.: RxJS is known to be one of the most difficult JavaScript libraries to master, but we'll show you how that's no longer the case in SP, where streams are first-class and not just yet another async primitive developers have to stitch to the rest.

In SP the Observable is a low-level, read-only stream that you should probably never need to instantiate directly in your applications.

Two other types of stream will play a fundamental role in all stream-oriented development. Subject and BehaviorSubject.

Subject is the most basic implementation of a reactive stream that looks like data in => data out.

BehaviorSubject is the stateful stream. You can think of it as the universal state manager and you'll use it extensively.

If you come from React, this is a bit like the functional equivalent of useState, but infinitely more powerful.

Operators (the top 3)

Just like you have separation of concerns as a general principle in software engineering, you have an equivalent in Stream-Oriented programming, too, where you separate architecture from implementation.

The architecture of an application is a graph of streams.
The anatomy of a stream is a pipeline of operators, which break down all logic to a sequence of steps.

map

The most basic and important operator is map: it takes the input, applies a transformation function and re-emits the result synchronously. It behaves like Array.map, but for event streams.

Here is a simple stream that doubles its input.

const doubler = new Subject<number>().pipe(
  map(x => 2*x)
);

filter

The second most important operator is filter. Just like Array.filter, this takes a boolean function to decide synchronously whether to re-emit a given event to the next step or not.

Here is a stream that takes numbers and only lets the odd ones through:

const odds = new Subject<number>().pipe(
  filter(x => x&1)
);

scan

This is like a "progressive" Array.reduce. It performs the same functionality, just one-by-one, re-emitting synchronously a reduced value as data comes in.

This operator will be used extensively nearly every time you need a state machine.

Following is a basic "total" stream that takes numbers in, adds them up and emits the sum of all items received.

const total = new BehaviorSubject<number>(0).pipe(
  scan((total, newValue) => total +newValue)
);

Here the initial value of the BehaviorSubject will be also used as the initial value of the operator, so the whole stream will emit 0 initially.

Following is a "mergeUp" stream that takes objects in and merges their key-values into a single "state" object:

const mergeUp = new BehaviorSubject<number>({}).pipe(
  scan((a, b) => ({...a, ...b}))
);

Other operators

If you know JavaScript Promises you already know operators: Promise.all, Promise.allSettled, Promise.then, Promise.catch are all everyday examples of operators used by Promises.

Streams can have their own. Since there are many more use cases for reactive streams than promises, there are also many more operators. RxJS sports around 200 but you'll actually count on your fingers the number of actual operators you'll use on a daily basis.

Composing Streams

Streams have a key property that makes them perfectly suited to create applications: they can be composed, which means you can wrap many of them inside a larger stream which, seen from the outside, will also be a stream that in turn can be composed again, and again.

Everything is a Stream

Back to the mantra of the paradigm. What does it mean that everything is a stream? Is that something like a "one size fits all" for programming?
Essentially... yes.

Everything stream-oriented programming is concerned about can be represented as a stream. A button, a textbox, a dialog box, a view, a page, a route, a router, an application.

This is what makes stream-oriented programming as simple as building a house with LEGO bricks. They all fit together easily because they all have the same pluggable interface.
Now, imagine using LEGO bricks if they all had slightly different sizes or shapes and you couldn't fit them together. That's object-oriented programming, or various other mixed paradigms. Every object has its own interface, its own methods with their names, their return values, or callbacks, getters and setters with various names, let alone sagas, stores, generators. You have to read the documentation of each, find the correct method to use, its parameters, its semantics. Sync methods work differently from async ones, some return promises, others return callbacks.

In Stream-Oriented programming all streams have the same interface, Stream<I,O>, so connecting them together becomes trivial.

A collection of basic and advanced Dialog Boxes demonstrates how those can be treated as streams and integrated in various UI scenarios.

Solving the "glue code" problem

In a world where many objects each speak a different "language", creating an application means writing a log of "glue code" which is code that converts data emitted by one object and makes it usable in another, according to its semantics.
A large amount of glue code necessarily means a larger bug surface and more code to maintain.

Stream-Oriented programming solves this elegantly by making streams all speak the same language and letting frameworks take care of connecting them behind the scenes.

Streams and Templates

Streams on their own don't do anything. They are lazy, so they won't typically start processing any data until they get connected to the real world.

This connection is what templates are for.

A template is a declaration of where we want to connect our streams. RML is an HTML-based template language designed to connect reactive streams in HTML.
It allows you to put streams nearly anywhere and make them work with the DOM.

The simplest example of a reactive stream in action is the classic "click-counter": a button that counts how many times you clicked it.

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

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

  const double = count.pipe(
    scan(x => x*2)
  );

  const even = count.pipe(
    map(x => ~x&1)
  );

  return rml`
    <button onclick="${count}"> click me </button>

    count: <span>${count}</span>
    double <span>${double}</span>
    is even: <input type="checkbox" checked="${even}">
  `;
};

document.body.innerHTML = ClickCounter();

To see this in action you can play with this running example.

The above was probably enough for a start, the rest is just larger components with more functionality, more streams and novel design patterns.

To get started, you can learn more about the first JavaScript library for Stream-Oriented Programming, Rimmel.js, on Github or various posts here on dev.to

Follow for more, reach out to say hi, show the world what you can do with streams before others!

Learn More


	You might actually not like React
	Effect Maps: How Stream-Oriented Programming rethinks effect management
	From Plain Functions to Reactive Streams: a mindset change with a thousand benefits

Building a Stream-Oriented, Infinite-Scrolling DEV.to reader

Dario Mannu — Sat, 11 Oct 2025 11:21:28 +0000

This is a short, beginner-friendly walk-through for building an infinite scroll reader that loads articles from dev.to, showcasing Stream-Oriented Programming (SP).

This is a great way to learn how streams can replace traditional event handlers, callbacks, and state variables with something cleaner and easier to reason about. You can run the full example here: https://stackblitz.com/edit/dev-to-infinite-scroll-component

Why streams?

Most UI frameworks revolve around components, lifecycle hooks, and state updates. Rimmel.js is a stream-oriented UI library that takes a different approach: everything (user actions, async data, DOM updates) is treated as a stream of values that flow through transformations. Instead of thinking in terms of components "reacting" to events, you just describe how data moves. This eliminates glue code and makes your app easier to extend, debug, and test.

In SP style, logic is expressed as data pipelines, not as nested callbacks with shared state. You get a clear separation between producers (events), transformers (logic), and consumers (UI updates).

Step 1: Imports and a tiny Event Adapter

Let’s start at the top of main.ts. We import RxJS tools and Rimmel helpers.
RxJS brings us essential stream operators like scan (keep track of state as data flows through) and concatMap (keep async events in the right order), while Rimmel lets us connect those streams directly to the DOM.

Next comes a small but powerful pattern called Event Adapter, which is used to turn the DOM's Event objects into a predictable stream of data, in the exact format we want.
We'll define one such event adapter called Next that converts scroll events into sequential page numbers.

const Next = inputPipe<Event, number>(
  scan(x => x + 1, 0),
);

Before diving deeper, it’s important to understand what inputPipe really is. Unlike RxJS’s .pipe() method, which applies transformations on the output of an Observable, inputPipe is a Rimmel utility that sets up a pipeline on its input. It feeds a target stream with processed data as events occur.

Why `scan`?

scan is an RxJS operator that keeps a running state over time, similar to reduce, but for continuous streams. Here, it starts at 0 and increments each time the adapter receives an event. Instead of raw DOM events, we now get a stream of clean, numeric values: 0, 1, 2, 3… which represent page numbers to fetch. It’s a simple and declarative way to generate sequential data without mutable counters or shared state.

Step 2: A simple article template

The articleTemplate turns dev.to API results into HTML using Rimmel’s rml syntax. It’s a pure function: data in, markup out.

const articleTemplate = ({ url, title, tag_list, description, social_image, user }) => rml`
  <article>
    <h3><a href="${url}">${title}</a></h3>
    <img class="social-image" src="${social_image}">
    <p>${description}</p>
    <div class="notes">
      Tags: <span>${tag_list.join(', ')}</span>
      <div>Posted by <a href="https://dev.to/${user?.username}">${user?.name}</a></div>
    </div>
  </article>
`;

Step 3: The page stream – fetching and rendering

Now we define a stream named page. It receives numbers (our page indexes) and emits HTML as output. Every time it gets a new number, it fetches that page from dev.to and turns the results into HTML.

const page = new Subject<number>().pipe(
  concatMap(page => fetch(`https://dev.to/api/articles?page=${page}&per_page=10`)),
  concatMap(response => response.json()),
  map(posts => posts.map(articleTemplate).join('')),
) as Observer<number> & Observable<HTMLString>;

Here’s what happens step by step:

Subject is both an event receiver (Observer) and data emitter (Observable).
concatMap ensures requests happen one after another, maintaining order. If page 3 starts before page 2 finishes, it waits, keeping results sequential.
The second concatMap unwraps the fetch Response into JSON.
map transforms the JSON array into HTML via our template.

Why `concatMap`?

concatMap is crucial for ordered async work. It queues up asynchronous operations (like fetches) and executes them in sequence. If you used mergeMap or switchMap instead, requests could overlap or cancel each other, breaking pagination. concatMap ensures smooth, predictable flow (page 1, then page 2, then page 3) just as users expect when scrolling.

This pipeline describes what to do with input numbers, not how or when. The order and timing are handled by the stream itself.

Step 4: Connecting the UI

The app template includes a <main> element and uses AppendHTML: a Rimmel sink that appends whatever HTML the stream emits into the DOM.

<main>
  ${AppendHTML(page)}
</main>

You don’t manually touch the DOM. When new HTML arrives, Rimmel will know how to update it.

Step 5: The in-view marker that triggers new pages

To make it scroll automatically, we use a custom element called <inview-marker>. It emits an event when it enters the viewport. We connect that event to our Next adapter so that every time the marker comes into view, the next page number flows through the pipeline.

<inview-marker oninview="${Next(page)}"></inview-marker>

That’s it: no scroll listeners, timers, or counters. Just streams.

Step 6: The custom element logic

In lib/in-view-marker.ts, we register the element and use the browser’s IntersectionObserver API. When the element appears, it emits an inview event.

RegisterElement('inview-marker', ({ oninview }) => {
  const emit = callable(oninview);

  const load = ({ target }) => {
    new IntersectionObserver((entries) => {
      entries.forEach(e => e.isIntersecting && emit(new Event('inview')));
    }).observe(target);
  };

  return rml`<marker rml:onmount="${load}"></marker>`;
});

This small bridge connects browser visibility events to your reactive stream world.

Step 7: Bootstrapping the app

Finally, the app mounts itself by setting its root element’s innerHTML to the Rimmel template output.

document.getElementById('app').innerHTML = App();

Everything is reactive from that point forward. The first page loads, the marker enters view, and new pages stream in.

Why this pattern improves code quality

There’s no tangled state or complex lifecycle management. Each piece does one thing:

The adapter converts events into numbers.
The stream defines how data flows.
The sink updates the DOM.
The marker triggers when needed.

Because every link in the chain is declarative, the behaviour is transparent and easy to debug. If you ever want to change behaviour—like preloading or adding filters—you modify one stream operator instead of rewriting your UI logic.

Run it live

Try the complete demo here: https://stackblitz.com/edit/dev-to-infinite-scroll-component

Scroll down and watch new posts load automatically, one clean stream at a time.

If you appreciate the clean, modern approach of the stream-oriented paradigm, join a growing community of forward-thinking developers and give the project a ⭐ on GitHub

Learn More


	Effect Maps: How Stream-Oriented Programming rethinks effect management
	Lit vs Rimmel: tagged templates in OOP vs SP
	Stream Oriented Programming: an introduction

From Plain Functions to Reactive Streams: a mindset change with a thousand benefits

Dario Mannu — Wed, 08 Oct 2025 12:57:02 +0000

Functions have been at the core of computer programming since the dawn of time. From the simplest arguments in -> results out pure functions to async functions that return future values, to reentrant generators that can dynamically produce any number of results over time, sync or async.

There is one thing functions share in common: they lack any sort of event awareness.

Bad news in a world where literally everything revolves around events and a whole chain of reactions to be executed in response: a button click, a file upload, a form submission, a page refresh or a ticking timer.

Streams can handle a multitude of events in input, perform some processing and emit some results. They can take the output of other streams as their own input and compose up new derived streams.

A great analogy can be drawn with water pipelines or electrical circuits. Reactive streams treat data just like pipeline channel water and circuits enable the controlled flow of electricity.

From simple function to simple stream

Let's take a function that returns its argument doubled:

// imperative
function double(n: number) {
  return n * 2;
}

An equivalent reactive stream that takes numbers and emits double the input value looks something like this:

// stream-oriented
const double = new Subject<number>().pipe(
  map(n => n * 2)
);

You may have noticed how streams take a single parameter, which seems a bit of a limitation given that functions can take many. This can be mitigated by passing objects instead of plain values and in practice, given that a stream should represent a single "thing", this won't even feel like a limitation.

The difference is small, subtle, but fundamental. In the former case it's an imperative call that triggers the function and handles the result, in the latter case, the stream is something that can be fed and subscribed to, ideally by the framework.

From async functions to streams

The difference between sync or async streams is not as critical as it is between functions and async functions. At the end of the day, you combine streams the same way with the same operators (such as zip, combineLatest, withLatestFrom, etc) in a seamless way.

Perhaps one little exception is when you use promises inside streams. Say you have one that calls an API and propagates its results. You can't just use the map operator, as it would not wait for any fetch() call to resolve. What you want to use instead is the switchMap operator, which also cancels any in-flight operation before starting the new one.

// imperative
function getData(id: number) {
  return fetch(`/data/${id}`).then(r => r.json());
}

// stream-oriented
const dataStream = new Subject<number>().pipe(
  switchMap(id => fetch(`/data/${id}`).then(r => r.json()))
);

Actually this is an overly simplified example, because there's so much more to using fetch and handling errors, but we only wanted to focus on the structure now and how to get from an async function to a stream. There is a collection of examples showing how to fetch data and handle retries and errors. Perhaps we'll write about those in more detail some day.

So, what's the key difference, in summary? In one case, in the imperative paradigm, you "call" the getData() function and await the result. In the stream-oriented paradigm, you don't call anything. You only create pure streams and declare how you'd like those to be called. An example could be like the click on a button triggers the stream and its output goes into a <div> somewhere on the page. HTML templates serve this exact purpose.

Benefits of thinking in streams

Embracing streams over traditional functions brings several practical and architectural benefits:

1. Event awareness and composability. Streams integrate seamlessly with events, which are the backbone of interactive systems. They let you model complex workflows as a network of dataflows rather than a series of callbacks.

2. True asynchronicity. Streams naturally handle asynchronous data over time without forcing developers into nested then chains or async/await boilerplate.

3. Declarative clarity. Instead of describing how to react to each event, you define what should happen when it does. This leads to more maintainable, predictable, and testable code.

4. Error resilience and recovery. Operators like catchError, retry, or switchMap give you built-in tools to manage transient errors or cancellation logic gracefully.

5. Framework synergy. Modern UI and data frameworks—especially those aligned with reactive programming—can automatically connect streams to views, enabling state updates without explicit imperative glue code.

6. Better scalability. As systems grow, adding new event sources or transformations doesn't require changing existing logic. Streams let you plug in new flows like components in a circuit.

By shifting from functions to streams, you're no longer writing programs that merely execute from top to bottom; you're designing living systems that react, evolve, and adapt continuously in response to their environment.

Learn More


	Stream-Oriented Programming: An Introduction
	Contrarian JavaScript Frameworks: The Top 3
	A Stream-Oriented App — building in public

A Messagebus? Using Observable Streams? https://stackblitz.com/edit/tops-example #JavaScript #WebDev #WebDevelopment #FrontEnd #RxJS

Dario Mannu — Mon, 15 Sep 2025 19:52:06 +0000

stackblitz.com

Why Angular Isn’t the Observable Framework You Think It Is

Dario Mannu — Sat, 13 Sep 2025 17:55:23 +0000

When many developers hear "observables", one framework often jumps to mind: Angular. It’s been closely tied to RxJS for years, marketed as the reactive framework of choice.

But here’s the catch: Angular doesn’t actually live in the observable world. Instead, it constantly forces you to switch gears — juggling RxJS streams on one side, and its own reactivity model (async pipes, now signals) on the other.

And that’s where the cracks start to show.

You’re wiring async pipes everywhere.

You’re managing BehaviorSubjects by hand.

You always have to unsubscribe.

And now, with signals, you’re asked to learn yet another reactive abstraction.

It’s not seamless. It’s not elegant. And it’s certainly not the pure observable experience RxJS developers dream about.

Enter Rimmel.js: Built on Streams from Day One

Imagine a UI library where you don’t need two paradigms. Where event sources and data sinks just bind to streams and your UI is simply a declarative destination for your data. That’s what Rimmel.js was designed to do.

This isn’t Angular with a bolt-on async pipe. This is [stream-oriented programming] — where observables aren’t guests at the table, they are the table.

And the difference is dramatic.

Angular vs Rimmel in Practice

Counter Example

Angular version

@Component({
  selector: 'app-counter',
  template: `
    <button (click)="increment()">+</button>
    <span>{{ count$ | async }}</span>
  `,
})
export class CounterComponent {
  private count = new BehaviorSubject(0);
  count$ = this.count.asObservable();

  increment() {
    this.count.next(this.count.value + 1);
  }
}

Rimmel.js version

const Counter = () => {
  const total = new BehaviorSubject(0).pipe(
    scan(x=>x+1)
  );

  return rml`
    <button onclick="${total}">
      click me <span>${total}</span>
    </button>
  `;
};

No async pipes. No imperative methods. Just streams, neatly and directly connected to the UI.

Angular Signals vs Rimmel Observables

Angular’s recent push for signals looks shiny at first glance. They promise "fine-grained reactivity" and "fewer recalculations". But here’s what actually happens:

You now have two reactive paradigms: signals and RxJS.

Data from an observable still has to be bridged into a signal.

Events from your UI still go through imperative steps.

Your app ends up with split logic: streams for async work, signals for rendering.

You learn one reactive model, then constantly translate it into another.

That’s unnecessary complexity.

With Rimmel.js, you don’t need signals at all. Observables are already expressive, composable, and powerful enough to handle both async data and complex state. By cutting out the extra layer, you stay in one mental model: streams in, streams out.

The result? Code that feels neat, light, direct, and more predictable.

Why This Matters for Developers

Rimmel.js gives you:

True first-class observables. No pipes, no wrappers.

Cleaner code. Every part of your app speaks one language: streams.

Future-proof thinking. Stream-oriented programming scales elegantly with complexity.

Instant familiarity. If you know RxJS, you already know most of Rimmel.js.

Instead of wrestling with multiple reactivity systems, you can finally focus on what matters: building features, not boilerplate.

The Takeaway

Angular might be the framework you think of when you think "observables", but the reality is that Angular’s observable support is skin-deep. It keeps you juggling async pipes, signals, and RxJS — a constant context-switching tax.

Rimmel.js flips that script. By embracing a stream-oriented paradigm, it turns observables into the natural fabric of your application. Your knowledge of RxJS doesn’t just transfer — it thrives.

Learn More


	A Web Developer's guide to Stream-Oriented Programming
	Web Components with one Simple Function
	From callbacks to callforwards: reactivity made simple?

DEV Community: Dario Mannu

Composable UI contracts and an algebraic approach to layout, style and interaction

The core idea: UI as responsibility contracts

Paradigms, not properties

Concerns: the dimensions of responsibility

Layout concerns (example set)

Style as authority, not decoration

Style concerns (example set)

Interaction and animation as contracts

Interaction and motion concerns (example set)

Components vs layout paradigms

Schemes and themes: separating meaning from values

Accessibility as an invariant, not a feature

Responsive design = paradigm substitution

A model to create design systems and frameworks

What this enables

What comes next

Learn More

HTML strings vs the DOM API: from a small benchmark to a surprising result

The setup

First-run: surprise surprise!

After that everything flips

What this means in practice

Learn More

Is your JS Framework slowing you down when you render something complex? Rimmel.js allows you to create Custom Sinks to render anything you want the exact way you want https://stackblitz.com/edit/rimmel-table-powersink

Working with WebSockets? No, it's never been simpler than this, ever! https://stackblitz.com/edit/simplest-chat-app-deno-rimmel

Workinng with WebSockets? No, it's never been simpler than this, ever! https://stackblitz.com/edit/simplest-chat-app-deno-rimmel

Rediscovering Effect Management with Effect Maps

The Problem with Traditional Effect Management

HTML: The Most Powerful Effect Language Ever Created

From Functions to Streams

What Is an Effect Map?

Why It Works So Well

Comparing to Free and Freer Monads

The (inputs) => Template Maps Pattern

Generalising Beyond the Browser

Why This Matters

From Templates to Topologies

The Future of Effect Languages

Closing Thought

Learn More

Contrarian JavaScript Frameworks: The Top 3

HTMX — The Antiscript

Hyperscript — Like plain English

Rimmel — The Stream-Oriented Pioneer

Which One Fits You

The Small Print

Learn More

A Web Developer's guide to Stream-Oriented Programming

An architectural mental model

What is a Stream?

Operators (the top 3)

map

filter

scan

Other operators

Composing Streams

Everything is a Stream

Solving the "glue code" problem

Streams and Templates

Learn More

Building a Stream-Oriented, Infinite-Scrolling DEV.to reader

Why streams?

Step 1: Imports and a tiny Event Adapter

Why scan?

Step 2: A simple article template

Step 3: The page stream – fetching and rendering

Why concatMap?

Step 4: Connecting the UI

Step 5: The in-view marker that triggers new pages

Step 6: The custom element logic

Step 7: Bootstrapping the app

Why this pattern improves code quality

Run it live

Learn More

From Plain Functions to Reactive Streams: a mindset change with a thousand benefits

From simple function to simple stream

From async functions to streams

Benefits of thinking in streams

Learn More

The `(inputs) => Template Maps` Pattern

Why `scan`?

Why `concatMap`?