Forem: usapop

Should Test Expected Values Come from the Same Place as the Implementation?

usapop — Sun, 08 Feb 2026 17:44:45 +0000

What Started This

Here are two tests that verify the same behavior:

test('calculates tax correctly', () => {
  const price = 1000;
  const tax = calculateTax(price);
  expect(tax).toBe(100);
});

import { TAX_RATE } from './config';

test('calculates tax correctly', () => {
  const price = 1000;
  const tax = calculateTax(price);
  expect(tax).toBe(price * TAX_RATE);
});

Both tests check the same thing, but the expected value comes from a completely different place. The first hardcodes 100; the second imports it from config. Does this difference matter? Looking into it led me to a more fundamental question about where test expected values should come from. I am not confident I have arrived at the right answer, but I hope this can at least serve as food for thought.

The Concept of a Test Oracle

In 1978, William E. Howden introduced the concept of a "test oracle." He later articulated the idea more clearly in a 1981 publication:

The use of testing requires the existence of an external mechanism which can be used to check test output for correctness. This mechanism is referred to as the test oracle.

The word "external" seems to be the key here. The information used to judge correctness in a test must come from something other than the program itself.

This idea was subsequently developed in various directions: Elaine Weyuker's definition of "non-testable" programs, Cem Kaner's emphasis on the oracle problem as one of the defining challenges in software testing education, and James Bach and Michael Bolton's oracle consistency heuristics, among others.

Bolton in particular has argued that the purpose of an oracle is not to "prove correctness" but to "detect problems." This distinction seems especially relevant to the question at hand.

Tests That Import from Config

Let us take a closer look at the second version from the introduction — the one that imports from config:

import { TAX_RATE } from './config';

test('calculates tax correctly', () => {
  const price = 1000;
  const tax = calculateTax(price);
  expect(tax).toBe(price * TAX_RATE);
});

This test looks reasonable. It follows the DRY principle, and if the value changes, you only need to update it in one place.

However, when viewed through the lens of Howden's principle, this test may have a problem. The expected value comes from the same config as the implementation. If someone accidentally changes TAX_RATE to 0.01, the test will continue to pass. The test has become a mirror of the implementation — and a mirror reflects the same distortions as the original.

Does Hardcoding Solve the Problem?

Then what about the first version — the one with the hardcoded 100?

test('calculates tax correctly', () => {
  const price = 1000;
  const tax = calculateTax(price);
  expect(tax).toBe(100); // assuming 10% tax rate
});

By hardcoding 100, the expected value becomes independent of the implementation. If TAX_RATE is accidentally changed, the test will fail and catch the problem.

But this introduces a different issue. The 100 is a hardcoded value, and the test will also fail when TAX_RATE is intentionally changed. That is not "problem detection" — it is just a test maintenance oversight.

Furthermore, if the reasoning behind 100 is simply "the config file says 0.1, so 1000 × 0.1 = 100," then you have just manually copied the config value. That is essentially the same as duplicating a hardcoded constant.

On the other hand, if the reasoning is "the law mandates a 10% tax rate," then the expected value is grounded in an external fact that is independent of the implementation — exactly the kind of "external mechanism" Howden described.

In other words, even for the same hardcoded 100, the meaning changes depending on whether you can explain the expected value without looking at the code. This seems to be the line that separates a duplicated hardcode from an independent oracle. There may be better criteria, but this is what I arrived at in my research.

Reconsidering the Relationship with DRY

To summarize the story so far: importing from config follows DRY, while hardcoding expected values appears to violate it. Following DRY undermines oracle independence; preserving oracle independence seems to violate DRY. The two principles appear to be in conflict.

However, when we go back to the original definition of DRY, it turns out they may not conflict at all.

Andy Hunt and Dave Thomas addressed this misconception explicitly in the 20th Anniversary Edition of The Pragmatic Programmer:

DRY is about the duplication of knowledge, of intent. It's about expressing the same thing in two different places, possibly in two totally different ways.

In a section titled "Not All Code Duplication is Knowledge Duplication," they explain that even if the code for validating age and validating quantity is identical, those validations represent different pieces of knowledge. That is a coincidence, not a DRY violation.

Let us apply this to test expected values. The production code TAX_RATE = 0.1 represents the knowledge "this system operates with a tax rate of 0.1." The test expect(tax).toBe(100) represents the knowledge "for a 10% tax rate, the tax on 1000 should be 100."

These two happen to involve the same value of 0.1, but they express different knowledge. The former is a system configuration; the latter is a verification of a business rule. If we follow the definition in The Pragmatic Programmer strictly, hardcoding 0.1 in a test is not a DRY violation — it is simply "different knowledge that happens to share the same value."

In other words, DRY and oracle independence may not actually be in conflict, once we return to DRY's original definition. The apparent conflict only arises when DRY is narrowly interpreted as "eliminate code duplication."

I cannot say with certainty that this interpretation is correct. But based on the original definition, calling a hardcoded test expected value a DRY violation does seem like a bit of a stretch.

When Sharing Config Values Becomes Dangerous

Let me return to the config-sharing problem. Even when hardcoding is justified, there is a more structural concern worth considering.

When every unit in a system references the same config constant, an incorrect value in that config propagates to every unit that depends on it. If the tests also reference the same config, then no one — not even the tests — catches the mistake. This risk exists regardless of whether the system is a monolith or a microservice architecture. It is an inherent risk of depending on a single source of truth.

Thinking about this at the unit level, as long as each unit's tests trust input values as "presumably correct" and use them as-is, an error in those values will propagate through every layer of tests without being caught. This may be a somewhat strong claim, but logically, it should hold.

Testing Properties Instead of Exact Values

That said, preparing independent hardcoded expected values for every config value is not practical. Tax rates have legal grounds, but what about a retry count? There is usually no external authority that dictates "this should be 3." For values like these, finding an independent oracle is genuinely difficult.

One approach that may help is testing properties and relationships rather than exact values:

test('retry count is within a reasonable range', () => {
  expect(MAX_RETRY).toBeGreaterThan(0);
  expect(MAX_RETRY).toBeLessThanOrEqual(10);
});

test('retry count and timeout are consistent', () => {
  expect(MAX_RETRY * RETRY_INTERVAL).toBeLessThanOrEqual(TIMEOUT);
});

Tests like these do not need to be updated when values change. They only catch unintended breakage. And because the constraints are grounded in design intent — which serves as an external justification — they seem consistent with Howden's principle.

It Is a Tradeoff After All

Howden's principle is theoretically sound. The argument that all expected values should be independent of the implementation is logically correct. But applying independent verification to every single config value is not realistic.

So this is, I believe, a tradeoff.

What matters most is whether you are aware that you are making a tradeoff. There is a significant difference between deciding "this value should ideally be verified independently, but we are sharing it from config as a conscious cost-benefit decision" and simply sharing it without any thought.

Coming back to the original question: does it matter whether the expected value is hardcoded or imported from config? I believe it does — but not because one approach is universally better. What matters is whether the choice was made deliberately, with an understanding of what is gained and what is lost.

Perhaps the value of a test is determined not by its form, but by the quality of the judgment behind it. I may be off the mark, but that is the conclusion I reached through this research.

References

William E. Howden, "Theoretical and Empirical Studies of Program Testing", IEEE Transactions on Software Engineering, 1978
William E. Howden, "A Survey of Dynamic Analysis Methods", in Software Validation and Testing Techniques, IEEE Computer Society, 1981
Andy Hunt, Dave Thomas, "The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition", Addison-Wesley, 2019
Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, Shin Yoo, "The Oracle Problem in Software Testing: A Survey", IEEE Transactions on Software Engineering, 2015
The Oracle Problem - YLD Blog
The Oracle Problem and the Teaching of Software Testing - Cem Kaner
Oracles Are About Problems, Not Correctness - DevelopSense
The DRY Principle and Incidental Duplication - Anthony Sciamanna

Will React Compiler Make Manual Memoization Obsolete? — Things to Know Before Adopting It

usapop — Mon, 26 Jan 2026 08:31:07 +0000

In October 2025, React Compiler 1.0 was released as a stable version. It's said that we'll no longer need to manually write useMemo, useCallback, or React.memo. For those of us who have struggled with forgetting dependencies or getting them wrong, this is a welcome evolution. That said, there are some things that seem worth knowing before adopting it, so I've tried to organize them here. Some of my understanding may be incorrect, so please refer to the official documentation for accurate information.

What is React Compiler?

It's a tool that automatically inserts memoization at build time — something we previously had to write manually. It's already running in production at Meta, including Quest Store, with reported improvements of up to 12% faster initial loads and more than 2.5× faster interactions.

https://react.dev/blog/2025/10/07/react-compiler-1

Installation

React Compiler is provided as a Babel plugin.

npm install -D --save-exact babel-plugin-react-compiler@latest

For Vite, you can configure it through the babel option in vite-plugin-react:

// vite.config.ts
export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: [
          ['babel-plugin-react-compiler', { target: '18' }], // For React 18
        ],
      },
    }),
  ],
});

It works with React 17 and above. For versions below React 19, you'll need to add the react-compiler-runtime package and specify the version with the target option.

https://react.dev/learn/react-compiler/introduction

Differences from React.memo

Aspect	React.memo / useMemo	React Compiler
Scope	Explicitly specified	Automatic analysis
Granularity	Component or value level	Down to expression level (even after conditionals)
Dependencies	Explicit array	Implicit
Custom comparison (2nd arg of React.memo)	Possible	Not possible
Adoption cost	None	Build configuration required

The biggest difference is that dependency arrays are no longer needed.

Previously, we had to explicitly specify dependencies:

const filtered = useMemo(() => {
  return items.filter(item => item.category === category);
}, [items, category]);

With React Compiler, you can write it like this:

const filtered = items.filter(item => item.category === category);

While this is simpler, it also means you can no longer tell from the code what's being memoized or what it depends on. This might cause some difficulties during code reviews or debugging.

Memoization After Conditional Branches

One technical advantage of React Compiler is that it can memoize even after conditional branches:

// Manual approach would violate Rules of Hooks
function Component({ data }) {
  if (!data) return null;
  const processed = useMemo(() => expensiveProcess(data), [data]); // NG
}

// React Compiler handles this fine
function Component({ data }) {
  if (!data) return null;
  const processed = expensiveProcess(data); // Automatically memoized
}

Variables after early returns are also automatically memoized, giving you more freedom in your code structure.

Patterns to Check Before Adopting

React Compiler optimizes code that follows the "Rules of React." These are the rules that must be followed for React to work correctly:

Components and hooks are pure (same inputs return same outputs)
No side effects during rendering
Don't directly mutate props or state

https://react.dev/reference/rules

When the compiler detects a rule violation, it skips that component or hook and continues compiling the rest. The skipped parts will work as before, so the app won't break.

However, you might want to verify the behavior if you have code like the following:

Referencing external mutable objects

const data = globalCache[id]; // Reading external mutable state during render

If you read external mutable objects during render, the compiler may not be able to track dependencies correctly.

Mutable array operations

const sorted = items.sort((a, b) => a.id - b.id); // Mutates the original array

sort() directly modifies the original array, which may cause React's re-render detection to not work properly. It's safer to use [...items].sort() or toSorted().

Using ref values in calculations

const doubled = countRef.current * 2; // Reading ref during render

Reading ref.current during render will trigger a warning from ESLint's react-hooks/refs rule. Since ref changes are not reactive, they don't work well with memoization.

Date.now() or Math.random()

const timestamp = Date.now(); // May cause compiler to skip optimization due to impurity

These return non-deterministic values, so they get caught by the compiler's purity check. ESLint's react-hooks/purity rule will also warn about this.

Custom comparison with React.memo's second argument

// React.memo allowed controlling when to skip re-renders with the 2nd argument
const MemoizedComponent = React.memo(Component, (prevProps, nextProps) => {
  // Return true to skip re-render
  return prevProps.item.id === nextProps.item.id;
});
// React Compiler doesn't support this kind of custom comparison logic

With React.memo's second argument, you could compare only some props or do deep comparison. React Compiler doesn't support this control, so if you need such comparison, it seems the recommendation is to reconsider the design itself.

If problems occur, you can opt out specific components using the 'use no memo' directive:

function SuspiciousComponent() {
  'use no memo';
  // This component won't be compiled
}

https://react.dev/reference/react-compiler/directives/use-no-memo

Patterns That Cause Compiler to Skip Optimization

There are patterns reported in GitHub Issues and the community where the compiler skips optimization that aren't detected by ESLint rules. These may be supported in future versions, but as of version 1.0, the following patterns seem to require attention.

Using finally clauses

There are reports that using try...catch...finally or try...finally causes the component to be excluded from optimization.

// May not be optimized
async function fetchData() {
  try {
    const res = await fetch('/api/data');
    return await res.json();
  } finally {
    console.log('Done');
  }
}

As a workaround, extracting the finally logic into a custom hook allows the calling component to be optimized.

Conditional branches or Optional Chaining inside try...catch

There are reports that using if statements or ?. inside try...catch blocks prevents optimization.

// May not be optimized
try {
  const data = await res.json();
  setValue(data.user?.name ?? 'Unknown'); // Optional Chaining inside try
} catch {
  console.error('Error');
}

Moving conditional branches and Optional Chaining outside the try...catch block reportedly allows optimization.

Dynamic import inside components

// May not be optimized
async function handleClick() {
  const { helper } = await import('./utils');
  helper();
}

Extracting the import to a function outside the component allows optimization.

These patterns are not explicitly documented in the official documentation and are based on community reports. You can verify actual behavior in the React Compiler Playground.

Should You Remove useMemo/useCallback?

According to the official documentation, for new code, the recommendation is to let the compiler handle it, while using useMemo/useCallback when the compiler's automatic decisions don't produce the intended behavior. For existing code, since removing them may change the compilation output, the recommendation is to either leave them in place or remove them only after thorough testing.

Decision Flowchart

Here's a summary of the decision flow based on the above.

Considering React Compiler
            │
            ▼
    ┌───────────────────┐
    │  New project?     │
    └─────────┬─────────┘
              │
     ┌────────┴────────┐
     │Yes              │No
     ▼                 ▼
┌─────────────┐  ┌──────────────────────────┐
│Can follow   │  │Is existing codebase      │
│Rules of     │  │pure and immutable?       │
│React?       │  └────────────┬─────────────┘
└──────┬──────┘               │
       │               ┌──────┴──────┐
  ┌────┴────┐          │Yes          │No
  │Yes      │No        ▼             ▼
  ▼         ▼     ┌───────────┐  ┌─────────────┐
┌──────┐ ┌──────┐ │Using      │  │Gradual      │
│Worth │ │Review│ │React.memo │  │adoption     │
│trying│ │code  │ │2nd arg?   │  │or wait      │
└──┬───┘ │design│ └─────┬─────┘  └─────────────┘
   │     │first │       │
   │     └──────┘  ┌────┴────┐
   │               │Yes      │No
   │               ▼         │
   │        ┌─────────┐      │
   │        │Gradual  │      │
   │        │adoption │      │
   │        │or wait  │      │
   │        └─────────┘      │
   │                         │
   └────────────┬────────────┘
                ▼
    ┌───────────────────────┐
    │Try in small scope     │
    │and verify behavior    │
    └───────────────────────┘

The key point is "whether the code is pure and immutable." Since React Compiler optimizes based on the assumption of purity, codebases with many mutable operations or side effects may have more places where the compiler skips, or unexpected behavior may occur. According to the official documentation, changes in memoization may also affect useEffect firing timing. If immutable design is thoroughly implemented, adoption tends to go smoothly.

Having E2E tests makes it easier to verify behavior after adoption. Even without tests, adoption is possible, but it might be better to proceed carefully by pinning the compiler version (--save-exact). According to the official documentation, memoization behavior may change even in minor or patch versions, so manually verifying updates rather than auto-upgrading is recommended.

Current Thoughts

React Compiler 1.0 is a stable release with track record in Meta's production environment. Being freed from manual memoization is a significant benefit. It's genuinely nice that bugs from dependency array mistakes and time spent deciding how much to memoize will decrease.

If you're considering adoption, I think it would be good to first enable the ESLint plugin and check how many Rules of React violations exist in your codebase. The recommended or recommended-latest presets in eslint-plugin-react-hooks include compiler-specific rules and can be used even without installing the compiler. The unsupported-syntax rule can detect unsupported syntax, though I haven't been able to confirm whether it detects finally clauses or conditional branches inside try-catch. If you want to know for certain, you might want to try it in the React Compiler Playground or use tools like react-compiler-marker.

Note that there used to be a separate package called eslint-plugin-react-compiler, but it has now been integrated into eslint-plugin-react-hooks. If you have it installed, it's recommended to remove it and migrate to eslint-plugin-react-hooks@latest.

References

Why Can You Right-Click Save a WebGL Canvas? A 20-Year History of Browser Graphics

usapop — Sun, 25 Jan 2026 08:05:16 +0000

Below is a 3D fractal called "Mandelbulb" being rendered in real-time by the GPU. You can drag to rotate it.

Try right-clicking and saving the image at an angle you like. It just works.

When you think about it, this is pretty remarkable. Every frame, the shader is running calculations on potentially hundreds of thousands to millions of pixels on the GPU, and with a single right-click, it becomes a PNG file. Why can GPU-rendered content be saved as a regular PNG?

I got curious about this, so I did some research on browser graphics technology and its evolution — from the birth of the Canvas element to WebGL and JavaScript image export APIs. There may be some inaccuracies, so please take this as a learning reference.

Before Canvas: The Plugin Era

Before Canvas, displaying rich graphics in browsers required plugins.

Java applets, introduced in 1995, were widely used for interactive content in browsers. The early beta version of Minecraft apparently ran as a Java applet. Adobe Flash, introduced in 1996, dominated games, animations, and video playback.

However, both required plugin installation and had numerous security issues. Canvas would eventually become the plugin-free replacement for these technologies.

The Birth of the Canvas Element (2004)

The Canvas element was first committed to WebKit on May 25, 2004, by Apple engineer Richard Williamson. It was reportedly developed to power Dashboard widgets in Mac OS X 10.4 Tiger.

The reaction from the web standards community was mixed. Eric Meyer reportedly responded with "What the bleeding hell?!?" expressing concerns about proprietary extensions.

Later, Ian Hickson of WHATWG organized the specification draft based on Apple's implementation. Firefox 1.5 added support in 2005, Opera in 2006, and standardization gradually progressed.

Year	Event
May 2004	Apple implements Canvas in WebKit
Aug 2004	First WHATWG spec draft
Nov 2005	Firefox 1.5 support
2006	Opera support
Mar 2007	Apple claims Canvas-related patents
Jun 2008	Apple releases patents under W3C royalty-free terms
Oct 2014	W3C Recommendation as part of HTML5

toDataURL(): The First Image Export Method

The toDataURL() method, implemented around the same time as Canvas, allows you to get Canvas content as a Base64-encoded Data URL.

const canvas = document.getElementById('canvas');
const dataURL = canvas.toDataURL('image/png');
// "data:image/png;base64,iVBORw0KGgo..."

It was reportedly available as early as Safari 2.0 (2005), though the spec wasn't finalized yet and behaviors like MIME type handling may have differed from today. This enabled JavaScript to treat Canvas content as images.

However, Base64 encoding increases size by about 33% compared to the original binary data. For large images, URL length limits could sometimes be an issue.

The Arrival of WebGL (2011)

In 2009, the Khronos Group established the WebGL Working Group with participation from Apple, Google, Mozilla, Opera, and others. In March 2011, the WebGL 1.0 specification was officially released.

WebGL is a JavaScript binding for OpenGL ES 2.0, enabling GPU-accelerated 3D graphics in the browser. It's provided as a webgl context separate from Canvas's 2D context.

const canvas = document.getElementById('canvas');
const gl = canvas.getContext('webgl');

Browser	WebGL 1.0 Support
Chrome 9	Feb 2011
Firefox 4	Mar 2011
Safari 5.1	Jul 2011 (*)
IE 11	Oct 2013

*Safari 5.1 had the feature implemented but disabled by default — it had to be enabled via the developer menu, so general users couldn't easily use it until later.

WebGL-rendered content is drawn on the same Canvas element, so it can be captured with toDataURL(). However, WebGL requires consideration of the preserveDrawingBuffer option.

The preserveDrawingBuffer Trap

For performance optimization, WebGL doesn't guarantee buffer contents after drawing completes. If you try to capture an image from outside the drawing function (requestAnimationFrame), the content may be empty (or black).

For example, if you call toDataURL() from a button click handler, the buffer contents are already undefined, so you'll get a black image. You can capture it immediately after shader drawing (within the same frame), but you need to be aware of timing.

If you want to freely read the buffer from JavaScript at any time, specify preserveDrawingBuffer: true when creating the context.

// Specify when creating WebGL context
const gl = canvas.getContext('webgl', {
  preserveDrawingBuffer: true
});

With this option enabled, drawing buffer contents are preserved and you can always get correct images with toDataURL(). However, unless you have a clear reason like screenshot functionality, it's generally recommended to keep it false (default) due to performance impact.

By the way, "right-click save" works because the browser internally reads the buffer at the appropriate timing in the rendering pipeline.

Side Note: Browser Right-Click Save Has Improved

In the past (around 2013), there were bug reports where right-click saving WebGL canvas in Firefox would result in a black image. At the time, preserveDrawingBuffer handling varied between browsers, and some behaviors were "undefined" in the spec.

Modern browsers have improved to properly read the buffer at the compositor (screen compositing) timing, so right-click save works correctly even with preserveDrawingBuffer: false. The timing issue remains when calling toDataURL() from JavaScript, but users saving via right-click no longer need to worry about it.

Another Side Note: When Screenshots Turned Videos Black

Going further back, in Windows from the 1990s to early 2000s, pressing PrintScreen while playing video would result in just the video portion being black (or magenta or green).

This was caused by "hardware overlay." PCs at the time had limited performance, so video playback wrote directly to a dedicated video memory region, and the GPU overlaid that region's content during screen composition. The OS screenshot function couldn't recognize this overlay region and only captured the mask color (black or a specific color).

This issue was resolved after Windows Vista introduced the Desktop Window Manager (DWM). With DWM, all windows are composited by the GPU, making the overlay concept unnecessary.

toBlob(): A More Efficient Method (2013~)

The toBlob() method was added to solve the Base64 overhead problem of toDataURL().

canvas.toBlob((blob) => {
  // Get as Blob object
  const url = URL.createObjectURL(blob);
  // Create download link
  const a = document.createElement('a');
  a.href = url;
  a.download = 'image.png';
  a.click();
}, 'image/png');

Blob handles binary data directly, so it's memory-efficient and can process large images without issues.

Browser	toBlob Support
Firefox 19	Feb 2013
Chrome 50	Apr 2016
Safari 11	Sep 2017 (macOS)

*Mobile browsers (iOS Safari, etc.) may have different support timelines.

Since Chrome's support came as late as 2016, polyfills were needed for a long time. The polyfill mechanism was surprisingly simple: decode the Base64 string from toDataURL() with atob(), convert to Uint8Array, then create a Blob object with new Blob(). It was achieved by combining existing APIs.

// Basic toBlob() polyfill mechanism
function dataURLtoBlob(dataURL) {
  const parts = dataURL.split(',');
  const byteString = atob(parts[1]);
  const mimeType = parts[0].split(':')[1].split(';')[0];

  const ab = new ArrayBuffer(byteString.length);
  const ia = new Uint8Array(ab);
  for (let i = 0; i < byteString.length; i++) {
    ia[i] = byteString.charCodeAt(i);
  }

  return new Blob([ab], { type: mimeType });
}

These days, you can convert in one line using the fetch() API.

const blob = await fetch(dataURL).then(r => r.blob());

Data URLs can be passed as fetch() arguments, so there's no need to manually decode Base64 anymore.

How Right-Click Save Works

The browser's "Save Image As" function also works on Canvas elements. The browser likely performs processing equivalent to toBlob() internally and exports the Canvas's current state as a PNG image (though this is just my speculation — I might be wrong).

Why PNG?

There seem to be reasons why PNG is the default for Canvas image saving.

First, PNG uses lossless compression, so Canvas content can be saved without quality degradation. JPEG uses lossy compression, so quality degrades with each save.

Second, Canvas can have transparent backgrounds, and PNG supports alpha channels (transparency). JPEG doesn't support transparency, so transparent areas become black or white.

Also, PNG is patent-free. It was originally developed to avoid GIF patent issues, making it easier to adopt as a web standard.

By the way, browser add-ons or extensions (like "Save image as Type") let you save in other formats like JPEG or WebP from the right-click menu.

For WebGL too, since framebuffer content is reflected on the Canvas element, it can be saved the same way. Millions of pixels calculated by the GPU every frame can be captured as a still image with a single right-click.

Saving as Video: captureStream() and MediaRecorder (2016)

Not just still images — it became possible to save Canvas animations as video. This was a major paradigm shift.

The Struggles Before MediaRecorder

Before 2016, turning Canvas animations into video in the browser was extremely difficult. The main methods were as follows, but none were practical.

Sending frames as DataURL to a server

Generate PNG/JPEG images with toDataURL() every frame and send them to a server to convert with FFmpeg. This required sending and receiving massive amounts of image data, creating high network and server load, and losing real-time capability.

JavaScript encoders (whammy.js, etc.)

whammy.js, which appeared around 2012, converted Canvas frames to WebP and packed them into a WebM container. However, it couldn't do inter-frame compression, resulting in enormous file sizes. It was a "better than GIF" last resort option.

GIF encoders

Libraries like gif.js could generate GIF animations, but they were limited to 256 colors and encoding was slow.

The Browser Became an Encoder

In 2016, the arrival of captureStream() and the MediaRecorder API changed everything.

The browser itself became a video encoder. Browsers now natively perform proper inter-frame compression using codecs like VP8/VP9. JavaScript just calls the API, and encoding is handled by the browser's optimized native code.

// Get stream from Canvas
const stream = canvas.captureStream(30); // 30fps

// Record with MediaRecorder
const recorder = new MediaRecorder(stream, {
  mimeType: 'video/webm'
});

const chunks = [];
recorder.ondataavailable = (e) => chunks.push(e.data);
recorder.onstop = () => {
  const blob = new Blob(chunks, { type: 'video/webm' });
  // Download as video file
};

recorder.start();
// Stop after a few seconds
setTimeout(() => recorder.stop(), 5000);

What Changed

Aspect	Before MediaRecorder	After MediaRecorder
Encoding	JS implementation (slow)	Browser native (fast)
Compression	No inter-frame compression	VP8/VP9 inter-frame compression
File size	Huge	Practical
Real-time	Difficult	Possible
Server dependency	Often required	Completely client-side

The background for these APIs was WebRTC.

In 2010, Google acquired GIPS (a VoIP and video conferencing software company) and obtained codec and echo cancellation technologies. In 2011, they open-sourced these as WebRTC. The goal was "enabling real-time video calls in the browser without plugins." At the time, video calls on Skype and Facebook required Flash or plugins.

For WebRTC, getUserMedia() to handle video/audio from cameras and microphones, and the MediaStream interface to handle them uniformly, were created. captureStream() is an extension that allows generating MediaStream from Canvas elements too. In other words, the real-time video processing infrastructure built for video calls was opened up to Canvas as well.

Being able to treat Canvas-drawn content as a "stream" enabled not just recording but also live streaming via WebRTC.

Browser	captureStream Support
Firefox 43	Dec 2015
Chrome 52	Jul 2016
Safari 11	Sep 2017

How to Save Videos

Unlike still images, videos can't be saved with right-click. You need to explicitly write download processing in JavaScript to download the recorded Blob.

recorder.onstop = () => {
  const blob = new Blob(chunks, { type: 'video/webm' });

  // Generate URL from Blob
  const url = URL.createObjectURL(blob);

  // Create download link and click
  const a = document.createElement('a');
  a.href = url;
  a.download = 'recording.webm';
  a.click();

  // Release URL when done
  URL.revokeObjectURL(url);
};

This means you don't have the convenience of "right-click to save" like with still images — the application needs to implement a save UI. This is a major difference from still image saving.

Summary

Year	Technology	What Became Possible
2004	Canvas + toDataURL	Get 2D graphics as Data URL
2011	WebGL	GPU-accelerated 3D graphics
2013~2016	toBlob	Efficient image retrieval as Blob
2016	captureStream + MediaRecorder	Recording and saving as video
2018~	OffscreenCanvas	Drawing and image generation in Web Workers

The element Apple created 20 years ago for Dashboard widgets has evolved to the point where we can render 3D fractals calculated by the GPU in real-time and save them as still images or videos.

Recently, OffscreenCanvas allows running heavy drawing processing on Web Workers without blocking the main thread, and generating images directly. Canvas has finally been freed from the main thread.

Furthermore, WebGPU is being standardized as WebGL's successor. With lower-level GPU access and WGSL, a new shader language, browser graphics expression still has room to evolve.

The "right-click save" we use without thinking twice is built on layers of Canvas, WebGL, Blob, and various other APIs — I found that quite fascinating.

References

What I Didn't Know About Icon Library Licenses (And You Might Not Either)

usapop — Fri, 23 Jan 2026 18:07:15 +0000

TL;DR

Icon libraries with MIT or ISC licenses don't require visible attribution in your UI
Font Awesome Free is actually a combination of three different licenses — keeping the embedded comments satisfies attribution requirements
For new projects, Lucide or Heroicons offer simpler licensing with less friction

Font Awesome, Lucide, Heroicons… When choosing an icon library for work projects, I suspect many of us don't give much thought to licensing.

I used to think "it's MIT licensed, so it's fine" and left it at that. But when I looked into it more closely, I discovered quite a few things I didn't know. I thought it might be helpful to share what I found.

Chapter 1: What "Free" Really Means

Two Meanings of "Free"

When you hear "free icon library," you probably think "no cost." But in the open source world, there's another meaning.

"Think free as in free speech, not free beer."

These are the words of Richard Stallman, founder of the free software movement.

Free as in beer — No cost. But you can't see the source code or modify it (e.g., Adobe Reader)
Free as in speech — You can use it freely, view the source, modify it, and redistribute it (e.g., Linux)

For icon libraries:

Font Awesome Free → No cost, but Pro features are unavailable
Lucide, Heroicons → No cost, and you can freely modify and redistribute the source code

This distinction matters when it comes to choosing licenses.

Chapter 2: A Brief History of Web Icons

2012: The Explosive Growth of Font Awesome

In the 2000s, web icons were mostly individual PNG images. They weren't scalable, and they required many HTTP requests.

In 2011, Twitter Bootstrap (now Bootstrap) shipped with Glyphicons bundled in. Glyphicons was an icon set created by Jan Kovařík — originally a paid product, but around 250 icons were provided free of charge for Bootstrap. Then in 2012, Dave Gandy released Font Awesome, and it became the most popular new project on GitHub.

In 2016, Font Awesome raised $1,076,960 (over $1 million) on Kickstarter, reportedly setting a record for software projects at the time.

Why Glyphicons Disappeared from Bootstrap 4

Glyphicons was standard in Bootstrap 3, but it was removed in Bootstrap 4. The reasons included: file size bloat for users who didn't need icons, many users were already using Font Awesome or other icon fonts, and it made sense to delegate icon development to specialized projects.

Feather Icons → Lucide: A Fork Story

In 2017, Cole Bemis released Feather Icons. It was a minimal and beautiful icon set, but maintenance gradually slowed down, with over 300 issues left unaddressed.

In 2020, the community forked it and launched Lucide. It has since grown into an active project with over 1,500 icons. This is open source succession at its finest.

Chapter 3: Practical Differences Between Licenses

License Quick Reference

License	Commercial Use	Modify/Redistribute	Attribution	Copyleft	Notes
MIT	✅	✅	In source code	None	Most simple. Most popular on GitHub
ISC	✅	✅	In source code	None	Nearly identical to MIT. npm's default
Apache 2.0	✅	✅	In source code	None	Includes patent clause. Common in Google projects
CC BY 4.0	✅	✅	Required in principle	None	Designed for content. Used by Font Awesome icons
SIL OFL 1.1	✅	✅	In source code	None	Font-specific. Cannot be sold standalone
GPL	✅	✅	Derivatives must use same license	Yes	If you distribute derivatives, you must release source code under the same license

MIT / ISC — The Easiest for Practical Use

Keep the copyright notice and license text in your source code

That's basically all you need to do. No visible attribution in the UI is required. When you run npm install, license files are automatically included in locations like node_modules/lucide-react/LICENSE — just don't delete them and you're fine.

Lucide, Heroicons, Tabler Icons, Phosphor Icons, and Bootstrap Icons all fall into this category. These licenses are quite easy to work with for commercial projects.

Apache 2.0 — The Patent Clause Matters

Similar to MIT, but includes explicit permission regarding patents. Often adopted by projects involving large corporations.

Common in Google's Material Symbols and Android-related projects. Attribution is "welcomed but not required."

CC BY 4.0 — A License for Content

Creative Commons was originally designed for content like images, music, and text. "BY" stands for "Attribution."

Font Awesome Free's icon SVGs and JS files use this license. In principle, attribution is required, but Font Awesome has made special accommodations (more on this below).

Chapter 4: Font Awesome Free Actually Has Three Licenses

The Multi-License Trap

Font Awesome Free isn't under a single license. This might come as a surprise.

Component	License	Specific Files
Icons (design)	CC BY 4.0	SVG files
Font files	SIL OFL 1.1	.woff2, .ttf, etc.
Code	MIT	CSS, JavaScript

Even when using the SVG-JS model via npm, these three licenses are all in play.

But It's Not That Strict in Practice

The official LICENSE.txt states:

Attribution is required by MIT, SIL OFL, and CC BY licenses. Downloaded Font Awesome Free files already contain embedded comments with sufficient attribution, so you shouldn't need to do anything additional when using these files normally.

In other words, if you keep the embedded comments in the downloaded files, no additional attribution is required.

⚠️ Build Tool Behavior

Modern build tools like Webpack, Vite, and esbuild extract comments starting with @license, @preserve, or /*! into separate files (.LICENSE.txt) by default. Font Awesome's files include these comments, so the license information is preserved. However, since the comments are removed from the original JS files, it's worth checking your build output to be sure.

When Copying Individual SVGs

If you copy individual SVGs from the website, they may not include comments. In that case, you can add a license comment inside the SVG. This way, you don't need to display attribution in your footer or UI.

<!-- Font Awesome Free 6.x by @fontawesome - https://fontawesome.com License - CC BY 4.0 -->
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">...</svg>

Of course, you can also add attribution in your about page or footer.

<footer>
  Icons by <a href="https://fontawesome.com">Font Awesome</a> (CC BY 4.0)
</footer>

Brand Icons Are a Different Matter

Brand icons included in Font Awesome (company logos, etc.) involve trademark issues.

Even if the license is MIT or CC BY, you must follow each company's Brand Guidelines. For example, modifying Twitter (X)'s logo without permission or using it in a competitor's context is not allowed. This is separate from licensing.

Chapter 5: Font Awesome Pro Token Management

Font Awesome Pro requires an API token when installing via npm. Here's the difference from the Free version.

Free Version: No Token Required

npm install --save @fortawesome/fontawesome-free

That's all you need.

Pro Version: Token Required

The Pro version is fetched from Font Awesome's private npm registry, so an authentication token is required. Configure it in your project's .npmrc file:

# .npmrc
@fortawesome:registry=https://npm.fontawesome.com/
//npm.fontawesome.com/:_authToken=${FONTAWESOME_NPM_AUTH_TOKEN}

Manage your token via environment variables — don't write it directly in the .npmrc file.

Chapter 6: Comparing Icon Libraries

There are plenty of alternatives to Font Awesome.

Library	License	Icon Count	Attribution	Token
Font Awesome Free	CC BY 4.0 + SIL OFL + MIT	2,000+	Required (embedded OK)	Not required
Font Awesome Pro	Commercial license	30,000+	Not required	Required
Lucide	ISC	1,500+	Not required	Not required
Heroicons	MIT	450+	Not required	Not required
Tabler Icons	MIT	5,900+	Not required	Not required
Bootstrap Icons	MIT	2,000+	Not required	Not required
Phosphor Icons	MIT	9,000+	Not required	Not required
Material Symbols	Apache 2.0	2,500+	Recommended (not required)	Not required

How to Choose

If simplicity is your priority:

Lucide — A fork of Feather Icons, actively developed
Heroicons — Official Tailwind CSS icons, high design quality

If icon count is your priority:

Tabler Icons + Phosphor Icons — Both MIT, over 15,000 combined

If ecosystem matters:

Font Awesome Pro — Over 30,000 icons, $120/year
Material Symbols — Great compatibility with Google's ecosystem

Chapter 7: Where Should You Put Attribution?

Is UI Attribution Required?

License	Source Code/LICENSE	UI (Footer, etc.)
MIT	✅ Required	Optional
ISC	✅ Required	Optional
Apache 2.0	✅ Required	Optional
CC BY 4.0	✅ Required	Recommended if comments removed
SIL OFL 1.1	✅ Required	Optional

For MIT-licensed libraries, visible attribution in HTML, CSS, or UI is generally not considered necessary.

What You Might Want to Do Anyway

# THIRD_PARTY_LICENSES.md

## Icons

### Lucide Icons
- License: ISC
- https://lucide.dev/license

With MIT or ISC licenses, you don't need visible attribution in the UI. However, you do need to keep license information somewhere in your project's source code. Creating a file like this can be helpful when legal review comes around.

There are also tools to auto-generate license lists:

npx license-checker --json > licenses.json

Conclusion

When choosing an icon library for commercial projects, it's easy to default to "just use Font Awesome." But understanding the license structure can give you peace of mind.

Personally, I tend to use Lucide or Heroicons for new projects. They have simple, single licenses (MIT/ISC), no token management required, and official React/Vue components — less friction in practice.

Font Awesome Free is perfectly fine for commercial use, so if you're already using it in an existing project, there's no need to migrate. Just keep the embedded comments and you'll meet the attribution requirements.

I hope this article helps someone out there.

References

Licenses

Choose a License — Helpful for choosing a license
MIT License - Wikipedia

Icon Libraries

History

How Font Awesome became the most funded software project on Kickstarter
Adam Wathan - 2020 Year in Review — The birth of Heroicons
A Brief History of Free and Open Source Software Licensing

true-form-length: A Library for Accurate Character Counting in Web Forms

usapop — Fri, 23 Jan 2026 14:59:36 +0000

Background

I previously wrote about the hidden pitfalls in JavaScript character counting. The issues go beyond the well-known surrogate pair problem:

Issue	JS `.length`	Server receives
Emoji `🎉`	2	1 character
`a\nb\nc` (textarea)	5	7 chars (`\n` → `\r\n`)
Lone surrogate `\uD800`	1	MySQL error 💥

That last one is especially problematic—a lone surrogate can cause your database insert to fail entirely.

I kept running into these issues in my own projects, so I ended up creating a small library to handle them. It might be useful for others dealing with similar problems, so I'm sharing it here.

What is true-form-length

true-form-length is a zero-dependency TypeScript library that counts characters as your server will receive them.

npm install true-form-length

Features

Accurate character counting - Counts code points, not UTF-16 code units
CRLF normalization - Matches HTTP form submission behavior
Lone surrogate detection - Identifies and removes invalid UTF-16 sequences
UTF-8 byte length - For database byte-limit validation
URL-encoded length - For query parameter validation
React, Vue, and Lit components - Drop-in UI components

Basic Usage

import { countChars } from 'true-form-length'

// Simple counting
const result = countChars('Hello 🎉')
console.log(result.length)     // 7 (not 8)
console.log(result.byteLength) // 10 (UTF-8 bytes)

// Textarea with newlines
const textarea = countChars('Line1\nLine2')
console.log(textarea.length)   // 13 (accounts for \n → \r\n)

The countChars function returns:

interface CountResult {
  length: number           // Code points (MySQL CHAR_LENGTH compatible)
  byteLength: number       // UTF-8 bytes (MySQL LENGTH compatible)
  urlEncodedLength: number // Length after percent-encoding
  hasLoneSurrogate: boolean
  newlineCount: number
  wordCount: number
  sentenceCount: number
  readingTime: number      // Minutes (200 wpm)
}

Validation

Direct Validation

import { isValidLength, isValidByteLength } from 'true-form-length'

// VARCHAR(255) check
isValidLength(userInput, 255)

// Index byte limit check (MySQL InnoDB: 767 bytes)
isValidByteLength(userInput, 767)

Zod Integration

import { z } from 'zod'
import { maxLength, maxByteLength, noLoneSurrogates } from 'true-form-length'

const schema = z.object({
  username: z.string()
    .refine(maxLength(255), 'Must be 255 characters or less')
    .refine(noLoneSurrogates(), 'Contains invalid characters'),
  bio: z.string()
    .refine(maxByteLength(767), 'Too long for database index'),
})

Yup Integration

import * as yup from 'yup'
import { maxLength, noLoneSurrogates } from 'true-form-length'

const schema = yup.object({
  username: yup.string()
    .test('maxLength', 'Too long', maxLength(255))
    .test('valid', 'Invalid characters', noLoneSurrogates()),
})

React Components

The library includes Radix UI-style compound components:

import { Textarea } from 'true-form-length/react/textarea'

function PostEditor() {
  const [content, setContent] = useState('')

  return (
    <Textarea.Root
      maxLength={280}
      value={content}
      onValueChange={setContent}
      warningThreshold={0.9}
    >
      <Textarea.Input placeholder="What's happening?" />
      <Textarea.Counter />
      <Textarea.Error>Too many characters!</Textarea.Error>
      <Textarea.Progress />
    </Textarea.Root>
  )
}

Styling with data attributes:

textarea[data-state="over"] {
  border-color: red;
}

textarea[data-state="warning"] {
  border-color: orange;
}

/* Tailwind */
.counter {
  @apply text-gray-500 data-[state=over]:text-red-500 data-[state=warning]:text-amber-500;
}

Vue Components

<script setup lang="ts">
import { ref } from 'vue'
import * as Textarea from 'true-form-length/vue/textarea'

const content = ref('')
</script>

<template>
  <Textarea.Root v-model="content" :max-length="280" :warning-threshold="0.9">
    <Textarea.Input placeholder="What's happening?" />
    <Textarea.Counter />
    <Textarea.Error>Too many characters!</Textarea.Error>
  </Textarea.Root>
</template>

Presets

Built-in constants for common limits:

import {
  X_LIMIT,            // 280
  SMS_LIMIT,          // 160
  MYSQL_VARCHAR,      // 255
  MYSQL_TEXT,         // 65535
  INSTAGRAM_BIO,      // 150
  LINKEDIN_POST,      // 3000
  YOUTUBE_TITLE,      // 100
  TIKTOK_CAPTION,     // 2200
  X_URL_LENGTH,       // 23 (t.co wrapper)
} from 'true-form-length'

// X-style URL counting (all URLs = 23 chars)
const tweet = 'Check out https://example.com/very/long/path'
const result = countChars(tweet, { urlLength: X_URL_LENGTH })

URL Encoding Validation

For query parameters and path segments:

import {
  countChars,
  isValidUrlEncodedLength,
  truncateUrlEncoded
} from 'true-form-length'

// Japanese characters expand significantly when URL-encoded
const result = countChars('こんにちは')
console.log(result.urlEncodedLength) // 45 (each char = 9 encoded)

// Validate before building URLs
isValidUrlEncodedLength(searchQuery, 2000)

// Smart truncation that won't break encoded sequences
truncateUrlEncoded('Hello World', 10) // "Hello W"

Why Not Just `[...str].length`?

The spread operator fixes surrogate pairs, but misses CRLF normalization:

const text = 'Hello\nWorld'

// Spread operator
console.log([...text].length) // 11

// true-form-length (with CRLF normalization)
console.log(countChars(text).length) // 13

// What the server actually receives: 13 characters

And lone surrogates can still cause issues:

const problematic = 'Valid text\uD800more text'

// Spread operator
console.log([...problematic].length) // 19

// true-form-length
const result = countChars(problematic)
console.log(result.hasLoneSurrogate) // true
console.log(result.length) // 18 (lone surrogate excluded)

Notes

Zero dependencies
Single-pass algorithm
~50KB minified (tree-shakeable)
React/Vue hooks use proper memoization

Links

For more context on why these issues occur, I wrote about it in detail here: Beyond Surrogate Pairs: Hidden Pitfalls in JS Character Counting with PHP/MySQL

Mutable Pipeline Pattern — Revisiting My Thoughts on Dynamic Pipelines

usapop — Thu, 22 Jan 2026 13:54:12 +0000

Background

A while back, I wrote an article called The Dynamic Pipeline Pattern. The idea was to make method chains reconfigurable at runtime.

At the time, I just thought "this might be useful" and wrote it up. But since then, I've had opportunities to use similar structures in a few projects, and my thinking has evolved a bit.

So I'd like to take this chance to reorganize my thoughts under the name Mutable Pipeline Pattern.

The "Rigidity" of Traditional Method Chains

TypeScript

data
  .processA()
  .processB()
  .processC();

Python

(data
  .process_a()
  .process_b()
  .process_c())

This style is readable, and I think many people like it. I do too.

But there's one constraint: you can't change its shape at runtime.

Sometimes you want to skip processB under certain conditions
Sometimes you want to temporarily inject logging
Sometimes you want to reorder steps based on the situation

When these requirements come up, we usually end up with more if statements and flags. I think many of you have experienced this.

In a sense, this is like an iron pipe. You can change the data flowing through it, but the pipe's shape is fixed.

The Idea: Treating Pipelines as Data

The core idea from my previous article was this:

Instead of treating a pipeline as "code," hold it as an "array of processes" and reconfigure it at runtime with add/remove operations.

If you hold [A, B, C] as data, then changing the configuration becomes a data operation, not a code change.

Back then I called it "Dynamic Pipeline," but now I feel Mutable Pipeline fits better. The essence is "mutability" rather than "dynamism."

Here's what it looks like in practice:

TypeScript

const pipeline = new Pipeline<Data>()
  .add('a', processA)
  .add('b', processB)
  .add('c', processC);

// Runtime modification
pipeline.remove('b');
pipeline.addBefore('a', 'log', logStage);

// Execute
const result = pipeline.execute(inputData);

Python

pipeline = (Pipeline()
    .add('a', process_a)
    .add('b', process_b)
    .add('c', process_c))

# Runtime modification
pipeline.remove('b')
pipeline.add_before('a', 'log', log_stage)

# Execute
result = pipeline.execute(input_data)

Characteristics of the Mutable Pipeline Pattern

Let me organize this more clearly:

Aspect	Method Chaining	Mutable Pipeline
Structure	Fixed	Mutable
When changes happen	At deploy time	At runtime
Conditional logic	Expressed with if statements	Expressed as configuration changes
Focus	Data flow	Pipeline structure itself

The last point about "focus" is important. In this pattern, the emphasis is on managing the configuration rather than just flowing data through it.

Where This Might Be Useful

Here are some scenarios where I felt this pattern works well.

Temporary Debugging in Production

Add an inspection stage only when a specific condition is met, then remove it when the investigation is done. No redeployment needed.

This is similar to what I mentioned about real-time processing in the original article.

Self-Adjusting Flows

Observe execution time and failure rates for each stage, then remove inefficient stages or insert caching stages upstream.

The program can adjust its own configuration while running.

Expressing State Through Configuration Instead of Flags

In games or simulations, character states are often managed with flags. With Mutable Pipeline Pattern, you could:

Poisoned state → Add damage processing stage
Silenced state → Remove magic processing stage

This way, state is expressed through the pipeline configuration itself. Sometimes this gives better visibility than combinations of flags and if statements.

Things to Keep in Mind

This pattern is powerful, but there are some considerations.

Keep data immutable: Even if the pipeline is mutable, keeping the data passed between stages immutable helps predictability. If both are mutable, things can get chaotic.

Make configuration visible: Having something like a snapshot() function to check the current configuration makes debugging much easier.

Closing

I've reorganized the ideas from my previous Dynamic Pipeline article under the name Mutable Pipeline Pattern.

When conditional logic and flag management start getting messy, "making the configuration itself mutable" might be one option to consider.

Of course, this doesn't work for every situation, and there might be better approaches out there. Just something to keep in mind.

Beyond Surrogate Pairs: Hidden Pitfalls in JS Character Counting with PHP/MySQL

usapop — Thu, 22 Jan 2026 10:54:06 +0000

When counting characters in JavaScript, the surrogate pair issue (where emoji and certain CJK characters count as 2) is fairly well-known. You've probably seen advice like "just use [...str].length" to solve it.

However, when I implemented a character counter for a textarea on the frontend, I discovered there are other causes of mismatches beyond surrogate pairs. It turned out to be deeper than I expected, so I'd like to share what I learned. I might have some things wrong, so please take this as a reference rather than absolute truth.

What Happened

I was implementing a character counter for a <textarea>. I was already using [...str].length as a surrogate pair countermeasure, but Laravel's max validation was still rejecting some inputs.

After investigating, I found the culprit: newline normalization.

Causes Beyond Surrogate Pairs

Cause	JS Side	PHP/MySQL Side	Discrepancy
Emoji (surrogate pairs)	`"🎉".length` → 2	`mb_strlen("🎉")` → 1	JS counts more
Newline normalization	`"a\nb".length` → 3	After HTTP: `"a\r\nb"` → 4	PHP counts more
Lone surrogates	Counted	MySQL error or warning	Possible save failure
NFD form (older macOS)	`"é".length` → 2	`mb_strlen("é")` → 2	Matches, but unintentionally 2 chars

Surrogate pairs can be handled with [...str].length, but the newline issue isn't solved by that alone. The more newlines in the text, the bigger the discrepancy—for example, 10 newlines means a +10 character difference.

About Newline Normalization

This is where I got stuck the most.

Browser → Server

When you submit the contents of a <textarea> via HTTP, newlines are normalized from \n to \r\n.

According to MDN, for wrap="soft" (the default):

the browser ensures that all line breaks in the entered value are a CR+LF pair

The WHATWG Blog also explains this in detail—newlines are normalized to CRLF during form submission per the spec.

// In browser
textarea.value  // "a\nb\nc" → 5 characters

// Received by PHP
$_POST['field'] // "a\r\nb\r\nc" → 7 characters

Laravel's max rule uses mb_strlen(), so it checks against the character count after normalization. This was why text with many newlines kept getting rejected.

The Round-Trip Problem During Editing

This issue doesn't just occur with new input—it also happens on edit screens.

Initial input: Browser (\n) → HTTP submission converts to \r\n → Saved to DB (\r\n)
Edit screen display: DB (\r\n) → Displayed in textarea → textarea.value is normalized to \n
JS count: Counts with \n → "5 characters"
Re-submission: Normalized to \r\n again → PHP/MySQL → "7 characters"

The textarea's .value property is called the "API value," and it's normalized to \n (LF) when retrieved. So even if \r\n is stored in the database, when you get it via JavaScript, it becomes \n.

This round-trip causes a constant mismatch between JS and server-side counting, which is why you need to normalize to \r\n on the JS side before counting.

Database Storage

Major databases like MySQL, PostgreSQL, and SQL Server store \r\n (CRLF) as-is as 2 bytes of data.

Text created in Windows environments is stored as \r\n
Input from Linux/Mac environments (or modern web browsers) uses \n (LF)

In other words, databases don't automatically convert newline codes, so the data varies depending on the input source.

Database-Specific Notes

MySQL / MariaDB

Data is basically stored as-is. However, when importing CSV files via LOAD DATA INFILE from the command line, if the default newline code setting doesn't match, \r can remain as garbage at the end of data.

SQL Server

Due to its Windows affinity, \r\n is treated as standard. When copying and pasting results in SSMS (management tool), newline codes might get changed automatically, so be careful.

Other Causes

Lone Surrogates

Corrupted data can sometimes get mixed in through copy-paste. MySQL treats these as invalid UTF-8 and may throw an error or truncate with a warning.

The behavior varies depending on sql_mode settings—STRICT mode causes an error and stops, while non-STRICT mode issues a warning and performs truncation or replacement.

NFD Form

This is a decomposed form that was used in filenames on older macOS (HFS+). Characters like "é" or "ñ" can have different internal representations while looking the same.

// NFC (composed) vs NFD (decomposed)
"é".length                    // → 1 (NFC: single code point U+00E9)
"é".normalize("NFD").length   // → 2 (NFD: "e" + combining acute accent)

"ñ".length                    // → 1 (NFC: single code point U+00F1)
"ñ".normalize("NFD").length   // → 2 (NFD: "n" + combining tilde)

This also affects other languages with combining marks—Vietnamese, Korean Hangul, Japanese kana, and many others.

According to Apple's official documentation, APFS (since macOS High Sierra in 2017) stores the normalization form as-is, unlike HFS+. However, normalization may still occur at the macOS layer, so NFD issues haven't completely disappeared.

In practice, NFD coming through textarea input or normal web input is quite rare—it mostly becomes an issue when dealing with filenames or copy-paste.

MySQL doesn't normalize by default, so it stores data in whatever form it receives. Depending on the collation, MySQL can search and compare NFD and NFC as "the same thing," but the stored byte count and CHAR_LENGTH results differ, so you still need to be careful from a character counting perspective.

Comparing JS Character Counting Methods

Using [...str].length for surrogate pair handling is common advice, but let me organize the differences between various methods.

Basic Comparison

Method	Unit	`"🎉"`	`"👨‍👩‍👧"`	`"\r\n"`
`str.length`	UTF-16 code units	2	8	2
`[...str].length`	Code points	1	5	2
`Intl.Segmenter`	Grapheme clusters	1	1	1
`TextEncoder`	Byte count	4	18	2
MySQL `CHAR_LENGTH()`	Code points	1	5	2

MySQL's CHAR_LENGTH() counts \r\n as 2 characters, so using Intl.Segmenter (which counts it as 1) will cause a mismatch.

`Intl.Segmenter` vs Spread Syntax

Here's a more detailed comparison:

Character Type	`Intl.Segmenter`	Spread `[...]`
Windows newline (`\r\n`)	1 character	Split into 2
CJK variant selectors	1 character	Split into 2
Private Use Area (U+E000, etc.)	1 character	1 character
ZWJ emoji sequences (👩‍👩‍👧)	1 character	Split apart

The `Intl.Segmenter` Trap

Intl.Segmenter returns "the number of characters as humans visually perceive them."

const segmenter = new Intl.Segmenter("en", { granularity: "grapheme" });
[...segmenter.segment("👨‍👩‍👧")].length  // → 1 (as it looks)
[...segmenter.segment("\r\n")].length   // → 1 (CRLF as 1 character)

This seems good at first, but it can't be used for MySQL VARCHAR limits. 👨‍👩‍👧 is 1 character in Intl.Segmenter, but MySQL's CHAR_LENGTH() counts it as 5, so even if you're within limits according to Segmenter, you might overflow in the database.

Interestingly, X (formerly Twitter) uses its own method. According to Emojipedia, in 2018 they changed to count all emoji uniformly as 2 characters. This differs from both Intl.Segmenter and [...str].length.

Private Use Area (PUA)

For the area commonly used for "custom characters" in Windows (Private Use Area: E000-F8FF), both Intl.Segmenter and spread syntax can handle them as 1 character without issues.

However, they only recognize it as "one code point"—Intl.Segmenter doesn't know what the character actually looks like.

Lone Surrogate Handling

The handling of lone surrogates also differs by method:

Method	Lone Surrogates	Combining Characters
`[...str]`	Kept	Split
`str.match(/./gu)`	Excluded	Split
`Intl.Segmenter`	Kept	Kept as 1 character

`TextEncoder`

Returns the UTF-8 byte count. Useful for checking MySQL's LENGTH() or index byte limits (like 3072 bytes).

new TextEncoder().encode("abc").length   // → 3 (1 byte × 3 characters)
new TextEncoder().encode("café").length  // → 5 (c, a, f each 1 byte + é is 2 bytes in UTF-8)
new TextEncoder().encode("你好").length   // → 6 (CJK characters are 3 bytes each in UTF-8)

By Use Case

Use Case	Method
MySQL VARCHAR(N) limit	`[...str].length` (excluding lone surrogates, etc.)
MySQL index byte limit	`TextEncoder().encode(str).length`
Visual character count	`Intl.Segmenter`

Common Mistakes

Being Satisfied with Just Surrogate Pair Handling

// Surrogate pairs are handled, but newlines cause mismatch
const count = [...str].length;

Using `str.length` Directly

// Emoji counted as 2 characters
"🎉".length  // → 2

Looping by Index

// Surrogate pairs get split
for (let i = 0; i < str.length; i++) {
  const char = str[i];  // 🎉 gets broken
}

// for...of works by code point
for (const char of str) {
  console.log(char);  // 🎉 stays intact
}

Using `Intl.Segmenter` for VARCHAR Limits

As mentioned above, it doesn't match MySQL's counting.

Using `strlen()` in PHP

// Returns byte count
strlen("café")  // → 5 (é is 2 bytes in UTF-8)
strlen("你好")   // → 6 (CJK characters are 3 bytes each)

// Use this instead
mb_strlen("café", 'UTF-8')  // → 4
mb_strlen("你好", 'UTF-8')   // → 2

Example Solution

Here's a function I use to sync with MySQL's VARCHAR(N) limit. There might be better approaches, though.

export function countForMySQL(str: string, charLimit: number) {
  // 1. Exclude lone surrogates from count (MySQL treats them as invalid UTF-8)
  const validChars = str.match(/[\uD800-\uDBFF][\uDC00-\uDFFF]|[^\uD800-\uDFFF]/gu) ?? [];

  // 2. Normalize newlines to CRLF for counting (to match post-HTTP-submission state)
  const normalized = validChars.join('').replace(/\r?\n/g, "\r\n");

  // 3. Count code points (= MySQL CHAR_LENGTH())
  const charLength = [...normalized].length;

  // 4. Byte count (for index limits)
  const byteLength = new TextEncoder().encode(normalized).length;

  return {
    isValid: charLength <= charLimit,
    charLength,
    byteLength,
  };
}

The key point is that this returns only "how MySQL would count it" without modifying the original data. Lone surrogates are excluded from the count because MySQL treats them as invalid UTF-8, but the input data itself is not modified.

Whether to reject input containing lone surrogates via validation can be decided by the calling code.

Reference Table

Concept	MySQL	PHP	JavaScript
Character count (code points)	`CHAR_LENGTH(col)`	`mb_strlen($str, 'UTF-8')`	`[...str].length`
Byte count	`LENGTH(col)`	`strlen($str)`	`new TextEncoder().encode(str).length`
Visual character count	-	`grapheme_strlen($str)`	`Intl.Segmenter`

Conclusion

Using [...str].length for surrogate pair handling is well-known, but there are cases where it's not enough.

Intl.Segmenter is correct for visual character count, but it's a bit tricky that it can't be used for database limit checks.

NFD normalization might be needed in some cases, but it seems rare enough that it's probably okay to ignore for now.

References

When Pendulum Physics Becomes Art: Implementing a Pollock-Style Generative Art Generator

usapop — Mon, 19 Jan 2026 14:23:04 +0000

Clicking the Paint button generates a different pattern each time.
The embed above may be cropped, so I'd recommend opening it in a larger window on CodePen: https://codepen.io/kokoyoshi/pen/YPWVwPB

Example output from the generator

Introduction

Are you familiar with Jackson Pollock?

He's the painter known for laying canvases on the floor and dripping paint from above. This technique, called "drip painting," made him one of the most representative American artists of the 20th century (here are some examples of his work).

At first glance, it might look like he was just randomly splattering paint. But actually, Pollock sometimes painted by swinging a paint-filled container on a string like a pendulum. Since it's a pendulum, it follows the laws of physics—slowing down at the edges where paint accumulates, speeding up in the center where it stretches thin.

What's even more interesting is that according to a 1999 study published in Nature by physicist Richard Taylor, the patterns created by this technique turned out to be fractals—the self-similar structures found throughout nature. And there's also research suggesting that viewing these fractals can reduce human stress by 60%.

Pendulum physics → Fractals → A sense of calm.

I found this chain fascinating and decided to try recreating it in code. This implementation is just one possible approach, so please consider it as a reference.

Breaking Down the Physics

Let me organize the visual characteristics that emerge from pendulum motion.

Physical Phenomenon	Visual Characteristic
Slowing at pendulum edges	Lines become thick and dense (paint accumulates)
Accelerating at center	Lines become thin and faint (paint stretches)
Centrifugal force	Paint splatters fly off
Multiple swings	Trajectories overlap
Repeating with multiple colors	Layered appearance

I'll recreate these in code.

Implementation: Pendulum Trajectories

Basic Movement

First, let's recreate the pendulum's velocity changes.

const speed = baseSpeed * (0.3 + Math.abs(Math.sin(phase)) * 0.7);

Using sin(phase) creates the acceleration and deceleration. Slow at the edges (sin=0), fast at the center (sin=1). This is essentially the pendulum's equation of motion.

From Velocity to Thickness and Opacity

Once velocity is calculated, I convert it to visual attributes.

// Slower = thicker
const curve = Math.pow(1 - normalizedVelocity, 1.5);
thickness = lerp(minThickness, maxThickness, curve);

// Slower = more opaque
opacity = lerp(0.05, 1.0, 1 - normalizedVelocity);

I'm using a non-linear curve (power of 1.5) because linear mapping didn't seem to produce enough contrast. This was adjusted by eye.

Boundary Reflection

Pendulums change direction at their endpoints. When the position exceeds the canvas boundary, I have it return toward the center.

if (isOutsideBounds(x, y)) {
  // Calculate angle toward center
  const toCenter = Math.atan2(centerY - y, centerX - x);
  // Add some randomness for the new direction
  moveAngle = toCenter + randomRange(-0.25, 0.25) * Math.PI;
}

The key point is that instead of bouncing within the canvas, it goes outside and then comes back. This creates strokes that sweep from edge to edge.

Drips

The strokes alone felt a bit lacking to me, so I added paint splatters. They represent paint flying off due to the pendulum's momentum. They're generated probabilistically and drawn as shrinking circles along the velocity vector.

// Probabilistically generate drips
if (Math.random() < 0.002 && isInsideCanvas(x, y)) {
  drips.push(createDrip(x, y));
}

// Draw drips: continuously draw shrinking circles
while (radius > 0.5) {
  drawCircle(x, y, radius);
  x += vx * 0.1;
  y += vy * 0.1;
  radius *= 0.85;
}

Layering Colors

Pollock painted with multiple overlapping colors. He seems to have commonly used black, red, blue, yellow, and white.

const layers = [
  { color: '#1a1a1a' },  // Black
  { color: '#c0392b' },  // Red
  { color: '#6e3b1a' },  // Burnt umber
  { color: '#2980b9' },  // Blue
  { color: '#f1c40f' },  // Yellow
  { color: '#ffffff' },  // White
];

I'm using mix-blend-mode: darken here. This blend mode lets darker colors dominate, which creates color layering similar to actual paint.

On Fine-Tuning

Most of the implementation is about recreating the physics, but I feel like parameter tuning can only be done by eye.

For example, the thickness of white lines. Initially I had them the same as other colors, but they felt too prominent.

1/3 → Still too thick
1/6 → Too thin
1/5 → Just right

This "just right" can't be derived logically—it's a cycle of looking, feeling, and adjusting.

The same goes for the wobble amount. Too much and it looks like "a person with tremors," too little and it feels "mechanical." The subtle range of 0.25–0.65px was the result of many comparisons.

In the end, code can recreate physical phenomena, but I think deciding "this is good enough" comes down to human eyes and intuition.

Conclusion

Pendulum physics → Fractals → Visual resonance → A sense of calm

Perhaps what Pollock was doing was capturing this chain as paintings.

What I've come to think through this recreation is that the boundary between "art" and "physics" is surprisingly blurry. If the result of letting a pendulum do its thing is beautiful, maybe that means the laws of nature themselves are beautiful.

You might enjoy trying different color schemes or tweaking the parameters.

References

Taylor, R., Micolich, A. & Jonas, D. "Fractal analysis of Pollock's drip paintings" Nature 399, 422 (1999)
Taylor, R. P. et al. "Perceptual and Physiological Responses to Jackson Pollock's Fractals" Frontiers in Human Neuroscience 5, 1-13 (2011)

Managing Multiple Related npm Packages with a Monorepo

usapop — Sun, 18 Jan 2026 10:38:23 +0000

When you want to publish multiple related packages to npm — like "core logic + React/Vue wrappers" — managing them becomes a question.

I initially thought "separate repositories would be cleaner" and managed them individually. But as packages grew, things got painful. Every time I fixed core, I had to open PRs in three repositories. npm link wouldn't work as expected and I'd waste hours debugging. Before I knew it, versions were all over the place...

For recent projects, I've been creating them as monorepos, and these headaches have mostly gone away. You don't need special tools — npm workspaces alone gets you pretty far.

This article summarizes that experience. There might be better approaches out there, so consider this just a reference.

Problems with Separate Repositories

Managing related packages in separate repositories led to these issues:

Situation	Problem
Development	Every core fix required dependency update PRs in react/vue repos
Development	`npm link` wouldn't work properly (symlink resolution, duplicate node_modules)
Development	ESLint/Prettier/TypeScript configs copied to each repo, had to sync changes
Publishing	Had to follow: publish core → update react/vue dependency versions → publish
Publishing	When rushing, forgot updates and versions diverged (core at 1.2.0, react at 1.0.3)
Publishing	Without scopes, package names were scattered and relationships unclear
GitHub	With personal accounts, just 3 repos side by side with no visible connection
GitHub	Creating an Organization for a small library feels overkill
GitHub	Issues and discussions scattered across repos

What Changed with Monorepo

Issue	Separate Repos	Monorepo
Core fixes	3 PRs in 3 repos	1 PR in 1 repo
Local dev	Manual `npm link` management	Workspaces auto-link
CI config	Setup per repo	One for all packages
Version management	Individual, prone to drift	Centralized
Config files	Copy-paste per repo	Shared at root

Basically, "packages that change together should live together." Conversely, packages that develop and release independently don't need to be forced into a monorepo.

When to Use (or Not)

Here's my take:

Monorepo works well for:

Core library + framework bindings (React/Vue/Svelte)
Shared utilities + various adapters
Design system component sets
Packages that frequently change together

Separate repos are fine for:

Completely independent packages (changes don't correlate)
Very different release cycles
Different teams managing them

From here, I'll explain the concrete steps to publish npm packages from a monorepo.

Structure assumed in this article:

@your-scope/core - Framework-agnostic core logic
@your-scope/react - React wrapper (depends on core)
@your-scope/vue - Vue wrapper (depends on core)

Dependency diagram:

┌─────────────────────────────────┐
│     User's Project              │
│  ┌───────────────────────────┐  │
│  │      Application          │  │
│  └───────────────────────────┘  │
│        │             │          │
│        ▼             ▼          │
│   ┌────────┐    ┌────────┐      │
│   │ react  │    │  vue   │      │
│   └────────┘    └────────┘      │
└─────────────────────────────────┘
        │             │
        ▼             ▼
┌──────────────┐ ┌──────────────┐
│@your-scope/  │ │@your-scope/  │
│    react     │ │     vue      │
└──────────────┘ └──────────────┘
        │             │
        └──────┬──────┘
               ▼
        ┌──────────────┐
        │@your-scope/  │
        │     core     │
        └──────────────┘

Since react/vue packages depend on core, core must be published first. When bumping versions, if core goes up, react/vue dependency versions need to follow.

I'll use npm as the package manager. The basic concepts apply to pnpm and yarn too, though some details differ.

Project Structure

my-library/
├── package.json          # Root (workspaces definition)
├── tsconfig.json         # Shared TypeScript config
├── packages/
│   ├── core/
│   │   ├── package.json  # @your-scope/core
│   │   ├── tsconfig.json # Extends root
│   │   ├── vite.config.ts
│   │   └── src/
│   │       └── index.ts
│   ├── react/
│   │   ├── package.json  # @your-scope/react
│   │   ├── tsconfig.json
│   │   ├── vite.config.ts
│   │   └── src/
│   │       └── index.ts
│   └── vue/
│       ├── package.json  # @your-scope/vue
│       ├── tsconfig.json
│       ├── vite.config.ts
│       └── src/
│           └── index.ts
└── examples/             # For testing (not published)
    ├── vanilla/
    ├── react/
    └── vue/

The examples/ directory is for testing during development. Including it in workspaces lets it reference local packages, which is convenient. Setting "private": true prevents accidental publishing.

Implementation Steps

1. Root package.json

{
  "name": "my-library",
  "private": true,
  "version": "1.0.0",
  "type": "module",
  "workspaces": [
    "packages/*",
    "examples/*"
  ],
  "scripts": {
    "dev": "npm run dev --workspaces --if-present",
    "build": "npm run build --workspaces --if-present",
    "test": "vitest",
    "lint": "eslint packages",
    "format": "prettier --write ."
  },
  "devDependencies": {
    "eslint": "^9.0.0",
    "prettier": "^3.5.0",
    "typescript": "^5.8.0",
    "vitest": "^3.0.0"
  }
}

A few points:

"private": true - The root itself won't be published to npm. Forgetting this could cause accidents with npm publish
workspaces - Specifies directories to manage. Wildcards like packages/* work
--workspaces --if-present - Runs scripts across all workspaces. --if-present skips packages without that script

Putting devDependencies at root avoids duplicate installations across packages. Things used everywhere like eslint, prettier, typescript are easier to manage at root.

On the other hand, things used only in specific packages (e.g., @vitejs/plugin-react only for the react package) are clearer in that package's devDependencies.

# Add to root (shared across all)
npm install -D -W eslint prettier typescript

# Add to specific package
npm install -D -w packages/react @vitejs/plugin-react

-W (--workspace-root) adds to root package.json, -w (--workspace) adds to the specified workspace.

2. Shared TypeScript Config

// tsconfig.json (root)
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "isolatedModules": true
  }
}

Each package extends this root config, overriding as needed.

// packages/core/tsconfig.json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src"]
}

// packages/react/tsconfig.json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "outDir": "./dist",
    "rootDir": "./src",
    "jsx": "react-jsx"
  },
  "include": ["src"]
}

3. Package-level package.json

Core package:

{
  "name": "@your-scope/core",
  "version": "1.0.0",
  "type": "module",
  "main": "./dist/index.cjs",
  "module": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.ts",
        "default": "./dist/index.js"
      },
      "require": {
        "types": "./dist/index.d.cts",
        "default": "./dist/index.cjs"
      }
    }
  },
  "files": ["dist"],
  "scripts": {
    "build": "vite build",
    "dev": "vite build --watch"
  },
  "devDependencies": {
    "vite": "^6.0.0",
    "vite-plugin-dts": "^4.5.0"
  }
}

Some notes:

exports - Available since Node.js 12.7.0, explicitly defines entry points. Takes precedence over main/module. Convention is to put types first in conditional exports since Node.js evaluates conditions top-down, ensuring TypeScript resolves types correctly
files - Specifies what to include in the npm package. Just dist means src and test files won't be included. You can also use .npmignore, but whitelist via files is less accident-prone
vite-plugin-dts - Plugin to generate TypeScript declaration files (.d.ts) with Vite

Framework binding (React):

{
  "name": "@your-scope/react",
  "version": "1.0.0",
  "type": "module",
  "main": "./dist/index.cjs",
  "module": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.ts",
        "default": "./dist/index.js"
      },
      "require": {
        "types": "./dist/index.d.cts",
        "default": "./dist/index.cjs"
      }
    }
  },
  "files": ["dist"],
  "scripts": {
    "build": "vite build",
    "dev": "vite build --watch"
  },
  "dependencies": {
    "@your-scope/core": "^1.0.0"
  },
  "peerDependencies": {
    "react": ">=17.0.0"
  },
  "devDependencies": {
    "@vitejs/plugin-react": "^4.4.0",
    "react": "^19.0.0",
    "vite": "^6.0.0",
    "vite-plugin-dts": "^4.5.0"
  }
}

A note on peerDependencies:

Frameworks like React should already be installed in the user's project, so we specify them as peerDependencies. This way, the library doesn't bundle React and uses the user's React instance instead.

If React gets bundled multiple times, hooks break and other issues occur, so this matters.

Meanwhile, we need React during development, so it's also in devDependencies.

4. Build Config (Vite)

// packages/core/vite.config.ts
import { defineConfig } from 'vite'
import dts from 'vite-plugin-dts'

export default defineConfig({
  build: {
    lib: {
      entry: 'src/index.ts',
      formats: ['es', 'cjs'],
      fileName: (format) => `index.${format === 'es' ? 'js' : 'cjs'}`,
    },
    sourcemap: true,
    // Not minifying in library mode makes debugging easier for users
    minify: false,
  },
  plugins: [
    dts({
      rollupTypes: true, // Bundle type definitions into one file
    }),
  ],
})

// packages/react/vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import dts from 'vite-plugin-dts'

export default defineConfig({
  build: {
    lib: {
      entry: 'src/index.ts',
      formats: ['es', 'cjs'],
      fileName: (format) => `index.${format === 'es' ? 'js' : 'cjs'}`,
    },
    sourcemap: true,
    minify: false,
    rollupOptions: {
      // Packages to exclude from bundle
      external: ['react', 'react/jsx-runtime', '@your-scope/core'],
    },
  },
  plugins: [
    react(),
    dts({
      rollupTypes: true,
    }),
  ],
})

About rollupOptions.external:

When building a library, you need to decide whether to include dependencies in the bundle. Packages in external won't be bundled — they'll use what's installed in the user's environment.

react, react/jsx-runtime - peerDependencies, don't include
@your-scope/core - It's a dependency, but users install it separately, so don't include

Conversely, packages not in external get bundled. Small utility libraries that you don't want users to install separately could be bundled.

5. Publishing to npm

First-time publishing requires explicitly marking the scope as public.

# Build
npm run build

# Publish (in dependency order)
cd packages/core && npm publish --access public
cd ../react && npm publish --access public
cd ../vue && npm publish --access public

--access public isn't needed after the first time.

Automating with Changesets

Manually running npm publish repeatedly gets painful as packages grow. You might mess up the order or forget to update dependency versions.

Changesets automates this. Manual works fine for small projects, but as packages grow or release frequency increases, it might be worth considering.

What Changesets Does

Dependency-aware version updates - When core goes up, it auto-updates the dependency version in react/vue
Auto-generated CHANGELOG.md - Records changes and writes them to files on publish
"Scheduling" changes - During development, just record "made this change," then process everything together at release time

Setup

Initialize at root:

npm install -D @changesets/cli
npx changeset init

This creates a .changeset/ directory and config file.

Workflow

1. Record changes

After adding features or fixing bugs, before committing:

npx changeset

Interactive prompts ask "which packages changed," "major/minor/patch," and "description." This creates a small markdown file in .changeset/ which you commit as-is.

2. Apply versions

When ready to release:

npx changeset version

Records in .changeset/ are consumed, auto-updating each package's package.json version and CHANGELOG.md. It considers dependencies, so if core's version goes up, react/vue dependency versions follow.

3. Publish

Finally, publish everything at once:

npx changeset publish

Packages with unpublished versions get uploaded to npm in dependency order.

GitHub Actions Integration

Combined with GitHub Actions, you can automate further. When a changeset is merged to main, it auto-creates a version update PR. When that PR is merged, it auto-publishes to npm.

There's an official GitHub Action, check it out if interested.

I'm still doing it manually though...

Gotchas

1. Don't Use workspace:* Protocol

pnpm and yarn berry (v2+) let you reference local packages with workspace:*:

{
  "dependencies": {
    "@your-scope/core": "workspace:*"
  }
}

This is convenient during development, but there's a problem. pnpm auto-replaces this with version numbers on npm publish, but npm and yarn v1 publish workspace:* as-is, causing install errors.

I wrote about this in detail in another article (Japanese):

usapop

Jan 18

The Pitfall of npm publish with pnpm's workspace:* Protocol

#npm #javascript #monorepo

Comments

2 min read

With npm workspaces, just write the version number normally. If a matching local package exists, it automatically symlinks.

{
  "dependencies": {
    "@your-scope/core": "^1.0.0"
  }
}

2. Mind the Publish Order

Packages with dependencies must publish the dependency first.

1. @your-scope/core   ← Publish first
2. @your-scope/react  ← Depends on core
3. @your-scope/vue    ← Depends on core

If you try to publish react before core, it'll error saying @your-scope/core@^1.0.0 not found.

If this is tedious, tools like Changesets auto-publish in dependency order. Though for small projects, manual is probably fine.

3. Don't Forget Dependency Version Updates

When bumping versions, dependent packages' reference versions need updating too.

// packages/core/package.json
{ "version": "1.1.0" }

// packages/react/package.json
{
  "version": "1.1.0",
  "dependencies": {
    "@your-scope/core": "^1.1.0"  // ← Update this too
  }
}

Forgetting this leaves react depending on old core. Manual updates are error-prone, so automating with shell scripts or npm scripts might help.

4. Unified vs Individual Versioning

Monorepo version management has two main approaches:

Unified versions (fixed versioning)

Used by Vue, React, Jest, and many famous projects. Even if only core changes, react/vue get the same version bump.

@your-scope/core: 1.2.0
@your-scope/react: 1.2.0
@your-scope/vue: 1.2.0

Simpler to manage. Users don't have to wonder "which version combination is correct." For personal projects, this probably has fewer accidents.

Individual versioning

Only bump packages that changed. If only core changed, only core goes up.

@your-scope/core: 1.2.0
@your-scope/react: 1.1.0  // No changes, stays
@your-scope/vue: 1.1.0

Per-package change history is clearer, but maintaining dependency consistency is a bit more work. Changesets handles this well.

I use unified versioning. For small libraries, simplicity of unified management seems to outweigh benefits of individual management.

Conclusion

Monorepos aren't a silver bullet, but they're a convenient option when you want to manage related packages together.

npm workspaces work without special tools, so maybe start small and add pnpm or Changesets as needed.

References

The Pitfall of npm publish with pnpm's workspace:* Protocol

usapop — Sun, 18 Jan 2026 10:36:58 +0000

TL;DR

pnpm's workspace:* is a local-only protocol
Publishing with npm publish as-is makes the package unusable for others
pnpm publish auto-replaces it, but requires proper setup
For simplicity, npm workspaces + normal version specifiers works fine

What Happened

I had a monorepo set up with pnpm, using workspace:* for inter-package dependencies.

// packages/react/package.json
{
  "name": "@my-lib/react",
  "dependencies": {
    "@my-lib/core": "workspace:*"
  }
}

Everything worked fine in local development, so I ran npm publish...

npm warn Invalid dependency "@my-lib/core": "workspace:*"

When someone tried to install the published package:

npm error Could not resolve dependency:
npm error peer workspace:* from @my-lib/react@0.1.0

Why This Happens

workspace:* is a local-only protocol used by pnpm/npm/yarn workspace features.

Locally: "reference the package within this workspace"
After publishing: unresolvable (npm registry doesn't understand workspace:)

Solutions

Option 1: Use pnpm publish (requires setup)

pnpm can replace workspace:* with actual versions on publish.

workspace:* → *
workspace:^ → ^x.y.z
workspace:~ → ~x.y.z

However, this isn't enabled by default. You need proper configuration:

# pnpm-workspace.yaml
packages:
  - 'packages/*'

And you must use pnpm publish (not npm publish).

Option 2: Manually write versions

Replace workspace:* with actual versions before publishing.

{
  "dependencies": {
    "@my-lib/core": "^1.2.3"
  }
}

Tedious but reliable.

Option 3: Switch to npm workspaces (simplest)

Drop pnpm and use npm workspaces with normal version specifiers from the start.

// package.json (root)
{
  "workspaces": [
    "packages/*"
  ]
}

// packages/react/package.json
{
  "dependencies": {
    "@my-lib/core": "^1.2.3"
  }
}

With npm workspaces, if a matching local package exists, it automatically symlinks. No special workspace:* notation needed.

pnpm and npm Publish to the Same Place

An easy point to misunderstand: both pnpm publish and npm publish go to the same npm registry.

Package managers are just client tools — the publish destination is shared. So:

Packages published with pnpm can be installed with npm
Packages published with npm can be installed with pnpm
Same goes for yarn

Conclusion

Approach	Pros	Cons
pnpm + `workspace:*` + `pnpm publish`	Local dev is easy	Complex setup, accidents with `npm publish`
pnpm + manual version specifiers	Reliable	Version updates are tedious
npm workspaces + normal versions	Simple, fewer accidents	Lacks pnpm's speed

For small monorepos, npm workspaces is probably enough. If you need pnpm's fast installs for a large project, you'll need to properly set up the pnpm publish workflow.

Hope this helps someone.

References

Building Generative Art Step by Step — A Node Garden Example

usapop — Sat, 17 Jan 2026 23:14:05 +0000

This node garden implementation is just one example. There are many different expressions and implementations out there, so please consider this as a reference.

First, See the Final Result

This is what we're building.

Introduction

When creating generative art, you usually have an image in your head of "I want it to move like this." But when you actually try to implement it, it looks complex and you don't know where to start.

In such cases, the approach of "breaking it down into elements and building up from the bottom" might work well.

In this article, I'll introduce this approach using a node garden — a classic generative art implementation — as an example.

Verbalize Your Image

First, put the vague image in your head into words.

For this node garden, I imagined it like this:

Points floating around
Lines connect when they get close
They influence each other and change movement
Something organic feeling

Even vague things like "something organic" should be written down for now. Adding a simple sketch at this stage can be even more helpful.

Break Down Into Elements

Next, break down each description into concrete processes.

Image	Process
Points floating	Drawing points, movement with velocity
Connect when close	Distance calculation, threshold check, line drawing
Influence each other / Organic feeling	Force from charge, line stretch animation

The way you break things down will vary by person. I often separate "visible elements" from "movement rules."

Organize as Layer Structure

Organize the elements into a layer structure while considering dependencies.

For a simple node garden, Layer 3 might be enough.

Layer 4: Charge + Stretch Animation
    ↑
Layer 3: Line Connection & Opacity
    ↑
Layer 2: Point Movement & Screen Wrap
    ↑
Layer 1: Point Drawing

This is a dependency structure where upper layers can't exist without lower layers.

For example, to implement "force from charge," you first need "distance calculation," and to calculate distance, you need "point positions"... and so on.

Build From the Bottom

Now let's actually write the code. The key point is to verify at each layer.

Layer 1: Point Drawing

First, just draw points.
If white points are randomly displayed on the screen, it's OK.

const CONFIG = {
  width: 340,
  height: 340,
  numNodes: 60,
  nodeRadius: 3,
};

class Node {
  constructor(x, y) {
    this.x = x;
    this.y = y;
    this.radius = CONFIG.nodeRadius;
  }

  draw(ctx) {
    ctx.fillStyle = '#fff';
    ctx.beginPath();
    ctx.arc(this.x, this.y, this.radius, 0, Math.PI * 2);
    ctx.fill();
  }
}

// Initialize
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');
const nodes = Array.from({ length: CONFIG.numNodes }, () =>
  new Node(
    Math.random() * CONFIG.width,
    Math.random() * CONFIG.height
  )
);

// Draw
ctx.clearRect(0, 0, CONFIG.width, CONFIG.height);
nodes.forEach(node => node.draw(ctx));

Layer 2: Point Movement & Screen Wrap

Give points velocity and make them move.
If points are floating around, it's a success.

class Node {
  constructor(x, y) {
    this.x = x;
    this.y = y;
    this.vx = Math.random() * 3 - 1.5;
    this.vy = Math.random() * 3 - 1.5;
    this.radius = CONFIG.nodeRadius;
  }

  update() {
    this.x += this.vx;
    this.y += this.vy;

    // Wrap to opposite side when reaching screen edge
    if (this.x > CONFIG.width) this.x = 0;
    else if (this.x < 0) this.x = CONFIG.width;
    if (this.y > CONFIG.height) this.y = 0;
    else if (this.y < 0) this.y = CONFIG.height;
  }

  draw(ctx) {
    ctx.fillStyle = '#fff';
    ctx.beginPath();
    ctx.arc(this.x, this.y, this.radius, 0, Math.PI * 2);
    ctx.fill();
  }
}

// Animation loop
function loop() {
  ctx.clearRect(0, 0, CONFIG.width, CONFIG.height);
  nodes.forEach(node => {
    node.update();
    node.draw(ctx);
  });
  requestAnimationFrame(loop);
}
loop();

Layer 3: Line Connection & Opacity

Calculate distance between points and draw lines if within threshold.
If nearby points are connected with lines and opacity changes with distance, it's a success.

Here's one trick: when nodes wrap at the screen edge, lines suddenly disappear which looks unnatural. To prevent this, we set the wrap boundary larger than the drawing area (margin: 100). Nodes go off-screen and lines naturally fade out before wrapping to the opposite side.

Additionally, since we've added margin, the number of points may look sparse relative to the visible area, so we increase the node count slightly to compensate.

Up to Layer 2, it's just points so it's not noticeable, but from Layer 3 onward where lines connect, this technique becomes important.

const CONFIG = {
  // ...
  margin: 100,
  numNodes: 80,
  minDist: 100,
  lineWidth: 1.5,
};

class Node {
  // ...
  update() {
    this.x += this.vx;
    this.y += this.vy;

    // Wrap outside screen edge (so lines fade naturally)
    const m = CONFIG.margin;
    if (this.x > CONFIG.width + m) this.x = -m;
    else if (this.x < -m) this.x = CONFIG.width + m;
    if (this.y > CONFIG.height + m) this.y = -m;
    else if (this.y < -m) this.y = CONFIG.height + m;
  }

  distanceTo(other) {
    const dx = this.x - other.x;
    const dy = this.y - other.y;
    return { dx, dy, dist: Math.sqrt(dx * dx + dy * dy) };
  }
}

function loop() {
  ctx.clearRect(0, 0, CONFIG.width, CONFIG.height);
  ctx.lineWidth = CONFIG.lineWidth;

  for (let i = 0; i < nodes.length; i++) {
    const node1 = nodes[i];
    node1.update();
    node1.draw(ctx);

    for (let j = i + 1; j < nodes.length; j++) {
      const node2 = nodes[j];
      const { dist } = node1.distanceTo(node2);

      if (dist < CONFIG.minDist) {
        // Closer distance = more opaque
        const opacity = 1 - dist / CONFIG.minDist;
        ctx.beginPath();
        ctx.strokeStyle = `rgba(255, 255, 255, ${opacity})`;
        ctx.moveTo(node1.x, node1.y);
        ctx.lineTo(node2.x, node2.y);
        ctx.stroke();
      }
    }
  }

  requestAnimationFrame(loop);
}

Layer 4: Charge + Stretch Animation

Give each node a random "charge" so pairs attract or repel each other. Also, instead of lines appearing suddenly, add an animation where they extend from both ends toward the center.

By multiplying charges, we express attraction and repulsion.

interaction = charge1 × charge2

Same sign (+ × + or − × −) → Positive → Repel
Opposite sign (+ × − or − × +) → Negative → Attract

Charge (Node) 1	Charge (Node) 2	Result	Movement
+	+	+	Repel
−	−	+	Repel
+	−	−	Attract
−	+	−	Attract

Nodes that were moving similarly now have personality, and movement becomes more diverse.

const CONFIG = {
  // ...
  margin: 100,
  numNodes: 80,
  springAmount: 0.0005,
  maxSpeed: 1.5,
  lineGrowSpeed: 0.05,
};

class Node {
  constructor(x, y) {
    // ...
    // Random charge from -1 to 1
    this.charge = Math.random() * 2 - 1;
  }

  update() {
    // Speed limit
    const speed = Math.sqrt(this.vx * this.vx + this.vy * this.vy);
    if (speed > CONFIG.maxSpeed) {
      this.vx = (this.vx / speed) * CONFIG.maxSpeed;
      this.vy = (this.vy / speed) * CONFIG.maxSpeed;
    }

    this.x += this.vx;
    this.y += this.vy;

    // Wrap outside screen edge (so lines fade naturally)
    const m = CONFIG.margin;
    if (this.x > CONFIG.width + m) this.x = -m;
    else if (this.x < -m) this.x = CONFIG.width + m;
    if (this.y > CONFIG.height + m) this.y = -m;
    else if (this.y < -m) this.y = CONFIG.height + m;
  }

  applyForce(ax, ay) {
    this.vx += ax;
    this.vy += ay;
  }
}

// Manage connection state
const connections = new Map();

function getConnectionKey(i, j) {
  return i < j ? `${i}-${j}` : `${j}-${i}`;
}

function drawConnection(node1, node2, opacity, progress) {
  const midX = (node1.x + node2.x) / 2;
  const midY = (node1.y + node2.y) / 2;

  // Extend toward midpoint based on progress
  const x1 = node1.x + (midX - node1.x) * progress;
  const y1 = node1.y + (midY - node1.y) * progress;
  const x2 = node2.x + (midX - node2.x) * progress;
  const y2 = node2.y + (midY - node2.y) * progress;

  ctx.beginPath();
  ctx.strokeStyle = `rgba(255, 255, 255, ${opacity})`;
  ctx.moveTo(node1.x, node1.y);
  ctx.lineTo(x1, y1);
  ctx.moveTo(node2.x, node2.y);
  ctx.lineTo(x2, y2);
  ctx.stroke();
}

// Inside loop
if (dist < CONFIG.minDist) {
  const key = getConnectionKey(i, j);
  const currentProgress = connections.get(key) || 0;
  const newProgress = Math.min(1, currentProgress + CONFIG.lineGrowSpeed);
  connections.set(key, newProgress);

  const opacity = 1 - dist / CONFIG.minDist;
  drawConnection(node1, node2, opacity, newProgress);

  // Multiply charges (same sign → repel, opposite sign → attract)
  const interaction = node1.charge * node2.charge;
  const ax = dx * CONFIG.springAmount * interaction;
  const ay = dy * CONFIG.springAmount * interaction;
  node1.applyForce(ax, ay);
  node2.applyForce(-ax, -ay);
}

Conclusion

What's important in implementing art expressions is this process of taking the image in your head and:

Verbalizing it
Breaking it into elements
Organizing as layers
Building from the bottom

At each layer, you can verify "it's working, it's correct," so it's easy to see where problems occur. You can also decide mid-way "I don't need this element" and remove it.

I Made a Stroke Stabilization Library for Web Drawing Apps

usapop — Sat, 17 Jan 2026 17:01:57 +0000

🔗GitHub: https://github.com/usapopopooon/stroke-stabilizer
📦npm: https://www.npmjs.com/package/@stroke-stabilizer/core
🖋Live Demo: https://usapopopooon.github.io/stroke-stabilizer/

Introduction

If you've ever built a freehand drawing app or whiteboard app, you've probably encountered the problem of jagged, shaky lines. (By "freehand" here, I mean pen tablet, mouse, or touch input.)

So I made a library called stroke-stabilizer to smooth out hand tremor.

Here's a demo. The red line is raw input, and the green line is the stabilized output.
You can adjust the stabilization level with the slider.

What Is This Library?

stroke-stabilizer smooths coordinate data from pointer events (mouse, touch, pen) to produce smoother strokes.

My motivation was wanting the "stabilization" feature found in paint software like ClipStudio Paint, but for web apps.

Most existing libraries lock you into a single smoothing algorithm. With stroke-stabilizer, you can combine multiple filters yourself. Want just noise reduction? Or both Kalman filter and string filter? You can customize it for your use case.

There might be better approaches, and some parts of the implementation may still be rough, but I've written up the details here in case it's helpful to someone.

Features

Combine filters freely: Mix noise reduction, Kalman filter, moving average, string filter, etc. in any order to build your own stabilization pipeline
Lightweight: Core library has zero dependencies, small bundle size
Framework support: React/Vue wrappers available
Real-time processing: Stabilizes while drawing
Post-processing filters: Apply Gaussian or bilateral smoothing after stroke completion
Endpoint correction: Automatically adjusts so strokes end at the actual pointer position
rAF batching: Batch high-frequency pointer events into animation frames
TypeScript support: Type definitions included

When to Use (and When Not to)

Good fit:

Freehand drawing/painting apps
Whiteboard and annotation tools
Signature capture
Any app where smooth pen input matters

Not a good fit:

Precision drafting apps (CAD, etc.)
Apps with existing stabilization
Simple click-and-drag operations

Installation

Choose based on your environment:

# Core library only
npm install @stroke-stabilizer/core

# If using React (install additionally)
npm install @stroke-stabilizer/react

# If using Vue (install additionally)
npm install @stroke-stabilizer/vue

Basic Usage

Vanilla JavaScript

import {
  createStabilizedPointer,
  gaussianKernel,
} from '@stroke-stabilizer/core'

// Create a stabilizer (level is 0-100)
const pointer = createStabilizedPointer(50)

// Add post-processing (optional)
pointer.addPostProcess(gaussianKernel({ size: 5 }))

// Process coordinates from pointer events
canvas.addEventListener('pointermove', (e) => {
  // IMPORTANT: Use getCoalescedEvents() for smoother input
  const events = e.getCoalescedEvents?.() ?? [e]

  for (const ce of events) {
    const point = {
      x: ce.offsetX,
      y: ce.offsetY,
      pressure: ce.pressure,
      timestamp: ce.timeStamp,
    }

    const stabilized = pointer.process(point)
    if (stabilized) {
      // Draw using stabilized.x, stabilized.y
    }
  }
})

// Apply post-processing and get final points on stroke end
canvas.addEventListener('pointerup', () => {
  const finalPoints = pointer.finish()
  // Redraw with smoothed points
})

React

import {
  useStabilizedPointer,
  useStabilizationLevel,
} from '@stroke-stabilizer/react'

function DrawingCanvas() {
  const { level, setLevel } = useStabilizationLevel({ initialLevel: 50 })
  const { process, reset, pointer } = useStabilizedPointer({
    level,
    onPoint: (point) => {
      // Draw with stabilized coordinates
    },
  })

  const handlePointerMove = (e) => {
    // IMPORTANT: Use getCoalescedEvents() for smoother input
    const events = e.nativeEvent.getCoalescedEvents?.() ?? [e.nativeEvent]

    for (const ce of events) {
      process({
        x: ce.offsetX,
        y: ce.offsetY,
        pressure: ce.pressure,
        timestamp: ce.timeStamp,
      })
    }
  }

  const handlePointerUp = () => {
    // Apply post-processing and get final stroke
    const finalPoints = pointer.finish()
    reset()
  }

  // ...
}

Vue

<script setup>
import {
  useStabilizedPointer,
  useStabilizationLevel,
} from '@stroke-stabilizer/vue'

const { level, setLevel } = useStabilizationLevel({ initialLevel: 50 })
const { process, reset, pointer } = useStabilizedPointer({
  level: level.value,
  onPoint: (point) => {
    // Draw with stabilized coordinates
  },
})

const handlePointerMove = (e) => {
  // IMPORTANT: Use getCoalescedEvents() for smoother input
  const events = e.getCoalescedEvents?.() ?? [e]

  for (const ce of events) {
    process({
      x: ce.offsetX,
      y: ce.offsetY,
      pressure: ce.pressure,
      timestamp: ce.timeStamp,
    })
  }
}

const handlePointerUp = () => {
  // Apply post-processing and get final stroke
  const finalPoints = pointer.finish()
  reset()
}
</script>

Important: Using getCoalescedEvents()

This is essential for smooth strokes. Browsers throttle pointermove events to around 60fps, but pen tablets and high-refresh-rate mice can generate 200+ events per second. Without getCoalescedEvents(), you lose all those intermediate points, resulting in jagged strokes no matter how good your stabilization is.

canvas.addEventListener('pointermove', (e) => {
  // Get all coalesced events (falls back to single event if unsupported)
  const events = e.getCoalescedEvents?.() ?? [e]

  for (const ce of events) {
    pointer.process({
      x: ce.offsetX,
      y: ce.offsetY,
      pressure: ce.pressure,
      timestamp: ce.timeStamp,
    })
  }
})

The ?. optional chaining handles browsers that don't support getCoalescedEvents() (though most modern browsers do).

Framework notes:

React: Access via e.nativeEvent.getCoalescedEvents?.()
Vue: Access directly on the event (it's already the native PointerEvent)

Algorithm Details

This section covers technical details. Feel free to skip if you just want to use the library.

Architecture: Dynamic Pipeline Pattern

This library uses a Dynamic Pipeline Pattern.

Traditional Builder or Chain of Responsibility patterns make it hard to modify a pipeline at runtime. But drawing apps often need to update filter parameters in real-time when the user moves a slider, or toggle specific filters on/off.

That's why I came up with this pattern. I wrote about it in detail in a separate article:

usapop

Jan 14

The "Dynamic Pipeline" Pattern: A Mutable Method Chaining for Real-time Processing

#architecture #programming #designpatterns #javascript

Comments

4 min read

Key characteristics

Dynamic add/remove — Add or remove filters at runtime
Parameter updates — Change specific filter settings without rebuilding the entire pipeline
Always ready — No .build() call needed. Ready to use immediately
Order matters — Filters execute in the order they were added

Input → [Filter 1] → [Filter 2] → ... → [Filter N] → Output

Multiple filters are available, and combinations are flexible. For example, you could implement a system where the filter combination changes based on level (0-100):

Level	Applied Filters
0	None (raw data passes through)
1-20	Noise filter
21-40	Noise + Kalman filter
41-60	Noise + Kalman + Moving average
61-80	Above + String filter (weak)
81-100	Above + String filter (strong)

Let me explain each filter.

1. Noise Filter

The simplest filter. If the distance from the last output is below a threshold, it discards the input.

How it works

Calculate distance between current input and last output
If distance is less than minDistance, reject the point
Otherwise, pass it through

In other words: "if it barely moved, ignore it." Simple, but effective at removing fine jitter from sensor noise.

2. Kalman Filter

The Kalman filter is a recursive algorithm that estimates optimal state by combining "prediction" and "observation." It's apparently used for things like rocket trajectory calculations.

This library implements a simple position-only model (no velocity) for stability with high-frequency input devices (144Hz+).

How it works

The filter maintains two values: estimated position and its uncertainty.

Prediction step:

Assume position is the same as last time
Increase uncertainty slightly (state might have changed)

Update step:

Compare prediction with actual observation
Calculate "Kalman gain" (how much to trust the observation)
Blend prediction and observation based on gain
Update uncertainty

Key parameters:

Process noise (Q): How much position is expected to change between samples
Measurement noise (R): How much to trust raw input

Roughly speaking:

Higher R → Trust observation less → Smoother output
Lower Q → Trust prediction more → Slower response to direction changes

3. Moving Average Filter

A simple filter that takes the average of the last N points.

How it works

Keep a buffer of the last N points
Output the average of all points in the buffer

This works as a low-pass filter. Larger N means smoother output but more lag.

4. String Filter (Lazy Brush)

Imagine a virtual "string" between the pen tip and the drawing point. That's basically how it works. ClipStudio Paint's stabilization probably uses a similar approach.

How it works

Calculate distance from anchor point (last output) to current input
If within string length: anchor doesn't move, no output
If beyond string length: anchor gets "pulled" toward input

The anchor moves only by the amount exceeding the string length. Like pulling something on a leash.

This filter behaves naturally. Slow movements get stabilized (delayed by string length), fast movements are followed appropriately.

5. One Euro Filter

An adaptive filter that adjusts smoothing strength based on speed. Applies strong smoothing to slow movements, weak smoothing to fast movements.

Reference paper

Géry Casiez, Nicolas Roussel, and Daniel Vogel. 2012. 1€ Filter: A Simple Speed-based Low-pass Filter for Noisy Input in Interactive Systems.
https://cristal.univ-lille.fr/~casiez/1euro/

How it works

Estimate current speed (how fast the pointer is moving)
Calculate cutoff frequency based on speed
- Slow movement → Low cutoff → Strong smoothing
- Fast movement → High cutoff → Weak smoothing
Apply exponential moving average with the calculated smoothing factor

Key parameters:

minCutoff: Smoothing strength at low speed (lower = smoother)
beta: How fast smoothing decreases as speed increases

6. Post-processing Kernels

Convolution filters applied after stroke completion. Since they process bidirectionally (looking at both past and future points), there's no phase delay like with real-time filters.

The library includes these kernel types:

Gaussian kernel: Standard Gaussian-weighted smoothing (center-weighted with smooth falloff)
Box kernel: Uniform weights (simple average)
Triangle kernel: Center-weighted with linear falloff
Bilateral kernel: Edge-preserving smoothing that respects sharp corners

How convolution works

For each point in the stroke:

Take a window of neighboring points (e.g., 5 points centered on current)
Multiply each point by its weight (determined by kernel type)
Sum the weighted values to get the smoothed output

Boundary handling has three padding modes: reflect, edge (replicate endpoints), and zero (zero padding).

Endpoint preservation

By default, smooth() preserves exact start and end points after convolution. This ensures the stroke reaches the actual pointer position when you lift the pen.

import { smooth, gaussianKernel } from '@stroke-stabilizer/core'

// Default: preserve endpoints (recommended)
const smoothed = smooth(points, {
  kernel: gaussianKernel({ size: 5 }),
})

// Disable endpoint preservation
const smoothedAll = smooth(points, {
  kernel: gaussianKernel({ size: 5 }),
  preserveEndpoints: false,
})

Option	preserveEndpoints	Behavior
Default	`true`	Start and end points match original exactly
Disabled	`false`	All points affected by convolution (may drift)

Parameter Tuning Tips

Each filter's parameters can be adjusted for your use case. Here's a rough guide:

Filter	Parameter	Lower value	Higher value
Noise	minDistance	Picks up fine points	Ignores subtle movements
Kalman	processNoise (Q)	Trusts prediction, slower response	Trusts observation, faster response
Kalman	measurementNoise (R)	Closer to raw data	Smoother
Moving Average	windowSize	Faster response, more jitter	Smoother, more lag
String	stringLength	More responsive	More stable
One Euro	minCutoff	Stronger smoothing	Weaker smoothing
One Euro	beta	Less speed-sensitive	More speed-sensitive

Building Custom Pipelines

The preset (createStabilizedPointer) is convenient, but if you don't need certain filters or want fine-grained parameter control, you can combine filters yourself.

Each filter has strengths and weaknesses, so try different combinations for your use case. For example, if you have lots of fast strokes, keep the string filter weak. For slow, careful drawing, make the Kalman filter stronger.

import {
  StabilizedPointer,
  noiseFilter,
  kalmanFilter,
  oneEuroFilter,
  gaussianKernel,
} from '@stroke-stabilizer/core'

const pointer = new StabilizedPointer()
  // Real-time filters
  .addFilter(noiseFilter({ minDistance: 2 }))
  .addFilter(oneEuroFilter({ minCutoff: 1.0, beta: 0.007 }))
  // Post-processing
  .addPostProcess(gaussianKernel({ size: 7 }))

// During drawing
const stabilized = pointer.process(point)

// On stroke end (applies post-processing)
const finalPoints = pointer.finish()

rAF Batching

High-frequency pointer events (144Hz+) can flood the event queue. The library provides optional requestAnimationFrame batching.

const pointer = new StabilizedPointer()
  .addFilter(noiseFilter({ minDistance: 2 }))
  .enableBatching({
    onBatch: (points) => {
      // Called once per frame with all processed points
      drawPoints(points)
    },
    onPoint: (point) => {
      // Called for each individual point (optional)
    },
  })

canvas.addEventListener('pointermove', (e) => {
  // Queue instead of process - will be batched
  pointer.queue({
    x: e.offsetX,
    y: e.offsetY,
    pressure: e.pressure,
    timestamp: e.timeStamp,
  })
})

canvas.addEventListener('pointerup', () => {
  // Flush pending points before finishing
  const finalPoints = pointer.finish()
})

Closing

That's my stroke stabilization library, stroke-stabilizer.

I hope this helps someone building drawing or whiteboard apps. There might be better approaches out there, but hopefully this gives you some ideas...

Bug reports and feature requests are welcome on GitHub Issues.

🔗GitHub: https://github.com/usapopopooon/stroke-stabilizer
📦npm: https://www.npmjs.com/package/@stroke-stabilizer/core
🖋Live Demo: https://usapopopooon.github.io/stroke-stabilizer/