ates.dev

Vite MCP Client Tools Plugin

Ateş Göral — Mon, 13 Oct 2025 24:00:00 GMT

tl;dr

A Vite plugin that brings client-side MCP tools to allow your coding agent to see your app in action. Uses your existing Vite development server, so you don't have to run a separate MCP server.

Short story

I've been enamoured with getting coding agents to self-improve by telling them to write MCP servers for themselves.

This is the outcome of one such experiment where I was getting frustrated by the agent's enthusiastic "Perfect!" exclamations while it had no idea what the UI it was modifying looked like. I told the agent to add an MCP server to the existing Vite server that's serving the UI, and to add two tools: A screenshot tool so it can see the browser window whenever it wants, and a console log tool so it can see errors and diagnostic messages.

Once the proof of concept worked, I put aside the agent to properly (manually) architect the plugin and made it extensible for new tools.

Installation and configuration

Adding the Vite plugin and its tools to a project looks like this:

npm install vite-plugin-mcp-client-tools

import { defineConfig } from 'vite';
import { viteMcpPlugin } from "vite-plugin-mcp-client-tools";
import { readConsoleTool } from "vite-plugin-mcp-client-tools/tools/read-console";
import { takeScreenshotTool } from "vite-plugin-mcp-client-tools/tools/take-screenshot";

export default defineConfig({
  plugins: [
    viteMcpPlugin({
      tools: [readConsoleTool, takeScreenshotTool],
    }),
  ],
});

Usage

Then the agent needs to be configured with the MCP server exposed by the plugin, running on the very same Vite development server. Depending on the coding agent that you use, you may have to edit an MCP configuration file. For Claude Code, you can run something like this:

claude mcp add vite-server-client-tools --transport http http://localhost:3000/mcp

Once the agent knows about these tools, it will automatically start using them, unprompted. Magic will ensue. It will start taking screenshots to see the result of its changes (and the reason for your complaints) and it will start peeking at the console to see what's happening in JavaScript land in the browser. Unless it doesn't. Then you might have to nudge it to start using the tools.

Hint: If you let your agent start the Vite development server as a background process, it can also see how the server is doing, by tailing its output.

Tool contract

Beyond the standard MCP tool definition components, name, description, inputSchema, and outputSchema, each tool consists of:

A handler function that implements the tool's logic.
An optional component factory function for a WebComponent that gets mounted on the document's body. This is useful for tools that require user interaction or configurability.
An optional server hash of helper methods that get mounted on the Vite server (namespaced by the tool's name).

The handler receives the component and server as properties on this:

The component property is the DOM node for the WebComponent.
The server property is a Proxy that lets the tool remote-call the defined server-side methods.

The built-in screenshot tool demonstrates all of these features. The tool's handler function is:

handler: async function (this: ToolContext) {
  const { dataUrl, quality, saveToDisk } = await this.component.captureScreenshot();

  const base64Data = dataUrl.split(",")[1];

  let savedPath: string | undefined;

  if (saveToDisk) {
    const { path } = await this.server.saveScreenshot({ dataUrl });
    savedPath = path;
  }

  const textContent = savedPath
    ? `Screenshot of current browser tab captured (quality: ${quality}, saved to: ${savedPath})`
    : `Screenshot of current browser tab captured (quality: ${quality})`;

  return {
    content: [
      {
        type: "text",
        text: textContent,
      },
      {
        type: "image",
        mimeType: "image/jpeg",
        data: base64Data,
      },
    ],
  };
},
...

Under the hood

The plugin uses Vite's existing HMR (Hot Module Replacement) WebSocket connection for bi-directional RPC (Remote Procedure Call) with a bridge that gets injected into the page as a virtual module (so that import.meta.hot can be present). Tools' WebComponents are defined using additional script tags and get mounted on the document's body.

In the scripts injected into the page by the plugin, there's generous use of IIFE (Immediately Invoked Function Expression) for serialization and deserialization of server-defined functions while performing dependency injection. I'm not going to cover all the tips and tricks here. You can see them in action in the source code of the plugin.

Joystick Hack

Ateş Göral — Mon, 20 Jan 2025 24:00:00 GMT

What follows is the first electronics mod I did as a child, with no artifacts to show for it. Circa late 1980s.

We didn't have digital cameras back then and I didn't have the foresight to take process photos using a regular camera, and didn't even think of preserving the modded monstrosity as a keepsake. You'll just have to take my word for it.

The priming

Growing up, we had an Atari 2600 Video Game Console, with CX40 joysticks to go with it. An issue with the joysticks, possibly due to our forceful usage, was that the metal dome switches on the circuit board would crack and flatten, causing the joystick to malfunction in one or more directions.

My architect/photographer/audiophile dad wasn't shy of cracking open electronics to do simple repairs. A single demonstration on how to open a joystick to unbend and reposition the metal contacts launched me on my DIY electronics repair journey. I performed all future joystick repairs.

The circuit board and its wiring was very simple to intuitively understand for an uninitiated kid: Just 6 wires for ground, the 4 directions and the fire button. (See: Atari 2600 Field Service Manual, 7-1 & 7-2.)

Credit: Atari2600PAL, forum post on AtariAge, used with permission.

The opportunity

Fast forward to many years later. I'm visiting my cousin and we're gaming on his Commodore 64. My cousin has autofire joysticks (a feature that allows a joystick to automatically send repeated fire signals without the need for the user to press the fire button repeatedly), which I never bothered buying.

One of his autofire joysticks is physically broken and he's thinking of tossing it out in the garbage. I said I wanted to examine it and took it from him. Given my understanding of a standard non-autofire joystick, I was very curious about what made these autofire joysticks tick.

I know nothing about electronics beyond "if you touch two metals, electricity flows through them" at this point.

The inspection

I take the joystick home, unscrew the housing and start examining the circuit board. Extrapolating my understanding of a basic joystick's circuit over the incomprehensible circuit elements of the autofire circuit, I visually isolate a section that is most likely responsible for the autofire action. I use my dad's circuit tester to verify.

I don't remember the make and model, but it probably looked something like the bottom right of this QuickShot II circuit board:

Credit: Giacomo Vernoni, blog post on oldcomputr.com, permission pending.

The hack

And here comes the hack.

I hacksaw the autofire section out of the circuit board, and franken-solder it to the circuit board of my non-autofire QuickShot I joystick with wires and tuck it sideways inside the joystick housing. I super-glue a single wire along the original 6-lead wire of the joystick to upgrade it to 7 leads. The stripped end of this extra wire is inserted into the +5V hole of the female DE-9 connector. I replace the top fire button of my joystick with a pole push button, which happens to fit perfectly in the shaft.

Credit: Peter Vis, page on petervis.com, used with permission.

And it worked!

I had a Frankenstein's monster of a joystick with an autofire circuit retrofitted on it like a parasite. I was clicking the toggle switch on the top to turn on autofire, and clicking it again to turn it off.

Courage, luck, success. Whatever confidence I had for all the other electronics mods I did in later life, I trace them back to this very first hack — literal hack, with a hacksaw involved.

Accurate Benchmarking

Ateş Göral — Sun, 12 Jan 2025 24:00:00 GMT

I'll share a mathematical approach to discounting the loop overhead when looping over a piece of code in order to measure how long it takes (as compared to some alternative piece of code).

This might be a well-known approach, and there might be better methods, but it is nevertheless a method I independently came up with and have used in the past.

The premise

We have a piece of code, method1(), that we want to benchmark to see how fast it is as compared to method2().

Since computers are very fast, running something just once isn't a viable way to measure how long it takes to run. We therefore run it many times in a loop and measure the total amount of time it takes.

A standard, qualitative approach

A straightforward way to set up a benchmark() utility could look something like this:

function benchmarkTotal(fn, iterations) {
  const start = performance.now();

  for (let i = 0; i < iterations; i++) {
    fn();
  }

  const end = performance.now();
  const total = end - start;

  return total;
}

// Usage:
const elapsed1 = benchmarkTotal(method1, 1_000_000);
const elapsed2 = benchmarkTotal(method2, 1_000_000);

This approach is sufficient for qualitatively comparing method1 and method2 to see which one is faster.

method1 is faster than method2 if elapsed1 < elapsed2
method1 is slower than method2 if elapsed1 > elapsed2

Factor in the loop overhead for quantitative comparisons

To get a quantitative "X is p% faster than Y", we should factor in the loop overhead. If method1 and method2 are both "slow" methods that take many computational cycles to run, the tiny overhead of the for loop will be insignificant. The faster the methods we're comparing, the more significant the loop overhead becomes.

Let’s denote the total time for method1 to run $n$ times as $t_{1}$ , and the total loop overhead for $n$ iterations as $e$ . And method2 takes $t_{2}$ .

Then:

\begin{matrix} {elapsed}_{1} & = & t_{1} + e \\ {elapsed}_{2} & = & t_{2} + e \end{matrix}

The only mathematically accurate quantitative result we can derive from the above is:

\begin{matrix} delta & = & {elapsed}_{1} - {elapsed}_{2} \\ = & (t_{1} + e) - (t_{2} + e) \\ = & t_{1} + e - t_{2} - e \\ = & t_{1} - t_{2} \end{matrix}

We can say that the difference between method1 and method2 running $n$ times is $delta$ milliseconds.

We can also calculate a percentage, p = delta / elapsed1 * 100, and say:

method2 is p% faster than method1 if p is negative
method2 is p% slower than method1 if p is positive

We can also say the difference between the run time of a single call is delta / n, but what if we want to measure a single call to either function? We haven't isolated $t_{1}$ or $t_{2}$ yet. We just know their difference.

Timing a single call

Here’s the key insight of this post.

If we want to loop $n$ times, we can still loop a total of $n$ times by looping a bit, and then a bit more. We can partition the loop by first calling the method once $\frac{n}{3}$ times, followed by calling it twice $\frac{n}{3}$ times, ensuring the total number of calls equals $n$ :

function benchmarkSingle(fn, iterations) {
  const oneThird = iterations / 3;

  const start1 = performance.now();

  for (let i = 0; i < oneThird; i++) {
    fn();
  }

  const end1 = performance.now();
  const elapsed1 = end1 - start1;

  const start2 = performance.now();

  for (let i = 0; i < oneThird; i++) {
    fn();
    fn();
  }

  const end2 = performance.now();
  const elapsed2 = end2 - start2;

  const partition = elapsed2 - elapsed1;
  const single = partition / oneThird;

  return single;
}

// Usage:
const elapsed = benchmarkSingle(method, 1_000_000);

Let's break it down:

If the time it takes for $\frac{n}{3}$ calls to method is $t_{p}$ and the loop overhead of $\frac{n}{3}$ iterations is $e_{p}$ , then the two loops have the following durations:

\begin{matrix} {elapsed}_{1} & = & t_{p} + e_{p} \\ {elapsed}_{2} & = & 2 t_{p} + e_{p} \end{matrix}

Then their difference is:

\begin{matrix} delta & = & {elapsed}_{2} - {elapsed}_{1} \\ = & (2 t_{p} + e_{p}) - (t_{p} + e_{p}) \\ = & 2 t_{p} + e_{p} - t_{p} - e_{p} \\ = & t_{p} \end{matrix}

We have gotten rid of the loop overhead and isolated $t_{p}$ ! Then we can accurately compute the time it takes for a single call to the method by dividing $t_{p}$ by $\frac{n}{3}$ :

single = \frac{3 t_{p}}{n}

Sanity check

Let's use both benchmarkTotal and benchmarkSingle 100 times over 10 million iterations of Math.atan2() with random numbers and compare the results:

// The subject
const fn = () => Math.atan2(Math.random(), Math.random());
const iterations = 10_000_000;

function average(measurer, samples = 100) {
  let total = 0;

  for (let i = 0; i < samples; i++) {
    total += measurer();
  }

  return total / samples;
}

const totalWithOverhead = average(() => benchmarkTotal(fn, iterations));
const single = average(() => benchmarkSingle(fn, iterations));
const total = single * iterations;

After waiting for the computations to finish:

technique	variable	value
simple	`totalWithOverhead`	`130.08399999946357`
improved	`total`	`127.3620000086725`

Conclusion:

It takes Math.atan2() ~127ms to run 10 million times over random numbers. With the simple approach of running a single loop for the measurement, there is a ~3ms loop overhead, or 2% of the measurement from the simple technique.

Does a 2% loop overhead matter in most cases? Probably not. ¯\_(ツ)_/¯

Using Bitmaps in Dweets

Ateş Göral — Mon, 30 Dec 2024 24:00:00 GMT

This is a breakdown of one of my older dweets, introducing a dweet rendering technique and a few general JavaScript golfing techniques.

It's a follow-up to:

The subject

Suppose we want to render a specific bitmap image in a Dweet. As an example, I'll nostalgically pick the mouse pointer icon of the TOS operating system on the Atari ST:

It's a 16x16 icon, but the bounding box of the black pixels is 8x14, so we can ignore pixel information that falls outside.

The raw binary data to encode this information looks like this:

If you squint, you should be able to make out the mouse pointer.

In its raw form these ones and zeroes would take up 8 * 14 = 112 characters, not leaving much room in a 140-character dweet to incorporate code to actually render the pixels.

Encoding, with a problem

Let's start with packing each of the rows into a byte. I'll prefix each row with 0b to turn it into a binary number literal:

const bytes = [
  0b10000000,
  0b11000000,
  0b11100000,
  0b11110000,
  0b11111000,
  0b11111100,
  0b11111110,
  0b11111111,
  0b11111000,
  0b11011000,
  0b10001100,
  0b00001100,
  0b00000110,
  0b00000110,
];

This is equivalent to:

const bytes = [128, 192, 224, 240, 248, 252, 254, 255, 248, 216, 140, 12, 6, 6];

We can now use String.fromCharCode() to turn each number into characters and then concatenate them:

const bytes = [128, 192, 224, 240, 248, 252, 254, 255, 248, 216, 140, 12, 6, 6];
const encoded = bytes.map((c) => String.fromCharCode(c)).join('');

This is what we get:

const encoded = '\x80ÀàðøüþÿøØ\x8C\f\x06\x06';

Note the extra overhead of the escaped characters in \x## form. Instead of single characters, they're all encoded as 4 characters. There's also the \f form feed character.

Depending on the size and content of the bitmap, you may get none, but you could also get a lot of these escape sequences. They take up precious space.

And when the bitmap size is wider than 8 pixels, you may venture into the much more verbose Unicode code point sequences, \u####.

More efficient encoding

We can get around this by adding an offset to the character codes to put them within 0x0000 through 0xFFFF. Characters within the Basic Multilingual Plane (BMP) don't require escaping, except:

Values	Designation
`0` through `31`	C0 controls
`127`	DEL (delete)
`128` through `159`	C1 controls

Keep in mind that fromCharCode() only works with BMP. We can't go beyond 16 bits (or bitmap columns). There's fromCodePoint() to access characters past BMP, but I won't get into that.

So, if we add 160 to the bit-packed value, we'll make sure we stay within the range that doesn't require escaping:

const bytes = [128, 192, 224, 240, 248, 252, 254, 255, 248, 216, 140, 12, 6, 6];
const encoded = bytes.map((c) => String.fromCharCode(c + 160)).join('');

This is what we get:

const encoded = 'ĠŠƀƐƘƜƞƟƘŸĬ¬¦¦';

Nothing escaped!

Initial render

Let's render our bitmap using 8x8 squares.

We will pluck the character corresponding to the whole encoded row with charCodeAt(Y) and then test the bit corresponding to pixel at X by AND'ing with a bitmask we obtain by left-shifting 1 by X places.

In verbose form, that's (encoded.charCodeAt(Y) - 160) & (1 << X), but we can exploit operator precedence at the expense of human readability to make it much shorter: encoded.charCodeAt(Y)-160&1<<X:

c.width|=0
for(Y=14;Y--;)for(X=8;X--;)'ĠŠƀƐƘƜƞƟƘŸĬ¬¦¦'.charCodeAt(Y)-160&1<<X&&x.fillRect(X*8,Y*8,8,8)

That didn't quite work as expected because the X axis loop is reversed to save space. Instead of reversing that loop or replacing the bit accessor i with 7-i and wasting space, we can simply flip our image data before encoding.

By doing more preparation outside of the dweet, we save space within.

More preparation

Mouse pointer icon, flipped on the X axis and encoded again:

const bytes = [
  0b00000001,
  0b00000011,
  0b00000111,
  0b00001111,
  0b00011111,
  0b00111111,
  0b01111111,
  0b11111111,
  0b00011111,
  0b00011011,
  0b00110001,
  0b00110000,
  0b01100000,
  0b01100000,
];
const encoded = bytes.map((c) => String.fromCharCode(c + 160)).join('');

We get:

encoded = '¡£§¯¿ßğƟ¿»ÑÐĀĀ';

And then we can render the icon facing the right way with no extra code:

c.width|=0
for(Y=14;Y--;)for(X=8;X--;)'¡£§¯¿ßğƟ¿»ÑÐĀĀ'.charCodeAt(Y)-160&1<<X&&x.fillRect(X*8,Y*8,8,8)

Wait a minute...

If we can add some offset, 160, to get us past the C1 block, what prevents us from using a power of 2 as the offset? Since we're doing binary masking to test bits, we're already ignoring any bits that fall outside our most significant bit. Let's go up to next power of 2 that's larger than 160: 256.

const bytes = [
  0b00000001,
  0b00000011,
  0b00000111,
  0b00001111,
  0b00011111,
  0b00111111,
  0b01111111,
  0b11111111,
  0b00011111,
  0b00011011,
  0b00110001,
  0b00110000,
  0b01100000,
  0b01100000,
];
const encoded = bytes.map((c) => String.fromCharCode(c + 256)).join('');

We get:

encoded = 'āăćďğĿſǿğěıİŠŠ';

And we gloriously save 4 characters by omitting the -256 subtraction:

c.width|=0
for(Y=14;Y--;)for(X=8;X--;)'āăćďğĿſǿğěıİŠŠ'.charCodeAt(Y)&1<<X&&x.fillRect(X*8,Y*8,8,8)

Loop collapse

A JavaScript golfing technique that can sometimes save space: Joining two nested loops into one.

We can loop over all 112 pixels and then compute the X and Y values.

For Y, the verbose way would be dividing the iterator i with the number of columns and flooring the value: Math.floor(i/8). We can also exploit binary operators to coerce the result into an integer: i/8|0. However, since in this case we're lucky enough to have exactly 8 columns, we can simply bit-shift the value by 3 bits: i>>3.

For X, a modulo would work: X=i%8. However, since 8 is a power of two, we can use a binary AND with 7 to the same effect: X=i&7. It's symmetrical with our use of bit shifting for Y and it also truncates the result in case i were to be not an integer — something modulo doesn't provide.

When you have creative freedom in picking dimensions in a dweet, sticking to powers of 2 can yield savings.

Here's the collapsed loop version:

c.width|=0
for(i=112;i--;'āăćďğĿſǿğěıİŠŠ'.charCodeAt(Y=i>>3)&1<<X&&x.fillRect(X*8,Y*8,8,8))X=i&7

Note that we're now using the "final expression" slot of the for loop to do the rendering. This slot doesn't have to be only used for incrementing/decrementing a loop variable. We've left the X=i&7 assignment within the loop because we then don't have to create an empty loop body with a ; character and we don't need to use a , operator within the final expression.

Also note a common trick where we can store the value of an expression while we use it for the first time, as in charCodeAt(Y=i>>3).

Just saved 2 characters, but it's worth it!

When you have extra space

Since we still have a whopping 44 characters until the 140 character limit, we can throw in some fun.

Mouse hijack!

c.width|=0
for(i=112;i--;'āăćďğĿſǿğěıİŠŠ'.charCodeAt(Y=i>>3)&1<<X&&x.fillRect(X*8+(S(t*3.1)**5+1)*960,Y*8+(C(t*5.3)**7+1)*540,8,8))X=i&7

Some final tricks that are used in the above:

Add 1 to the sine and cosine values, then divide by 2 to let them go between 0 and 1 instead of -1 and 1. Though, in the above, I'm not dividing by 2 but multiplying by half the extents of the canvas to save space.
Raise values to powers less then 1 to dampen and more than 1 to excite motion. I obtain the jolty motion by the **5 and **7.
Multiply angles with primes or "weird" values to prevent the motion to have a short loop cycle. The curves will take a long time converging back on their starting positions thanks to the *3.1 and *5.3.

Dweeting Outside the Box

Ateş Göral — Wed, 25 Dec 2024 24:00:00 GMT

This is a continuation of my previous post on Dwitter, where I gave an overview of Dwitter and a few JavaScript golfing tricks.

The subject was the "default dweet", which renders 9 bars swaying back and forth. I'll keep the subject the same, but show rendering those 9 bars in different ways.

Changing up how you render a scene often opens up new opportunities for visual effects because it's like stepping into another dimension.

Let's start with recalling the default dweet:

c.width|=0;for(i=9;i--;)x.fillRect(400+i*100+S(t)*300,400,50,200)

Scale

Seeing that the bars click into a 50x50 grid, one might be tempted to scale the context to save on digits. Let's scale the context by 50 and divide all dimensions by 50:

c.width|=0;x.scale(50,50);for(i=9;i--;)x.fillRect(8+i*2+S(t)*6,8,1,4)

In this particular case, the extra length of x.scale(50,50) is not offset by the savings we got from fewer digits. We went from 65 to 69 characters. The function call overhead (x.scale()) costs more characters than what we save by using smaller numbers.

In tiny-space coding, intuitions often don't pan out, you just have to try things for fit.

Transform

Instead of positioning the elements of the scene by x and y offsets from the top left, we can use translate() to shift the frame of reference to the center of the canvas. This can yield two benefits:

If there are multiple primitives in the scene, we don't have to repeat adding offsets to them and therefore save on characters.
We can use rotate() to rotate them around the center of the canvas.

translate(960, 540) moves the origin (0, 0) to the center of the canvas. Assuming we want to rotate by angle A using rotate(A), we can combine these stacked transformations into a single setTransform() call, saving precious space. Let's also throw Z, the zoom factor, into the mix. The verbose form is:

x.setTransform(C(A) * Z, S(A) * Z, -S(A) * Z, C(A) * Z, 960, 540);

Here's the default scene using such combined transformations:

for(c.width|=i=9,Z=1,A=0;i--;x.fillRect(-560+i*100+S(t)*300,-140,50,200))x.setTransform(k=C(A)*Z,z=S(A)*Z,-z,k,960,540)

Note the k and z variable assignments that reduce repetition. It makes intuitive sense to assign repeated expressions to variables, but it only saves space when the expression we're substituting is longer than 2-3 characters, or when it's repeated for more than 2 times.

This transformation setup enables perfect-loop animations like so:

for(c.width|=i=9;i--;x.fillRect(-425+i*100,-103,99-p**.3*50,206))p=t/2%1,Z=2.26+p*7.34,x.setTransform(k=C(A=1.57*p)*Z,z=S(A)*Z,-z,k,960,540)

And so:

eval(unescape(escape`挮睩摴桼㵦㵢㴾房❣汥慲剥捴✺❦楬汒散琧㭳㵓⡴⤻娽㤵〪猪⨴⬵〻甽䌨琩⩚㭸学⡵㸰⥝⠰ⰰⰲ攳ⰲ攳⤻砮瑲慮獦潲洨甬稽猪娬⵺Ⱶⰹ㘰ⰵ㐰⤻景爨椽ㄸ㭩ⴭ㬩硛昨椦ㄩ崨椭㤬ⴲⰱⰴ⤻`.replace(/u(..)/g,"$1%")))

That gibberish? It's an oft-used compression hack to stuff more than 140 characters into a dweet. The raw characters are encoded as UTF-16 code units, and then escaped as UTF-8 code units. While this doesn't technically violate the "140 characters" rule of Dwitter (since the rule was about characters, not bytes), it's not as pleasing as fitting a dweet into 140 characters without compression.

A quick way to see what the uncompressed version is, is to replace the eval() with a throw. The perpetual-beta version of Dwitter comes with a toggle to show uncompressed code.

Here's the uncompressed version of the dweet above:

c.width|=f=b=>b?'clearRect':'fillRect';s=S(t);Z=950*s**4+50;u=C(t)*Z;x[f(u>0)](0,0,2e3,2e3);x.transform(u,z=s*Z,-z,u,960,540);for(i=18;i--;)x[f(i&1)](i-9,-2,1,4)

To compress, you can use the wonderful CapJS tool created by the one and only Frank Force.

Slice and Dice

We can chop up the bars into tiny squares and perturb their individual positions or colors to create interesting effects. Like this specular highlight:

c.width|=0;for(j=n=10;--j;)for(i=100;i--;X=i%5+j*n+S(t)*30,Y=i/5|0,x.fillStyle=R(r=255-(X-50)**2-Y**2,r,r),x.fillRect(400+X*n,400+Y*n,n,n));

And this twirl:

c.width|=0;for(j=9;j--;)for(i=100;i--;X=i%5+j*10+S(t)*30,Y=i/5|0,x.fillRect(400+X*10+S(t+X+Y)*C(t)*9,400+Y*10,10,10));

Note the i/5|0 expression that exploits the fact that JavaScript floors numbers prior to performing binary operations like the binary OR used here. This is much shorter than Math.floor(i/5).

Another technique to note is the elimination of nested loops for X and Y. There is a single loop and the X and Y values are derived through modulo and division. This sometimes saves space, depending on how many times the X and Y values are used.

Also note the abuse of the comma operator to perform multiple operations. This is usually shorter than creating a {} code block with statements separated by semicolons.

XOR

We can also play with different compositing operations. Here, I'm overlaying a bunch of rectangles in XOR mode to let them alternate between black and white to create the default bars. You have to wait a bit to see the reveal:

c.width=1920
x.globalCompositeOperation='xor'
for(i=18;i--;)x.fillRect(400+i*50+S(t)*300,400+i*S(t/9)**9*200,2e3,200)

Thematic End

And here's a thematic end to this post. Not quite the default bars, but they're hidden in there:

c.width|=0
for(i=17;i--;)for(j=5;j--;)[2057,1,32897,0,2057][j]+87380&1<<i&&x.fillRect(1200-i*50+S(t)*300,400+j*40,50,40)

A Merry Christmas and a Happy New Year!

A Short Introduction to Dwitter and JavaScript Golfing

Ateş Göral — Fri, 20 Dec 2024 24:00:00 GMT

This is a brief introduction to JavaScript golfing — not the competitive kind, but the kind on Dwitter: a community for sharing visual JavaScript demos in 140 characters.

The Dwitter community has a friendly and collaborative remix culture (where users "fork" each other's works and build on them). And there's also a culture of sharing tips and tricks.

Sidestepping the numerous online resources for writing unreadably compact JavaScript, I will share the tricks I know and use, and try to present them in a progressive manner.

Check out my originals and remixes over at Dwitter under "magna" to see some of these tricks in action.

Dweet

Demos posted on Dwitter are called "dweets". The premise is, there's a rendering loop that keeps calling the function u(t) where t is time in seconds since the start of the demo, and you have to fit function u's body into 140 characters.

You're using the <canvas> API, with a 2D context. Dwitter gives you the following global variables:

Variable	Value
`c`	the 1920x1080 canvas element
`x`	the 2D context
`S`	the sine function (`Math.sin`)
`C`	the cosine function (`Math.cos`)
`T`	the tangent function (`Math.tan`)
`R`	a function for creating RGBA colors
`frame`	a counter, incremented on each frame

The R function takes four optional parameters: red, green, blue, and alpha. e.g. R(255, 0, 0, 0.5) is a semi-transparent red color. Skipped arguments default to 0 except for alpha, which defaults to 1.

The default scene

When you hit the New button on Dwitter, you're presented with this default scene:

c.width=1920 // clear the canvas
for(i=0;i<9;i++)
x.fillRect(400+i*100+S(t)*300,400,50,200) // draw 50x200 rects

9 black rectangles, swaying back and forth, following a sine wave.

This default scene is the main subject of many dweets, employing different creative/surprising techniques to draw the rectangles. Or a subject that makes a sudden entrance into an existing scene through a remix.

It's a Dwitter meme.

The default dweet is 112 characters in its initial form. Let's start shaving some characters off, bit by bit.

Obvious things

Let's start with the banally obvious: Remove comments and whitespace.

c.width=1920;for(i=0;i<9;i++)x.fillRect(400+i*100+S(t)*300,400,50,200)

We're down to 70.

Idempotency

Assigning the width or height of a canvas resets the canvas, even if the value is the same as the current value.

That's why the default scene sets the canvas width to 1920: To clear the canvas before drawing each frame.

But what we really need is a no-op assignment to clear the canvas. Any idempotent operation will do. So we can binary OR the canvas width with 0:

c.width=1920
c.width|=0

We shave another 2 characters off.

We could have added 0 or multiplied by 1. You get the idea.

Loop inversion

When loop order is unimportant, we can invert loops to shave characters.

for(i=0;i<9;i++)
for(i=9;i--;)

We shave 3 characters off.

c.width|=0;for(i=9;i--;)x.fillRect(400+i*100+S(t)*300,400,50,200)

Down to 65.

This is the maximum we can shave off, without resorting to other API methods, or starting to mess with the scene composition.

Compromising

Well, we often can mess with the scene composition. We can compromise accuracy when the result is visually indistinguishable.

OR'ing with 0 is idempotent. So is OR'ing with 9, when we're willing to compromise and accept 1929 as the new 1920.

OR'ing with 9 results in 1929 (1920 | 9), but the 9-pixel difference is imperceptible.

c.width|=0;for(i=9;i--;)
for(c.width|=i=9;i--;)

We shave another 2 characters off.

for(c.width|=i=9;i--;)x.fillRect(400+i*100+S(t)*300,400,50,200)

Down to 63.

And with that, one Dwitter article down, n to go.

Responsive Canvas Rendering

Ateş Göral — Sun, 08 Dec 2024 24:00:00 GMT

In web development, 'responsive' typically refers to layout. Adjusting the layout of a page based on the dimensions of the renderable area. A more formal definition from Wikipedia:

Responsive web design (RWD) or responsive design is an approach to web design that aims to make web pages render well on a variety of devices and window or screen sizes from minimum to maximum display size to ensure usability and satisfaction.

Here, I will share a few key techniques I always apply when rendering pixels on a <canvas> element, while ensuring the rendering properly responds to canvas size and Device Pixel Ratio (DPR).

This is not a comprehensive tutorial that aims to teach on canvas rendering from scratch. Code excerpts are partial, only highlighting key changes from the previous example. Knowledge of JavaScript and some algebra is assumed.

Defaults

Let's start with a default canvas:

<canvas></canvas>

By default, the canvas is a transparent rectangle measuring 300x150 pixels (spec). I have added a border around it to clearly define its size and position on the page.

Reference square

Now, let's fill it black and then render a 100x100 white square in its middle:

<canvas id="canvas"></canvas>

const canvas = document.querySelector('#canvas');
const ctx = canvas.getContext('2d');

ctx.fillRect(0, 0, canvas.width, canvas.height);

const SIZE = 100;

ctx.fillStyle = 'white';
ctx.fillRect(
  canvas.width / 2 - SIZE / 2,
  canvas.height / 2 - SIZE / 2,
  SIZE,
  SIZE,
);

Intrinsic dimensions

Now let's stretch the canvas to 100% of the width of the container:

canvas {
  width: 100%;
  height: 150px;
}

Why is our square no longer square? Because we resized the canvas with CSS and didn't attach width and height attributes to the <canvas> tag, the intrinsic dimensions of the canvas are still the defaults, 300x150.

We can fix this by setting the width and height properties of the canvas element to its pixel dimensions:

const {width, height} = canvas.getBoundingClientRect();

canvas.width = width;
canvas.height = height;

Reference circle

Next, let's switch to rendering a circle to achieve anti-aliased edges. And let's also print "1.0", and render a reference 20x20 square, both of which will become significant soon.

const RADIUS = 50;

ctx.beginPath();
ctx.arc(canvas.width / 2, canvas.height / 2, RADIUS, 0, Math.PI * 2);
ctx.fill();

ctx.font = '2em monospace';
ctx.fillText('1.0', 10, 35);

// 20x20 pixel reference square
ctx.fillRect(10, 50, 20, 20);

Crisp rendering

The CSS dimensions we set on the canvas are the logical pixel dimensions. Your browser's DPR (Device Pixel Ratio) is a multiplier that determines the physical pixel density of your screen. For example, if your DPR is 2.0, then for every logical pixel, there are 4 physical pixels (2x2). To render this circle in the crispiest way possible we apply the DPR as a multiplier to the canvas dimensions. We'll also print your actual DPR instead of the "1.0" we hard-coded earlier:

const dpr = window.devicePixelRatio;
const {width, height} = canvas.getBoundingClientRect();

canvas.width = width * dpr;
canvas.height = height * dpr;

But then, we also have to start factoring in DPR in all size units when using the drawing primitives:

// Adjust for DPR
const radius = RADIUS * dpr;

ctx.beginPath();
ctx.arc(canvas.width / 2, canvas.height / 2, radius, 0, Math.PI * 2);
ctx.fill();

// Display DPR
ctx.font = '2em monospace';
ctx.fillText(dpr.toFixed(2), 10, 35);

DPR comparison

If your DPR is greater than 1.0, you should see the 20x20 pixel reference square rendered as something smaller than 20x20 while our circle remains the same size. And the anti-aliased edges of the circle should now look as crisp as possible on your screen (without getting into subpixel rendering).

In case your DPR is 1.0, and you don't see a difference above, here's what the comparison would have approximately looked like against a DPR of 2.0:

Scene layout

In the examples so far we've used hard-coded dimensions for the elements because we knew the canvas height was always 150px. A square 100px across or a circle 50px in radius would nicely fit.

Defining the scene in proportions, such as a fraction of the canvas height, simplifies dynamic layouts. So, let's switch to rendering our circle with a radius of 1/3 of the canvas height:

const radius = canvas.height / 3;

ctx.fillStyle = 'white';
ctx.beginPath();
ctx.arc(canvas.width / 2, canvas.height / 2, radius, 0, Math.PI * 2);
ctx.fill();

Resizing

Typically, a canvas will be set up to be dynamically resized to fit its container. After rendering the circle once, let's start changing the width of the canvas container:

As the container width changes, the circle stretches into an ellipse because the canvas pixels are resampled to fit the new dimensions.

Brute-force rendering

One way to address this is to set up a rendering loop to keep adjusting the intrinsic dimensions of the canvas and rendering the scene every frame. This way, the entire scene will always be rendered at the correct proportions. We'll use a requestAnimationFrame (RAF) loop for this:

function draw() {
  // Request the next frame before we draw this one
  requestAnimationFrame(draw);

  const dpr = window.devicePixelRatio;
  const {width, height} = canvas.getBoundingClientRect();

  canvas.width = width * dpr;
  canvas.height = height * dpr;

  ctx.fillStyle = 'black';
  ctx.fillRect(0, 0, canvas.width, canvas.height);

  const radius = canvas.height / 6;

  ctx.fillStyle = 'white';
  ctx.beginPath();
  ctx.arc(canvas.width / 2, canvas.height / 2, radius, 0, Math.PI * 2);
  ctx.fill();
}

// Kick off the loop
requestAnimationFrame(draw);

The circle remains a circle now.

Preserving the aspect ratio

Instead of rendering a static scene every frame, another option is to preserve the aspect ratio of the canvas so that the scene doesn't stretch or squash. We can render the canvas once and let CSS do its thing:

<div class="container">
  <canvas></canvas>
</div>

/* How this container itself fits into the layout is up to you */
.container {
  aspect-ratio: 300 / 150;
}

canvas {
  /* Alternatively, use Flexbox */
  width: 100%;
  height: 100%;
}

The circle remains a circle.

Avoid resampling

However, the ugly truth is that you will lose all the crispy rendering you got at the start by updating the intrinsic dimensions of the canvas with DPR in mind. Even when initially rendering big and then scaling down, resampling can cause undesirable artifacts. And initially rendering small and then scaling up will create blurry results:

Debounced redraw

We can watch for the resizing of the canvas and redraw the scene on a debounce. This approach allows resampling during resizing but ensures accurate proportions once resizing stops.

Let's do this efficiently. To watch for resizing, we'll use the ResizeObserver browser API:

// One could always use Lodash's debounce
function tailDebounce(fn, delay) {
  let timer;

  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

let contentRect = null;

const draw = () => {
  // Always draw when the time is right
  requestAnimationFrame(() => {
    const dpr = window.devicePixelRatio;
    const rect = contentRect || canvas.getBoundingClientRect();
    const {width, height} = rect;

    canvas.width = width * dpr;
    canvas.height = height * dpr;

    ctx.fillStyle = 'black';
    ctx.fillRect(0, 0, canvas.width, canvas.height);

    const radius = canvas.height / 3;

    ctx.fillStyle = 'white';
    ctx.beginPath();
    ctx.arc(canvas.width / 2, canvas.height / 2, radius, 0, Math.PI * 2);
    ctx.fill();
  });
};

const debouncedDraw = tailDebounce(draw, 100);

const resizeObserver = new ResizeObserver((entries) => {
  for (const entry of entries) {
    if (entry.target === canvas && entry.contentRect) {
      contentRect = entry.contentRect;
      debouncedDraw();
    }
  }
});

draw();
resizeObserver.observe(canvas);

If you look closely, especially when scaling up, you can see the scene being resampled, creating a blurry edge around the circle. When the resizing stops for at least 100ms, the scene is redrawn and the crispiness is restored.

Stroke width and font size

Here's a hollow circle with a 3px border, with the text "circle" in the middle:

ctx.lineWidth = 3;

ctx.strokeStyle = 'white';
ctx.beginPath();
ctx.arc(canvas.width / 2, canvas.height / 2, radius, 0, Math.PI * 2);
ctx.stroke();

const fontSize = 1 * dpr;
const fontFace = 'Varela Round';

ctx.fillStyle = 'white';
ctx.font = `${fontSize}em ${fontFace}`;
ctx.textAlign = 'center';
ctx.textBaseline = 'middle';
ctx.fillText('circle', canvas.width / 2, canvas.height / 2);

The stroke width is not affected by the intrinsic resolution of the canvas. When you set the stroke width to 3, it will always be 3 logical pixels wide. Font size, however, needs to account for DPR adjustments.

Here's the same scene without the DPR adjustment:

If your DPR is greater than 1, the border should still appear more or less the same thickness as the previous one, but blurrier.

Solid shapes, images, and text should consider DPR for clarity. Strokes not so.

We Have a Corner Problem

Ateş Göral — Thu, 28 Nov 2024 24:00:00 GMT

The movement constraints of all 8 drag handles of a crop rectangle can be implemented by reusing the implementation of one corner.

The complexity of a crop rectangle

Oh man. Have you ever tried implementing a draggable crop rectangle from scratch? To give it all the flexibility you'd expect from a mature crop rectangle implementation there are many constraints to solve:

Drag the rectangle itself around by starting the dragging inside. Keep the rectangle inside the image. This is the easiest to implement.
Resize the rectangle by dragging any of the four corner drag handles. Each drag handle changes different properties of the rectangle:
- Top left changes the x, y, width, and height.
- Top right changes the y, width, and height.
- Bottom left changes the x, width, and height.
- Bottom right only changes the width and height.
- Keep the corners inside the image.
Resize the rectangle by dragging any of the four side drag handles. Again, each drag handle changes different properties of the rectangle. Keep the sides inside the image.
Don't allow the rectangle to go smaller than a minimum width and height.
Easy so far.
Now add optional aspect ratio enforcement while doing all of the above.
Make the aspect-ratio-enforced dragging feel natural instead of letting the handles jump around weirdly while trying to follow weird pointer movements. (Solution: project the pointer movement delta vector onto the aspect ratio vector.)
Corner drag handles should stay within the image by smartly clamping their x/y coordinates to obey the aspect ratio enforcement.
Side drag handles move the sides, but actually move the two adjacent corners symmetrically. Now we have not one but two corners to simultaneously keep inside the image while enforcing the aspect ratio.

Looking at things from a different angle

What do the four corner drag handles have in common? They're the same corner if you tilt your head at increments of 90 degrees. So all I had to do was to rotate the frame of reference by the appropriate multiple of 90 degrees, apply corner logic for only one of the corners, and rotate back the frame of reference. And which corner do we pick? The simplest one, of course. The bottom right corner only changes the width and height of the rectangle!

Here's all that's involved in implementing the bottom right corner drag handle:

From the pointer down to the pointer move event, get the pointer movement delta vector: (dx, dy).
Project the pointer delta vector onto the aspect ratio vector: (width, height).
Clamp the projected vector to the image boundaries while preserving aspect ratio.

And the frame of reference rotation trick for the bottom right corner looks like this:

Once we have a moveCorner method that handles the bottom right corner, and a withFrameOfReference wrapper, the implementation of e.g. the top right corner becomes just:

export const moveTopRightCorner = withFrameOfReference(moveCorner, Math.PI / 2);

The corners are reduced to a single corner problem.

Reflecting on things

What about the sides? A side drag handle can be seen as not dragging the side at all, but causing the dragging of the two adjacent corners while preserving the overall aspect ratio of the rectangle. There's symmetry across the middle.

If we forget about the two corners and the symmetry among them, and just focus on one of the corners, we're back to just dealing with the same old bottom right corner.

Here's the first tweak. We have yet another frame of reference: We're now operating in a squished coordinate system. The aspect ratio that we enforce on the drag handle is half of the original aspect ratio: (width, height / 2):

However, there's another edge case (oh, the puns!) that we must deal with. The bottom right corner might be free to move vertically more then it's top right counterpart:

To overcome this issue, here's the second tweak. We reflect the bounding rectangle (the rectangle representing the image itself) along the axis of symmetry and then intersect the two bounding rectangles to derive a smaller bounding rectangle that keeps both corners within the image:

Once we have a moveEdge method that internally uses the moveCorner method, we put our withFrameOfReference wrapper to good use to implement all side drag handles:

export const moveTopEdge = withFrameOfReference(moveEdge, Math.PI / 2);

Not a corner problem

One last piece of the puzzle is to prevent the crop rectangle from being shrunk beyond dimensions that would break the UX. To do this, the only thing we need to do is to clip the bounding rectangle:

But so much math!

This is one of those problem domains where throwing conditional logic (e.g. a boatload of if statements) might have done the job. Might. I doubt it, because there's only so much you can do by sidestepping vector math in a vector problem domain. Also, reduction of this problem to a few math principles allows us to just rely on well-established math.

Another advantage of the reduction of all drag handles into a single corner drag handle problem is, if the implementation of the bottom right corner is right, then everything else is right. You will not find a bug with any of the 8 drag handles if you can't find a bug with the bottom right corner!

We now only have a single corner problem!