DEV Community: Luciano0322

When Render No Longer Owns the Entire Data Flow

Luciano0322 — Mon, 22 Jun 2026 09:16:01 +0000

In frontend development, it is very easy to think of data flow and rendering as the same thing. After all, for most applications, the final goal is to display data on the screen. Data comes back from an API, gets written into state, the component re-renders, and the UI updates.

This path is so familiar that we often unconsciously assume:

The purpose of data changes is to trigger render.

But as an application scales, this assumption begins to crack. Data flow does not exist exclusively to serve the UI. In a complex system:

Some data changes simply update derived state.
Some trigger background tasks.
Some synchronize local caches.
Some orchestrate async resources.
Some happen entirely under the hood, with no need for the UI to ever know.

When every piece of data is forced to route back through a component—tangled up in render lifecycles, hooks, watchers, or effects—the architecture inevitably turns into a mess. This isn’t a flaw in React or Vue. It happens because, fundamentally, render was never meant to own the entire data flow.

Render Is a Consumer of Data Flow, Not the Owner

Over time, I've come to deeply embrace this mindset:

Render is just one side effect.

This sentence deeply changed the way I think about frontend architecture, because it reframes the core problem.

Render is, of course, extremely important. Without render, there is no visible output for the user. But from the perspective of a reactive system, render should never be the center of the data flow. It is only one possible side effect produced by data changes.

When a piece of data changes, the system may trigger a chain of reactions:

source state changes
        ↓
derived state updates
        ↓
effects run
        ↓
render may happen
        ↓
async work may continue

Render is one result of the system.
It is not the owner of the system.

However, many frontend architectures and usage patterns make us unconsciously treat render as the ownership boundary of data flow.

For example, in React, we often store data inside component state, then use useMemo, useEffect, and useCallback to manage derived data and side effects.

In Vue, the reactivity system is more fine-grained, but if the application’s data flow still revolves heavily around component scope, watch, watchEffect, or template consumption, data ownership can still become scattered.

This is not about whether a framework is capable or not.

It is about where the center of architectural thinking is placed.

Frameworks usually care about this question:

When should the UI update?

But when I was designing signal-kernel, the question in my mind was different:

After data changes, who should own the update logic?

These two questions may look similar, but they are fundamentally different.

Why Components Should Not Carry All Data Flow Responsibilities

Components are great at describing UI. They are good at composing views, receiving props, handling events, and presenting state.

But they are not ideal ownership boundaries for the entire data flow. This isn't obvious when your state is simple, but once derived state and async state start piling up, components are quickly crushed under responsibilities they were never meant to hold.

Consider a common flow like this:

userId changes
  → fetch user profile
  → fetch permissions
  → compute available actions
  → update form visibility
  → trigger validation
  → maybe render

If this entire flow is placed inside a component, it often becomes something like this:

useEffect fetch data
useMemo compute derived state
useEffect sync another state
useEffect trigger validation
conditional render

At first, this may still look acceptable. But as requirements grow, the component slowly turns into a data-flow scheduler.

It no longer only describes the UI. It also has to decide:

Who depends on whom?
Who should update first?
Which values can be recomputed?
Which side effects are allowed to run?
Which async work needs to be cancelled?
Which state must not drift?

At this point, the responsibility of the component has already gone far beyond render. And the most troublesome part is that these dependencies are usually not explicit. They are hidden inside hooks, watchers, callbacks, and dependency arrays.

The system may still work on the surface, but the ownership of the data flow has been shattered.

The Boundary Problem of Derived State

Derived state is where this architectural leak is most glaring. By derived state, I simply mean data that can be programmatically inferred from other data:

cartItems → totalPrice
userRole + permissions → availableActions
searchKeyword + filters + rawList → visibleList

Ideally, these are just nodes in a reactive graph. When source state changes, the derived state naturally marks itself as stale and recomputes only when necessary.

But in a render-centric codebase, these derivations are trapped inside components through useMemo, computed, or similar component-scoped mechanisms. This is fine in isolation. This is fine in isolation. The ownership boundary starts to blur, however, when that derived state is needed by an async task, a cache, or a business rule outside the UI layer.

Suddenly, state that looks like it belongs to the UI is actually carrying the weight of domain logic. This is the exact ambiguity of ownership I keep emphasizing.

It's About Ownership, Not Performance

When people talk about signals or fine-grained reactivity, the first thing that usually comes to mind is performance.React re-renders; Solid updates the DOM directly; Vue tracks dependencies precisely; Signals bypass unnecessary recomputations.

These are real, practical benefits. But over time, I’ve realized that performance is just the most visible byproduct. The actual paradigm shift is ownership.

Render-centric model: The UI owns the data flow. Data mutations must pass through the UI lifecycle (hooks, component scopes) before they can be organized, derived, and synchronized.
Graph-centric model: The reactive graph owns the data flow. Events trigger signals, signals derive a computed graph, and effects, resources, and renders are all simply downstream consumers.

This realization became my North Star while building signal-kernel. I wasn't trying to write another UI framework, nor was I trying to prove React or Vue wrong. I just wanted to answer one question:

If render is no longer the center of data flow, who should take over?

My answer is the reactive graph.

Let Render Return to Its Proper Position

When the reactive graph takes over, render is drastically simplified. It doesn't need to know how data is derived, it doesn't orchestrate update orders, and it doesn't juggle async consistency. It just reads the state it cares about and paints the screen.

This isn't about downplaying the importance of the UI. It’s about letting the UI return to what it's actually good at. In this model, the boundaries are strict:

Signal owns the source state.
Computed owns the derived state.
Resource owns the async state.
Effect owns the side effects.
Render owns the visual output.

By extracting data flow from the render lifecycle, we give data its own independent ownership boundary. This is the core semantic philosophy behind signal-kernel.

What This Means for React and Vue

For React developers, this pain point is acute. Because React is fundamentally render-driven, data-flow issues inevitably turn into interrogations about useState, useMemo, useEffect, dependency arrays, and re-render optimization. This is exactly why large React codebases suffer from dependency array fatigue, stale closures, and effect overuse.

For Vue, the situation is more nuanced. Vue already has a built-in reactivity system; ref, computed, and watch describe data dependencies beautifully. A Vue developer reading this might think: "Isn't Vue doing this already?"

To an extent, yes. Vue brought reactive graphs into mainstream application development much earlier. But there is a key distinction: Vue’s reactivity can be used independently, but its primary design context is still the Vue application model.

What signal-kernel explores is a framework-agnostic reactive graph. I'm not asking, "Should we use signals to update Vue components?" I'm asking, "Can we build a standalone data core that React, Vue, background jobs, async runtimes, and even AI agents can all consume simultaneously?"

That’s why the React and Vue adapters for signal-kernel are intentionally thin. A framework adapter shouldn't seize control of the data flow; it should merely bridge the graph to the UI.

A System You Can Actually Reason About

When render relinquishes control, you don't just get better performance—you get a system you can actually reason about. You stop asking framework-specific syntax questions and start asking architectural ones:

Is this source state or derived state?
Is this a synchronous derivation or an async result?
Is this a data-layer effect or a UI-layer effect?
Should this state live inside the component, or inside an independent reactive graph?

Conversely, when everything is pushed back into the component lifecycle, profound architectural flaws are disguised as hook usage questions:

How do I write this dependency array?
Why is this useEffect firing twice?
Should I wrap this in useMemo?
Is watchEffect too automatic?

These questions all have technical answers, but they mask the deeper, underlying problem:

Who is actually supposed to own this piece of the data flow?

Downgrading Render Into One of Many Outputs

UI frameworks are incredibly important. React, Vue, and Solid have all solved very difficult problems in their own dimensions.

But in complex frontend applications, we need to recognize one thing:

Render should no longer be treated as the only center of data flow.

Only when data flow has its own ownership can a system move from UI-driven state management toward graph-driven state ownership.

On the surface, signal-kernel is a signal library. But at its core, it is an exploration of how frontend data architecture can be rebuilt when render steps back and becomes just one kind of side effect.

In the next article, I will continue breaking down this problem:

When state, derived state, and effect are mixed together, how does a system gradually lose its boundaries?

From Signals to Ownership: Why I Built a Dataflow Kernel

Luciano0322 — Mon, 15 Jun 2026 07:17:57 +0000

When I first started building signal-kernel, I thought I was simply writing a signal library—a fine-grained reactive system not tied to any specific UI framework. On the surface, it had all the basic building blocks you would expect from a signal library:

Core primitives: Signal, Computed, and Effect
Mechanisms: dependency tracking and scheduling
Extensions: async resources and framework adapters

It could build a reactive graph, track dependencies, update derived state precisely when data changed, and bridge the result into React or Vue. But the deeper I dug into the implementation, the more I realized the real problem wasn't about building another signal library. The core question was actually this:

In a complex application, who should truly own the dataflow?

Fragmented Dataflow and the Derived State Problem

In modern frontend applications, dataflow often feels natural at first. API data comes back, gets written into state, and components render the result. If we need derived data, we use useMemo. If we need side effects, we use useEffect. If we need async requests, we use a query library, and if we need shared state, we introduce a store.

Individually, none of these solutions are wrong. React is not wrong. Vue is not wrong. TanStack Query is not wrong. Zustand and Jotai are not wrong either. The real problem appears when the system grows larger. At that point, the exact same logical dataflow starts getting split across multiple ownership models.

Some state belongs to components, while other state belongs to a store. Some derived state is trapped inside the render phase, and async state lives inside a query cache. The system still works, but the boundaries of the dataflow start to depend heavily on conventions, team discipline, and developer memory. It becomes incredibly hard to answer one seemingly simple question: Who actually owns this derived state? Is it the component, the store, the framework runtime, or just a temporary value calculated inside a hook?

Render Should Not Naturally Own the Entire Dataflow

Frontend developers often treat render as the center of the system. This is completely understandable—what we look at and debug every day is the UI. So when data changes, our first instinct is usually: "Which component needs to re-render?"

But if we reverse the question, the architecture looks very different. When data changes, perhaps the first question should be: "Which pieces of derived data are actually affected?" Render is simply one kind of side effect caused by data changes. It is extremely important, but it should not naturally own the entire dataflow.

This became one of the core architectural lessons I learned:

The reactive graph should first describe the relationships between data, while render should only be one consumer of that graph.

From Signal Library to Dataflow Kernel

If I only saw signal-kernel as a signal library, then most design questions would stay at the API surface: Should it feel more like Solid? Should computed values be lazy or eager? Should it support batching? These are important, but they hide the deeper issue: When a piece of state changes, who is responsible for deciding which derived states are affected?

In a traditional component-driven model, this usually happens during render:

Data changes → component re-executes → derived data is recalculated.

This model works beautifully for small applications, but it forces the lifecycle of derived state to follow the lifecycle of render. Once derived state becomes expensive, needs to be shared across frameworks, or needs to be deeply connected with async streams, this model becomes fragile.

That is why the real goal of signal-kernel was never simply to “reduce re-renders.” The goal was to detach derived dataflow from render ownership. What I actually wanted to build was a dataflow kernel.

A system that focuses on lower-level architectural concerns:

How state becomes a pure source of truth.
How derived state is tracked stably inside a reactive graph.
How effects can be separated cleanly from the render lifecycle.
How async work and continuously written streams can become part of the reactive graph while keeping clear state boundaries.
How render can return to its proper role: a consumer, not the owner.

Keeping the Boundary: Thin Framework Adapters

This way of thinking also directly shaped how I designed the React and Vue adapters. At the beginning, I naturally wanted to provide many convenient hooks and APIs that felt familiar to framework users. But over time, I became much more conservative.

If an adapter becomes too thick, it quietly pulls ownership back into the UI framework. And once that happens, the data independence that signal-kernel is trying to preserve starts to fade away.

A cleaner and more stable boundary should look like this:

Core owns the reactive graph.
Async-runtime owns the consistency of async state.
Framework adapters only subscribe to and read snapshots.
Render only draws the current result to the screen.

An adapter should not redefine the dataflow. It should only be a transparent pipe into the framework.

Rethinking Framework Responsibility

I want to make one thing clear: this series is not meant to criticize React or any other UI tool. React is still excellent at handling UI consistency, and TanStack Query solves a very real, difficult server-state problem.

What I want to explore is a deeper architectural question:

When we habitually put all data logic into the model of a UI framework, are we accidentally making render responsible for too much?

If reactive dataflow itself can be an independent system, then what role should a UI framework actually play?

What I Was Really Studying Was Ownership

While implementing the core and async-runtime of signal-kernel, I kept running into a series of uncomfortable architectural questions:

After a Promise resolves, is it really just a simple setState?
If a stream keeps emitting chunks, who should own its stable value, status, and error?
After a mutation succeeds, is invalidation the responsibility of the query cache, or the reactive graph?

All of these questions eventually point to the same word: Ownership.

I originally thought I was building a signal library. But the more I built, the more I realized that what I was really studying was how the boundaries of dataflow should be redefined in increasingly complex frontend applications. APIs can change. Implementations can be replaced. But the core question remains the same:

When data changes, who is responsible for understanding that change?

If the answer is always render, then we are forced to keep layering workarounds around the UI framework. But if the answer is the reactive graph, then render can return to its most reasonable position. It is one outlet of the dataflow. It is one side effect. It is a consumer of the system, not the owner.

That is the most important lesson I learned while building signal-kernel. If this idea resonates with you, I’m exploring it through signal-kernel, a framework-agnostic reactive dataflow kernel.

The project is still evolving, but its direction is clear: render should be a consumer of the dataflow, not the owner.

In the next article, I want to continue exploring this question:

What actually changes in frontend architecture when render no longer owns the entire dataflow?

What I Learned After Building a Signal System from Scratch

Luciano0322 — Mon, 08 Jun 2026 02:27:19 +0000

Recap

At this point, this series on Signals and fine-grained reactivity is temporarily coming to an end.

This article will not introduce new technical details. Instead, I want to share some personal reflections and thoughts after writing the whole series.

The Influence of Ryan Carniato

In some sense, this entire series was inspired by Ryan Carniato, the creator of Solid.js.

Ryan has always been able to point directly at the pain points we face in React development. As a senior React engineer, I often find myself thinking:

Yes, this is exactly the problem I run into every day.

Solid.js is undoubtedly an excellent framework, although its learning curve can be high for beginners.

However, from my perspective, many of its design choices feel more reasonable than the direction React has taken. For example:

Effects without dependency arrays
Separating mounted logic from cleanup logic
JSX without the Virtual DOM

These are all things that many developers in the React community had asked for before, but they were never truly prioritized.

The Dilemma of React and Next.js

Over the past few years, React’s direction has become increasingly influenced by the needs of the Next.js ecosystem.

Server Components introduced an important architectural shift, but they also forced many frontend engineers to adopt a model that still feels immature in everyday application development.

To be clear, I am not saying Server Components are useless. They solve real problems around server-side data access, streaming, and reducing client-side JavaScript. But from a frontend developer’s perspective, they also make the mental model of React significantly more complex.

To be honest, I sometimes miss the era of “Next.js without Server Components.” React was simpler back then. Its problems were obvious, but at least the boundaries were easier to reason about, and we had more freedom to choose our own solutions.

People in the community have proposed ideas such as “Should React introduce signals?” or even “Should React explore a version without the Virtual DOM?” These ideas may not align naturally with the current product direction and incentives around React and Next.js, but I still think they are worth discussing seriously.

My point is not that React is wrong or that the Virtual DOM is useless.

The Virtual DOM is still a reasonable abstraction in many scenarios. For example, in cross-platform environments such as React Native, it provides a practical compromise between a declarative UI model and multiple rendering targets.

My point is narrower:

The Virtual DOM is not wrong. It is just no longer the only reasonable center of frontend architecture.

When the problem is fine-grained data dependency, update precision, and scheduler correctness, signals provide a different model that deserves serious consideration.

What I see today is a React ecosystem entering a more conflicted phase. Although projects like TanStack are still doing excellent work to improve the developer experience, if a mature alternative appears in the future, I may no longer choose Next.js by default.

Common Misunderstandings

“Isn’t this just Jotai?”

In the community, you may sometimes hear people say that Jotai — or the atomic state model in general — is basically the same thing as signals. Some even argue that because it is built closer to the framework ecosystem, it is more developer-friendly.

But if you have followed this series and implemented the concepts step by step, or if you have ever implemented a reactive system yourself, you will understand that the two approaches are based on very different design philosophies.

The key difference is whether the system handles dependencies.

Below is a simple conceptual comparison.

Atomic State: The Recoil / Jotai Family

Core idea: Split state into the smallest possible units, often called state atoms. There is no implicit dependency tracking between them.
Composition model: Use selectors or derived functions to organize logic and compose state.
Update model: When state changes, the system does not automatically notify downstream dependents. Instead, selectors are re-executed as pure functions.
Characteristics:
- Easy to understand in a functional way: state is a value, and a selector is a pure function.
- However, the dependency graph is not explicit. Every read may require recomputation, which can lead to repeated calculations.

Signals

Core idea: Signals are also fine-grained state units, but they include an explicit dependency-tracking graph.
Composition model: computed and effect automatically register dependencies during execution. When a source value changes later, downstream subscribers are notified automatically.
Update model: Usually push-based. Once a source value changes, downstream nodes are marked as stale, and the scheduler decides when to run updates.
Characteristics:
- Avoids unnecessary recomputation because the runtime knows who depends on whom.
- Update propagation is faster and more precise.
- Requires the runtime to manage a dependency graph.

Summary of the Difference

In one sentence:

Atomic state: Splits state, but does not deeply manage dependencies. The system needs to “calculate again” through functions.
Signals: Splits state and adds dependency tracking. The system knows who needs to update.

Not handling dependencies does make the model easier to write and understand. Jotai also relies on the framework’s own state model, which naturally aligns with the framework lifecycle and avoids many synchronization problems.

But the trade-off is that this model must rely on framework re-renders to guarantee correctness. Signals, on the other hand, can achieve more fine-grained updates through runtime-level dependency tracking.

Flow Difference

“Isn’t this just Dependency Injection?”

Another common comparison is to treat signals, especially when integrated with Vue or React, as something similar to Dependency Injection (DI) in the traditional OOP world.

At first glance, it does look somewhat similar: you inject external state into a framework and use it inside the application.

But the essential difference is this:

DI solves the composition and management of object dependencies.
Signals solve the tracking and update timing of data dependencies.

They may look similar on the surface, but they solve problems at completely different dimensions.

What Does DI Solve?

It answers: “Which object needs which service?”
Timing: Construction time
Keywords: dependency relationship, object composition
Example: A Car needs an Engine, and the DI framework injects it for you.

class Engine {}

class Car {
  constructor(private engine: Engine) {}
}

What Do Signals Solve?

They answer: “Which piece of data depends on which other piece of data?”
Timing: Runtime
Keywords: data tracking, state update propagation
Example: totalPrice depends on count * unitPrice, and it updates automatically when the source values change.

const count = signal(2);
const unitPrice = signal(100);
const totalPrice = computed(() => count.get() * unitPrice.get());

A Simple Clarification

DI helps objects get the services they need.
Signals help the system know who should update when data changes.

“Signals are just another state management tool”

Many people think signals are just another form of state management.

But after going through the implementation details in this series, you can see that signals touch much more than state management.

A state management library usually helps you organize where state lives and how it is updated.

A signal system goes one layer deeper. It asks:

How are data dependencies tracked?
How are invalidations propagated?
When should derived values recompute?
When should effects run?
How should the scheduler preserve consistency?

This is why reducing signals to “just another state management tool” misses the point.

What signals challenge is not merely state management, but the long-standing assumption that the Virtual DOM must sit at the center of frontend architecture.

That does not mean the Virtual DOM has no value. It means we should treat it as one architectural trade-off among many, not as the only valid mental model for UI development.

Technical evolution is never just about code. It is also about incentives, existing knowledge systems, and the cost of changing how people think.

Signals are uncomfortable because they move the discussion away from component re-rendering and toward data dependency itself.

Adjusting Your Mindset: Facing Irrational Criticism

Some people will directly deny the value of signals. Some may even mock them with comments like:

Signals are useless.

Dan already told you not to use them.

These comments often carry more emotion or tribal position than technical understanding.

To me, these voices are not a threat. They are more like a mirror:

If you already understand the difference between atomic state and signals, you can easily see the blind spots in the argument.
If you do not understand it yet, then it is a useful reminder that you should study the topic more deeply.

Of course, this does not mean we should blindly reject React’s design decisions either. React has solved many real engineering problems, and its ecosystem is still extremely valuable.

But no framework author, no matter how experienced or influential, should become a reason for us to stop thinking.

The healthier attitude is to return to concrete examples, implementation details, and trade-offs.

So when you encounter this kind of criticism, the best response is not to rush into an argument.

Return to the code. Return to the design principles.

Once you can explain the difference in dependency tracking with a simple example, the mockery naturally loses its power.

The Future of Signals

Overall, I am quite optimistic about the future of signals.

The TC39 Signals proposal from last year already shows that signals are becoming increasingly important in frontend development.

Apart from React, which still seems to maintain a “React knows best” atmosphere, most mainstream frameworks have already entered a new era with signal-like ideas:

Vue’s Vapor Mode
Angular 17+ Signals
Svelte Runes
Preact Signals
SolidJS

Some of them are even moving toward removing the unnecessary parts of the Virtual DOM, such as Vue’s Vapor Mode and SolidJS’s JSX compilation model.

This means that developers who truly understand the core ideas behind signals will be much more comfortable in future frontend applications.

In my own experience, once I understood these concepts, switching between different frameworks became much easier.

Why I Started This Series

The reason I started this series was that I was building my own open-source signal system library: signal-kernel.

During that process, I kept running into challenges. Then I realized something important:

Many of the “algorithms and data structures” we learned in school or practiced for interviews are actually useful here.

This made me even more convinced of one thing:

If you want to design the foundation of a framework well, you must understand JavaScript fundamentals and computer science.

What I Learned

To me, this series is not just a set of technical notes. It is also part of my own journey as an engineer.

It started from my frustration with React.
It was inspired by Ryan Carniato’s ideas.
It eventually led me back to the importance of JavaScript fundamentals and algorithms.

The biggest lesson I learned is this:

Frameworks will come and go, but fundamental knowledge and mental models are what allow you to go further.

This series only peels back the first layer of a framework engine: the reactive core.

Of course, the reactive core is also one of the most important foundations of any framework. If we continue going deeper, we will run into topics such as:

DOM rendering
UI rendering schedulers
Component models

Every framework makes different decisions and trade-offs in these areas.

These may become directions for my future research.

Advice for Readers

If you are currently learning React, you do not need to rush into Solid.js or any other framework.

The truly important thing is not which framework you choose. The important thing is understanding the underlying concepts:

The data flow from state → derivation → effect
Why schedulers and dependency graph management matter
The difference between push and pull
The difference between eager and lazy execution

Once you understand these ideas, you can quickly find your direction in any framework.

Do not just learn how to use a framework. Learn the logic underneath it.

Trends will change, but fundamental concepts are the real assets that engineers can carry with them.

Signal Implementation Reference

As usual, I will also attach the implementation code from this series for reference:

reactivity_lessons

The repository includes unit tests for each section, although only the parts that changed in each chapter are tested.

I still hope readers will modify the examples themselves instead of simply copying and pasting the code.

If you only copy the implementation directly, you will miss many opportunities to think through the details.

The examples I provide are intentionally designed choices. In many cases, the data structures and subscription model may not fit every development scenario. However, they make the concepts easier for beginners to understand.

I did not want to switch between too many algorithms and data structures during the explanation, because that would introduce unnecessary confusion.

For more advanced discussion, I recommend focusing on Ryan Carniato’s article series, especially Derivations in Reactivity, which explains many of the trade-offs behind today’s mainstream signal implementations.

New article published: Building Reactive DevTools A reactive system should not be a black box. In this article, I explore how to make a signal-based runtime observable through node inspection, graph visualization, render counters, and hotspot tracking.

Luciano0322 — Mon, 01 Jun 2026 06:06:33 +0000

Luciano0322

Jun 1

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

#javascript #webdev #frontend #devtool

5 min read

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Luciano0322 — Mon, 01 Jun 2026 05:59:47 +0000

Recap

In the previous chapters, we explored:

Scheduler internals
Memory and graph management
Priority and layered scheduling
Time-slicing and cooperative scheduling

All of these mechanisms are essential for making a reactivity system work correctly internally.

But internal correctness alone is not enough.

For developers, the more important question is:

How do we observe, debug, and understand the system?

That is where DevTools and diagnostics become critical.

Inspecting Nodes

Why do we need `inspect()`?

One of the most common debugging needs during development is:

“What is the current value of this signal or computed?”

If the only solution is console.log, debugging quickly becomes inconvenient and intrusive.

A proper inspection layer gives developers visibility without polluting application logic.

Feature Design

The inspector should provide:

Current value
Dependency relationships (deps / subs)
Whether the node is:
- stale
- disposed

Implementation

// devtools.ts
// type reused from previous graph.ts
import type { Node } from "./graph.js";

// Assign IDs using WeakMap without polluting Node structure
const ids = new WeakMap<Node, string>();
let seq = 0;

function getId(n: Node) {
  let id = ids.get(n);

  if (!id) {
    id = `${n.kind}#${++seq}`;
    ids.set(n, id);
  }

  return id;
}

export type InspectSnapshot = {
  id: string;
  kind: Node["kind"];
  inDegree: number;
  outDegree: number;
  deps: { id: string; kind: Node["kind"] }[];
  subs: { id: string; kind: Node["kind"] }[];
};

// Get a flat snapshot of a single node (non-recursive)
export function inspect(node: Node): InspectSnapshot {
  return {
    id: getId(node),
    kind: node.kind,
    inDegree: node.deps.size,
    outDegree: node.subs.size,
    deps: [...node.deps].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
    subs: [...node.subs].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
  };
}

Debug-Friendly Logging

export function logInspect(node: Node) {
  const snap = inspect(node);

  console.log(
    `[inspect] ${snap.id} (${snap.kind})  in=${snap.inDegree}  out=${snap.outDegree}`
  );

  if (snap.deps.length) {
    console.log("  deps ↑");
    console.table(snap.deps);
  } else {
    console.log("  deps ↑ (none)");
  }

  if (snap.subs.length) {
    console.log("  subs ↓");
    console.table(snap.subs);
  } else {
    console.log("  subs ↓ (none)");
  }
}

This provides a much friendlier debugging experience than raw logging.

Recursive Graph Inspection

When debugging larger dependency chains, inspecting a single node is often not enough.

We can recursively expand the graph while avoiding cycles.

export function inspectRecursive(root: Node, depth = 1) {
  const seen = new Set<Node>();

  type Row = {
    from: string;
    to: string;
    dir: "deps" | "subs";
  };

  const rows: Row[] = [];

  const queue: Array<{
    node: Node;
    dUp: number;
    dDown: number;
  }> = [{
    node: root,
    dUp: depth,
    dDown: depth,
  }];

  seen.add(root);

  while (queue.length) {
    const { node, dUp, dDown } = queue.shift()!;
    const fromId = getId(node);

    if (dUp > 0) {
      for (const dep of node.deps) {
        rows.push({
          from: getId(dep),
          to: fromId,
          dir: "deps",
        });

        if (!seen.has(dep)) {
          seen.add(dep);

          queue.push({
            node: dep,
            dUp: dUp - 1,
            dDown: 0,
          });
        }
      }
    }

    if (dDown > 0) {
      for (const sub of node.subs) {
        rows.push({
          from: fromId,
          to: getId(sub),
          dir: "subs",
        });

        if (!seen.has(sub)) {
          seen.add(sub);

          queue.push({
            node: sub,
            dUp: 0,
            dDown: dDown - 1,
          });
        }
      }
    }
  }

  return {
    center: getId(root),
    nodes: [...seen].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
    edges: rows,
  };
}

Mermaid Export

We can even export subgraphs into Mermaid diagrams for documentation or DevTools visualization.

export function toMermaid(root: Node, depth = 1) {
  const g = inspectRecursive(root, depth);

  const lines = ["graph TD"];

  for (const n of g.nodes) {
    lines.push(
      `  ${n.id.replace(/[^a-zA-Z0-9_#]/g, "_")}["${n.id}"]`
    );
  }

  for (const e of g.edges) {
    const a = e.from.replace(/[^a-zA-Z0-9_#]/g, "_");
    const b = e.to.replace(/[^a-zA-Z0-9_#]/g, "_");

    lines.push(`  ${a} --> ${b}`);
  }

  return lines.join("\n");
}

API Summary

inspect(node)
- Fastest single-node snapshot
logInspect(node)
- Debug-friendly console tables
inspectRecursive(node, depth)
- Small graph expansion without infinite loops
toMermaid(node, depth)
- Export subgraphs for docs or DevTools rendering

Graph Visualization

As applications grow larger, textual inspection is no longer sufficient.

At that point, we need dependency graph visualization.

Signal nodes (blue) represent data sources
Computed nodes (green) represent derived values
Effect nodes (yellow) represent side effects

Inside DevTools, we could:

Click nodes to inspect current values
Highlight stale nodes
Visualize link/unlink operations
Observe automatic cleanup and graph pruning

This makes the dataflow fully observable.

Instead of a black box, developers can literally see:

Which state triggered which update.

Render Counters

The Problem

In UI frameworks, one of the most common performance issues is over-rendering.

For example:

Components re-render repeatedly
But nothing meaningful actually changes

Feature Design

A render counter can:

Increment on each render
Display a small overlay badge
Aggregate render statistics in DevTools

Why This Matters

This helps developers identify:

Unnecessary re-renders
Missing memoization
Poor equality strategies
Expensive recomputation chains

It also guides optimization decisions like:

memo
shallowEqual
computed caching

Hotspot Tracking

Why Track Hotspots?

In large applications, knowing that something updated is not enough.

We also need to know:

Which nodes update the most frequently?

That is where hotspot profiling becomes valuable.

Feature Design

We can track:

Update counts
Update frequency
Execution duration
Graph degree statistics

And combine them with:

Heatmaps
Timeline views
Priority scheduling traces

Hotspot Implementation

1. `hotspot.ts`

// hotspot.ts
import type { Node } from "../graph.js";

export type HotspotStats = {
  updates: number;
  lastTs: number;
  freqPerMin: number;
  durTotal: number;
  durCount: number;
};

let stats = new WeakMap<Node, HotspotStats>();

const liveNodes = new Set<Node>();

const alpha = 0.2;

const now = () =>
  globalThis.performance?.now?.() ?? Date.now();

The system tracks:

Frequency
Total execution time
Average execution time
Update counts

without modifying the core graph structure itself.

2. Tracking Signal Writes

recordUpdate(node);

We only inject instrumentation where actual work happens.

For example:

signal.set()
computed.recompute()
effect.run()

This keeps the core runtime clean and minimally invasive.

3. Wrapping Computation Timing

withTiming(node, () => {
  // recompute logic
});

This allows us to measure:

recomputation frequency
average execution duration
expensive reactive chains

Example Usage

logTopHotspots(5, "freq", allNodes());

logTopHotspots(5, "avgTime", allNodes());

logTopHotspots(5, "updates", allNodes());

This lets us quickly identify:

high-frequency nodes
expensive computations
reactive bottlenecks

Real-World Use Cases

Game Loops

Identify states updating every frame.

Forms

Detect extremely hot input fields.

Data Visualization

Locate nodes responsible for expensive re-renders.

Async Systems

Observe retry storms or invalidation cascades.

Why DevTools Matter

DevTools are not just debugging utilities.

They also help developers:

Build Mental Models

Understand how the reactive graph actually flows.

Optimize Performance

Locate bottlenecks quickly instead of guessing blindly.

Learn Reactivity

Make invisible runtime behavior visible and intuitive.

Possible Future Directions

Timeline Profiling

Visualize update propagation over time.

Priority-Aware Diagnostics

Inspect how different scheduler priorities interact.

Automated Suggestions

Examples:

“This signal updates too frequently.”
“Consider memoizing this computed.”
“This effect causes excessive downstream invalidation.”

Final Thoughts

By adding:

node inspection
graph visualization
render counters
hotspot profiling

we transform the reactive system from a black box into an observable runtime.

This not only improves debugging and optimization,
but also helps developers truly understand how reactivity works internally.

DevTools are not just developer conveniences —
they are part of how a runtime teaches its own architecture.

At this point, I’ve shared most of the core knowledge I gained while implementing this series.

There are still many unexplored trade-offs and architectural differences across reactive libraries, and those differences often determine why certain libraries perform better in specific scenarios.

In the next article, I’d like to share some personal reflections and lessons learned from writing this entire series.

I published a new article in my Signals series. In this article, I explore how cooperative scheduling, shouldYield(), and task chunking help avoid blocking the JavaScript main thread.

Luciano0322 — Tue, 26 May 2026 03:17:32 +0000

Luciano0322

May 26

How React-Style Time-Slicing Keeps UIs Responsive

#javascript #webdev #frontend #typescript

2 min read

How React-Style Time-Slicing Keeps UIs Responsive

Luciano0322 — Tue, 26 May 2026 03:11:13 +0000

Quick Recap

In the previous article, we introduced priority-based and layered schedulers, solving the problem of “which tasks should run first.”

However, real-world applications introduce another challenge:
long-running tasks can still block the main thread.

To keep applications responsive, a scheduler must also support:

Time-Slicing
Cooperative Scheduling

The Problem: Long Tasks Blocking the Main Thread

Imagine this scenario:

The UI thread is executing a large rendering task — for example, updating 5000 list items at once.

That operation might take tens of milliseconds, or even exceed 100ms before finishing.

During that time:

Mouse movement and keyboard input cannot respond immediately
The UI may freeze and drop below 60 FPS
Users experience visible stuttering and lag

Priority alone is not enough.

Even if a task has the correct priority, once execution begins, it can still monopolize the main thread.

Time-Slicing

The core idea behind Time-Slicing is:

Split a long task into smaller chunks and periodically yield control back to the main thread.

Workflow

A task is divided into smaller chunks
After each chunk, the scheduler checks whether there is remaining execution time
If not → pause execution and continue later during the next available frame or idle period

This ensures:

User input and animations remain responsive
Background work completes progressively over time

Cooperative Scheduling

In operating systems, there are two major scheduling models:

Preemptive Scheduling
Cooperative Scheduling

In JavaScript’s single-threaded environment, true preemption is impossible.

So frameworks adopt cooperative scheduling instead:

Tasks voluntarily check whether they should yield (shouldYield())
If interrupted, the remaining work is re-queued for later execution

This is essentially the strategy used by React Concurrent Mode.

Example Implementation

Here is a simplified example of a Time-Slicing + Cooperative Scheduler:

let deadline = 0;

function shouldYield() {
  return performance.now() >= deadline;
}

export function runWithTimeSlicing<T>(
  work: () => T,
  timeSlice = 5
): T | void {
  deadline = performance.now() + timeSlice;

  while (!shouldYield()) {
    const result = work();
    return result;
  }

  // Not finished → continue later
  queueMicrotask(() =>
    runWithTimeSlicing(work, timeSlice)
  );
}

Key Idea

Each execution is allowed to run for only timeSlice milliseconds
Once the budget is exceeded, control returns to the browser

This prevents long-running tasks from blocking the main thread entirely.

Combining Time-Slicing with Priorities

On top of a layered priority scheduler, we can integrate Time-Slicing strategies:

Immediate / High Priority
- Execute immediately without slicing
Normal Priority
- Use time-slicing and process incrementally
Low / Idle Priority
- Use requestIdleCallback
- Run only when the browser is idle

This allows the system to balance:

Real-time interactions
Heavy background updates
Overall UI smoothness

Time-Slicing Scheduler Flow

Final Thoughts

Priority scheduling solves the question of:

“Which task should run first?”

Time-Slicing and Cooperative Scheduling solve another equally important problem:

“How do we avoid blocking the UI?”

Together, these techniques allow systems such as Signals, React, and Vue to remain responsive even under massive update workloads.

In the next article, we’ll explore DevTools and Diagnostics, including:

Inspecting reactive nodes
Dependency graph visualization
Render counters
Hotspot tracing
Scheduler debugging tools

These tools help us better understand how signals and schedulers behave in real-world applications.

In my latest signal article, I explore how priority queues and layered execution can help a scheduler preserve interaction responsiveness while still maximizing performance utilization.

Luciano0322 — Thu, 21 May 2026 05:22:37 +0000

Luciano0322

May 21

Building a Smarter Scheduler: Priority Queues and Layered Execution

#webdev #javascript #frontend #typescript

3 min read

Building a Smarter Scheduler: Priority Queues and Layered Execution

Luciano0322 — Thu, 21 May 2026 05:19:07 +0000

Recap

In the previous article, we explored the relationship between the Scheduler and the dependency Graph, and discussed the challenges of memory management and dependency management.

However, in real-world applications, not all tasks have the same level of urgency:

Some updates must take effect immediately, such as text input from the user.
Some updates can be deferred, such as animations or low-priority UI updates.

This is where Priority and Layered Scheduling become important.

Why Do We Need Priority?

Imagine this scenario: a user is typing into an input field through input.onChange, while a large background computation is also running, such as a chart re-render.

If both tasks are placed into the same queue without any priority control, the user input may get blocked, leading to a poor user experience.

The solution: allow high-priority tasks, such as input events, to be processed first, while lower-priority tasks are deferred.

Common Priority Levels

In modern frontend frameworks, scheduling systems usually define priority levels similar to the following:

Immediate / Sync
- Examples: text updates in an input field, urgent error messages
- These must respond immediately and should not be delayed.
High Priority
- Main UI interactions, such as state updates triggered by button clicks.
Normal Priority
- Most non-critical UI updates.
Low Priority / Idle
- Background computation, performance statistics, prefetching, and other non-urgent work.

This ensures that the most important interactions for user experience are always handled first.

Layered Scheduling

Besides priority, another important concept is layering.

We can divide tasks into different layers, where each layer has its own queue, and the Scheduler coordinates the execution between them:

Computation Layer
- Signal / Computed updates
UI Layer
- DOM updates, Virtual DOM diffing
I/O Layer
- Fetch requests, network operations, storage access
Idle Layer
- Non-essential background tasks, such as log collection

This design is somewhat similar to an operating system’s CPU scheduler: different types of tasks are managed separately to prevent them from interfering with each other.

Example Architecture

Here is a simplified version of a Scheduler that supports both priority and layering:

type Priority = "immediate" | "high" | "normal" | "low";

interface Job {
  run(): void;
  priority: Priority;
  layer: "compute" | "ui" | "io" | "idle";
}

const queues: Record<Priority, Job[]> = {
  immediate: [],
  high: [],
  normal: [],
  low: [],
};

export function scheduleJob(job: Job) {
  queues[job.priority].push(job);
  requestFlush();
}

function requestFlush() {
  queueMicrotask(flushJobs);
}

function flushJobs() {
  // Execute jobs by priority
  runQueue(queues.immediate);
  runQueue(queues.high);
  runQueue(queues.normal);
  runQueue(queues.low);
}

function runQueue(queue: Job[]) {
  while (queue.length > 0) {
    const job = queue.shift()!;
    job.run();
  }
}

This is a “single-level priority” example.
If we want to introduce real layering, we can further split queues based on Job.layer.

Understanding the Execution Flow Through a Diagram

Performance and Optimization Strategies

Batching
- Tasks with the same priority can be merged to avoid duplicated computation.
Time-Slicing
- Long-running tasks can be split into smaller chunks to avoid blocking the main thread.
- React Concurrent Mode uses this kind of strategy.
Waterfall Execution
- Run high-priority tasks first, then process lower-priority tasks if there is still enough time.
- If time is insufficient, low-priority tasks can be deferred to the next tick.

Conclusion

Moving from a single queue to a Scheduler with priority and layering has one major goal:

Preserve interaction responsiveness while maximizing performance utilization.

This is why React introduced Concurrent Features, Vue uses a job queue, and signal-based systems are also starting to design more refined scheduling mechanisms.

In the next article, we will dive deeper into Time-Slicing and Cooperative Scheduling, and explore how a scheduler can keep interactions smooth even when handling expensive tasks.

I published a new article in my Signals series. This one is about the hidden cost of fine-grained reactivity: dangling nodes, stale edges, disposal, auto-unlinking, equality strategies, and why the dependency graph is just as important as the Scheduler.

Luciano0322 — Mon, 18 May 2026 08:01:26 +0000

Luciano0322

May 18

Signal Internals: Managing Memory and the Dependency Graph

#javascript #webdev #frontend #typescript

8 min read

Signal Internals: Managing Memory and the Dependency Graph

Luciano0322 — Mon, 18 May 2026 07:58:45 +0000

Quick Recap

In the previous article, we looked at the role of the Scheduler.

The Scheduler is responsible for arranging downstream jobs after data changes and batching those updates so the system does not recompute everything immediately and repeatedly.

However, scheduling alone is not enough to make a reactive system stable.

If a signal system is expected to run for a long time, especially inside real applications where components mount, unmount, reconnect, and re-track dependencies, two topics become unavoidable:

memory management
dependency graph management

This article focuses on these two layers.

Why Do We Need a Graph?

In a fine-grained reactivity system, the relationships between signal, computed, and effect are essentially a directed graph.

Nodes

A node represents a reactive unit in the system.

Signal: the source of state
Computed: a derived value calculated from other nodes
Effect: a side-effect node, such as DOM updates, logging, or external synchronization

Edges

An edge represents a dependency relationship.

When an effect reads a signal, or when a computed reads another computed, the system creates an edge between the dependent node and the dependency it read.

This gives the runtime a structured way to answer one important question:

When this value changes, who needs to know?

This design serves two major purposes.

1. Precise Updates

When a signal changes, the runtime does not need to notify the entire world.

It only follows the graph edges and finds the nodes that are actually affected.

2. Avoiding Redundant Computation

The graph allows the system to track which computations are still valid and which ones have become stale.

Instead of recomputing everything eagerly, the runtime can mark affected nodes as dirty and only recompute them when necessary.

Without a graph, the Scheduler would be forced to use a broad broadcast mechanism. Every update would become much more expensive because the system would lose the ability to know what is actually related to what.

The Memory Management Problem

Once we introduce a graph, we also introduce ownership and lifetime problems.

A graph is not just a set of values. It is a set of references.

If those references are not cleaned up correctly, the system may continue holding onto nodes that should already be gone.

This is where memory management becomes part of the core design.

1. Dangling Nodes

A dangling node appears when an effect or computed is no longer needed, but its node is still retained by the graph.

This commonly happens when:

a React component unmounts
a Vue component is destroyed
a manually created effect is no longer used
a derived computation becomes unreachable

If the corresponding graph node is not cleaned up, it may continue to be referenced by upstream nodes.

That means the runtime may still keep it alive, even though the application no longer needs it.

This is a typical source of memory leaks in reactive systems.

The solution is straightforward in principle:

When a node is disposed, unlink all of its upstream dependencies.

Disposal is not only about stopping future execution. It is also about removing the node from the graph so it can be released.

2. Stale Edges

A stale edge appears when a node's dependency relationship changes, but the old edge remains in the graph.

For example:

const value = computed(() => {
  if (enabled.get()) {
    return sourceA.get();
  }

  return sourceB.get();
});

When enabled is true, this computed value depends on sourceA.

When enabled becomes false, it should stop depending on sourceA and start depending on sourceB instead.

If the old edge to sourceA is not removed, then future updates to sourceA may still mark this computed value as stale, even though it no longer reads from sourceA.

That is not only inefficient. It also means the graph no longer reflects the real dependency structure of the program.

The solution is to rebuild dependency edges during the tracking phase.

In practice, this usually means:

collect dependencies while executing the tracked function
compare the new dependencies with the old ones
remove edges that are no longer used
add edges that are newly discovered

This is why a signal system needs explicit link and unlink operations.

3. GC and Retain Cycles

JavaScript's garbage collector can handle many circular references.

However, that does not mean a reactive runtime can ignore reference ownership.

If the internal graph structure keeps strong references to nodes that are no longer reachable from user code, those nodes may still remain alive.

The problem is not simply that a cycle exists.

The real problem is that the runtime may accidentally become the owner of objects that should have been released.

There are several ways to reduce this risk:

avoid unnecessary bidirectional ownership
make disposal explicit where lifecycle boundaries are clear
use WeakMap for metadata lookup when the runtime should not own the object
consider WeakRef only when the use case truly requires weak object references

In my own design preference, I would start with explicit disposal first.

It makes lifecycle boundaries easier to reason about. Weak references can be useful, but they should not become a replacement for a clear ownership model.

A Minimal Graph Structure

In a signal system, there is usually a dedicated Graph Layer responsible for managing nodes, dependencies, subscribers, and disposal.

A simplified node structure may look like this:

export interface Node {
  deps?: Set<Node>; // upstream dependencies
  subs?: Set<Node>; // downstream subscribers
  stale?: boolean; // whether the node is dirty
  disposed?: boolean; // whether the node has been released
}

Different libraries may use different names or organize the structure differently, but the underlying idea is usually similar.

If you read through the source code of several reactive libraries, you will often find the same core concepts under different abstractions.

Linking and Unlinking

When a reactive node reads another node during tracking, the runtime creates an edge.

A minimal implementation may look like this:

export function link(source: Node, target: Node) {
  (source.deps ??= new Set()).add(target);
  (target.subs ??= new Set()).add(source);
}

export function unlink(source: Node, target: Node) {
  source.deps?.delete(target);
  target.subs?.delete(source);
}

Here, source is the dependent node, and target is the node it depends on.

So the relationship is stored in two directions:

source.deps points to upstream dependencies
target.subs points to downstream subscribers

This bidirectional structure makes propagation efficient, but it also means cleanup must be handled carefully.

Disposing a Node

When an effect is destroyed, the runtime must remove it from its upstream dependencies.

A simplified disposal function may look like this:

export function dispose(node: Node) {
  if (node.deps) {
    for (const dep of node.deps) {
      dep.subs?.delete(node);
    }
  }

  node.deps?.clear();
  node.subs?.clear();
  node.disposed = true;
}

This ensures that:

stale dependencies do not remain in the graph
upstream nodes no longer retain the disposed node
memory can be released after a component or effect is destroyed

In other words, dispose() is not just an API for stopping an effect.

It is a graph cleanup operation.

How the Scheduler Uses the Graph

The Scheduler does not work in isolation.

It relies on the graph to know which nodes should be updated after a change.

A typical flow looks like this:

signal.set() updates the value and marks the signal node as stale.
The Scheduler queues affected jobs.
flushJobs() drains the queue.
The runtime follows subs to propagate invalidation downstream.
If some nodes no longer have subscribers, the runtime may auto-unlink or dispose them.

The important point is this:

The Scheduler decides when work should run, but the graph decides where the work should propagate.

Without the graph, scheduling becomes blind.

Without the Scheduler, graph updates can become chaotic and repetitive.

A stable signal runtime needs both.

Optimization Strategies

In small examples, basic graph management may be enough.

But in real applications, the graph may grow, shrink, and change shape constantly.

That is why signal systems usually need additional optimization strategies.

1. Auto-Unlink

In the standard link / unlink flow, a node may eventually lose all of its downstream subscribers.

If that node still keeps its upstream dependencies, invalid edges may remain in the graph for a long time.

This may not immediately cause incorrect behavior, but it can make the graph larger than necessary.

The solution is auto-unlink:

function autoUnlink(node: Node) {
  if (!node.subs || node.subs.size === 0) {
    for (const dep of node.deps ?? []) {
      dep.subs?.delete(node);
    }

    node.deps?.clear();
  }
}

With this approach, when a computed or effect no longer has subscribers, it can clean up its upstream dependencies automatically.

This prevents dangling dependency relationships from staying in the graph.

In the context of React or Vue, this is similar to removing event listeners during unmount.

The goal is the same: release resources when the lifecycle has ended.

2. Equals Strategy and Performance

In the signal.set() flow, we usually perform an equality check before triggering invalidation.

const set = (next: T) => {
  if (!equals(value, next)) {
    value = next;
    markStale(thisNode);
  }
};

This avoids unnecessary updates.

However, equality checking is not free. Different equality strategies have different trade-offs.

`Object.is`

Object.is is usually the default option.

It is native to JavaScript, fast, and predictable.

It works especially well for primitives and reference equality.

The limitation is that objects and arrays are compared by reference. If a new object is created, it will be treated as a new value even if its contents are structurally similar.

Shallow Equal

Shallow equality can be useful for common object-shaped UI state.

It can reduce unnecessary updates when object references change but the top-level fields remain the same.

The trade-off is that shallow comparison has an O(n) cost based on the number of keys or items being compared.

Custom Equal

Custom equality gives users full control.

It can support domain-specific comparison rules, Immutable.js structures, AST nodes, or deep equality.

However, this flexibility also introduces risk.

A poorly designed custom equality function can become more expensive than the update it tries to avoid.

Practical Guidance

For high-frequency updates, such as game loops, pointer tracking, animation, or real-time telemetry, Object.is is usually the safest default.

For form state or regular UI state, shallow equality can be a pragmatic compromise.

For complex domain data, custom equality may be useful, but it should be introduced deliberately.

The key is not to make equality smarter by default.

The key is to choose the cheapest strategy that preserves correctness for the use case.

3. Lazy Disposal

Some systems delay the actual cleanup work instead of disposing nodes immediately.

This is sometimes called lazy disposal.

The benefit is that it can reduce immediate overhead during hot update paths.

The cost is that the runtime now needs another mechanism to decide when deferred cleanup should happen.

Lazy disposal is not automatically better than explicit disposal.

It is a trade-off between immediate cleanup cost and delayed resource retention.

4. Weak References for Dependencies

Some metadata can be stored through WeakMap so the runtime does not accidentally extend the lifetime of user-owned objects.

This is useful when the runtime needs to associate internal metadata with external objects but should not become their owner.

WeakRef can also be used in more advanced cases, but it should be applied carefully.

Weak references can help reduce retention problems, but they also make lifecycle behavior harder to reason about.

For most signal systems, explicit graph cleanup should still be the foundation.

5. Layered Scheduler

Another optimization is to split work into different layers.

For example:

computation layer
UI update layer
I/O layer

Not all jobs have the same urgency.

A derived value recomputation, a DOM update, a network request, and a logging effect should not necessarily be scheduled with the same priority.

Once the runtime can distinguish these layers, the Scheduler can make more precise decisions.

This becomes especially important when the system needs to support larger applications, async resources, streaming updates, or framework adapters.

Conclusion

The Scheduler is not just a mechanism for running jobs later.

A serious signal system also needs to maintain its dependency graph and manage memory correctly.

The graph tells the runtime where changes should propagate.

Memory management ensures that obsolete nodes and edges do not stay alive forever.

Together, these two layers determine whether the system can remain efficient after running for a long time.

This is why implementations like Solid, Vue, and Preact Signals all contain dedicated logic for dependency tracking, graph cleanup, and lifecycle management.

In the next article, we will continue with priority and layered scheduling: how to optimize different kinds of tasks by giving the Scheduler a more structured execution model.

A Scheduler is the hidden commander of a reactivity system. It decides not whether something should run, but when it should run. New article: Building a Signal Scheduler

Luciano0322 — Mon, 11 May 2026 00:36:15 +0000

Luciano0322

May 11

Building a Signal Scheduler: Sync, Batch, Priority, and Lazy Execution

#webdev #javascript #frontend #typescript

5 min read

DEV Community: Luciano0322

When Render No Longer Owns the Entire Data Flow

Render Is a Consumer of Data Flow, Not the Owner

Why Components Should Not Carry All Data Flow Responsibilities

The Boundary Problem of Derived State

It's About Ownership, Not Performance

Let Render Return to Its Proper Position

What This Means for React and Vue

A System You Can Actually Reason About

Downgrading Render Into One of Many Outputs

From Signals to Ownership: Why I Built a Dataflow Kernel

Fragmented Dataflow and the Derived State Problem

Render Should Not Naturally Own the Entire Dataflow

From Signal Library to Dataflow Kernel

Keeping the Boundary: Thin Framework Adapters

Rethinking Framework Responsibility

What I Was Really Studying Was Ownership

What I Learned After Building a Signal System from Scratch

Recap

The Influence of Ryan Carniato

The Dilemma of React and Next.js

Common Misunderstandings

“Isn’t this just Jotai?”

Atomic State: The Recoil / Jotai Family

Signals

Summary of the Difference

Flow Difference

“Isn’t this just Dependency Injection?”

What Does DI Solve?

What Do Signals Solve?

A Simple Clarification

“Signals are just another state management tool”

Adjusting Your Mindset: Facing Irrational Criticism

The Future of Signals

Why I Started This Series

What I Learned

Advice for Readers

Signal Implementation Reference

New article published: Building Reactive DevTools A reactive system should not be a black box. In this article, I explore how to make a signal-based runtime observable through node inspection, graph visualization, render counters, and hotspot tracking.

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Recap

Inspecting Nodes

Why do we need inspect()?

Feature Design

Implementation

Debug-Friendly Logging

Recursive Graph Inspection

Mermaid Export

API Summary

Graph Visualization

Render Counters

The Problem

Feature Design

Why This Matters

Hotspot Tracking

Why Track Hotspots?

Feature Design

Hotspot Implementation

1. hotspot.ts

2. Tracking Signal Writes

3. Wrapping Computation Timing

Example Usage

Real-World Use Cases

Game Loops

Forms

Data Visualization

Async Systems

Why DevTools Matter

Build Mental Models

Optimize Performance

Learn Reactivity

Possible Future Directions

Timeline Profiling

Priority-Aware Diagnostics

Automated Suggestions

Final Thoughts

I published a new article in my Signals series. In this article, I explore how cooperative scheduling, shouldYield(), and task chunking help avoid blocking the JavaScript main thread.

How React-Style Time-Slicing Keeps UIs Responsive

How React-Style Time-Slicing Keeps UIs Responsive

Why do we need `inspect()`?

1. `hotspot.ts`

`Object.is`