DEV Community: Özer Gökalpsezer

How to render code videos with React

Özer Gökalpsezer — Sat, 16 May 2026 17:39:09 +0000

Most developers share code as screenshots. Carbon, ray.so, a quick crop from VS Code. They look fine, but they sit still in a feed full of motion, and most people scroll past.

A short video of the same code, typing itself out, behaves very differently. It catches the eye for the first second, which is usually all you need.

You can build this with React. The library is Remotion. Once you understand two things, that a frame is just a function of time, and that React already gives you everything else, the rest is small.

This post walks through a minimal version: a typing animation with syntax highlighting, rendered to MP4. Around 100 lines.

Why React for video

Remotion treats a video as a React tree. You write components. The library renders them once per frame and stitches the frames into a video file. There is no timeline panel, no keyframes, no After Effects.

Two hooks do most of the work:

useCurrentFrame() returns the current frame number.
interpolate(frame, [from, to], [a, b]) maps that frame to any animated value.

Everything else is React you already know.

Setting up

npm create video@latest -- --template hello-world
cd my-code-video
npm run dev

This opens Remotion Studio at localhost:3000. The studio is just a preview; the source of truth is src/Composition.tsx. Replace its contents as we go.

The entry point registers a composition (width, height, fps, duration) and points it at a component:

// src/Root.tsx
import { Composition } from "remotion";
import { CodeVideo } from "./CodeVideo";

export const Root = () => (
  <Composition
    id="CodeVideo"
    component={CodeVideo}
    durationInFrames={120}
    fps={30}
    width={1080}
    height={1920}
  />
);

That is the whole config for a 4-second 1080×1920 vertical video at 30 fps.

Syntax highlighting without the async trap

Remotion renders frames synchronously. Shiki, the highlighter, loads its themes and grammars asynchronously. If you call it inside a component, the first frame renders with no colors.

The fix is delayRender / continueRender. You tell Remotion to pause until your data is ready:

import { delayRender, continueRender } from "remotion";
import { useEffect, useState } from "react";
import { codeToHtml } from "shiki";

function useHighlightedCode(code: string, lang: string, theme: string) {
  const [html, setHtml] = useState<string | null>(null);
  const [handle] = useState(() => delayRender("Highlighting code"));

  useEffect(() => {
    codeToHtml(code, { lang, theme }).then((out) => {
      setHtml(out);
      continueRender(handle);
    });
  }, [code, lang, theme, handle]);

  return html;
}

Now the first frame is colored, and Remotion does not start rendering until Shiki has loaded.

The typing animation

The trick is that the visible substring of the code is a function of the frame:

import { useCurrentFrame, interpolate } from "remotion";

const code = `function hello(name) {
  return \`Hi, \${name}\`;
}`;

export const CodeVideo = () => {
  const frame = useCurrentFrame();

  const charsVisible = Math.floor(
    interpolate(frame, [0, 90], [0, code.length], {
      extrapolateRight: "clamp",
    }),
  );

  const visible = code.slice(0, charsVisible);
  const html = useHighlightedCode(visible, "javascript", "github-dark");

  return (
    <div
      style={{
        flex: 1,
        background: "#0d1117",
        fontFamily: "JetBrains Mono, monospace",
        fontSize: 48,
        padding: 80,
        whiteSpace: "pre",
      }}
      dangerouslySetInnerHTML={{ __html: html ?? "" }}
    />
  );
};

Frame 0 shows nothing. Frame 90 shows the full snippet. Frames in between show a growing prefix. clamp keeps it pinned to the end so the last 30 frames are a steady "finished" state, useful for the eye to land and read.

interpolate does linear easing by default. Pass easing: Easing.out(Easing.cubic) if you want it to slow down at the end, which feels more like real typing.

Loading a real font

System monospace varies across platforms, and on AWS Lambda or any headless renderer you cannot rely on it at all. Load a font explicitly:

import { loadFont } from "@remotion/google-fonts/JetBrainsMono";

const { fontFamily } = loadFont();
// then: fontFamily in your style

@remotion/google-fonts is build-aware. It registers the font with the renderer so it shows up correctly during headless rendering.

A blinking cursor (optional, 6 lines)

const cursorVisible = Math.floor(frame / 15) % 2 === 0;
// in your JSX, after the highlighted code:
{cursorVisible && <span style={{ background: "#fff", width: 20, height: 56 }} />}

That is all. The cursor is just a div whose visibility flips every 15 frames.

Rendering to MP4

npx remotion render src/index.ts CodeVideo out/video.mp4

The first render is slow because Chromium boots once. After that, frames render in parallel across CPU cores. A 4-second 1080×1920 video on a laptop takes 10 to 20 seconds.

For vertical platforms (TikTok, Reels, Shorts), keep the 1080×1920 composition. For Twitter or a blog header, change the composition to 1920×1080 and you are done. Same component, different framing.

Where to take this

The piece above is the floor. Things you can layer on, each maybe a weekend:

Line-by-line reveal instead of character-by-character. Feels less frantic for longer snippets.
Diff mode. Two versions of the code, the deletions fade out, the additions fade in. The diff npm package gives you the line ops; the rest is interpolate.
Token burst. Shiki returns tokens with positions; you can animate each one independently.
Keystroke audio. <Audio /> component with a short click sample, played on every character increment.
Backgrounds. Gradients, particles, a subtle drift. Just CSS or SVG, animated with interpolate.

Each of these is its own post. The core never changes: a frame is a function of time, and React handles the rest.

A short aside

I built all of the above for myself, then realized I did not want to copy-paste Remotion configs every time I wanted to post a snippet. So I packaged it as a small web app called code2clip: paste code, pick a theme and aspect ratio, get an MP4. If this tutorial reads like more weekend than you have, that exists. If it does not, the Remotion approach above is the whole picture; you do not need a tool.

Closing

Code screenshots are not going away, and they should not. But for the specific case of a developer feed (Twitter, LinkedIn, TikTok, Shorts), a 10-second video of code typing itself out behaves measurably differently from a static image. The infrastructure to build one is small, and you already know most of it.

What format are you using for code right now: screenshots, gifs, video? Curious whether anyone else has tested the same snippet in two formats.

Why existing React color pickers frustrated me (and what I built instead)

Özer Gökalpsezer — Sun, 31 Aug 2025 19:58:52 +0000

After building dozens of React applications, I thought choosing a color picker would be simple. Just grab a popular library from npm, import it, and move on, right? Wrong. Every existing solution I tried left me frustrated, leading me to build another library and here's why.

The monolithic problem that started it all

Most React color pickers give you a single, rigid component that looks something like this:

<ColorPicker />

That's it. One big, inflexible box with everything baked in. Want to move the hue slider above the saturation area? Too bad. Need to add your own custom controls between the picker and the sliders? Not happening. Want to create a compact horizontal layout for mobile? Sorry, you're stuck with whatever the library designer thought was best.

The frustration: Every design system is different, but color pickers force you to accept their vision or hack around it with brittle CSS overrides.

The layout inflexibility problem

Here's what really bothered me: I needed a color picker for a design tool where the layout requirements kept changing. Sometimes I needed a compact horizontal layout, sometimes vertical, sometimes I wanted to inject custom controls between components.

Every library I tried gave me a pre-built layout with limited customization options. Want the alpha slider above the hue? Not possible. Need to add a custom preset palette between the saturation area and sliders? Good luck with CSS hacks.

The frustration: Why can't I just arrange the color picker components exactly how my design needs them?

The CSS override nightmare

Most color pickers come with their own CSS that you have to fight against. Want to match your design system's border radius? Override their styles. Need custom spacing? More CSS overrides. Dark mode? Hope they thought of that.

I spent more time wrestling with CSS specificity and !important declarations than actually building features. The color picker should work with your design system, not against it.

The frustration: Why am I fighting the library's CSS when I just want to pick colors?

State management that fights you

Here's a scenario that drove me crazy: I'm building a design tool where users work in HSL values, but every color picker I tried would:

Take my HSL input
Convert it internally to RGB or HSV
Give me back a completely different HSL value due to rounding errors
Force me to manage the "drift" between what the user input and what I get back

Want to initialize with { h: 240, s: 100, l: 50 } and get back exactly that format? Good luck. Most libraries have their own internal state management that assumes you want whatever format they prefer.

The frustration: I know what format I want — why won't you just give it to me?

What I built instead: react-beautiful-color

After hitting these walls repeatedly, I decided to build something different. Here's how react-beautiful-color solves each of these problems:

Compound components that actually compose

Instead of one giant component, you get composable pieces:

<ColorPicker color={colorInput} onChange={setColor}>
  <ColorPicker.Saturation className="flex-1 mb-3" />

  <div className="flex items-center gap-3 p-3 pt-0">
    <ColorPicker.EyeDropper>
      <Pipette />
    </ColorPicker.EyeDropper>

    <div className="flex-1 flex flex-col gap-3">
      <ColorPicker.Hue className="h-4" />
      <ColorPicker.Alpha className="h-4" />
    </div>
  </div>
</ColorPicker>

Want the hue slider on top? Move it. Need a custom layout? Build it. Want to add your own controls? Drop them anywhere. You control the layout, not the library.

True compound component architecture

Unlike other libraries that give you one monolithic component, react-beautiful-color is built from the ground up as composable pieces. Each part (Saturation, Hue, Alpha, EyeDropper) is an independent component that you can arrange however you want.

Need a custom layout? Compose it. Want to add your own components between pieces? Drop them in. Building a design system with specific spacing requirements? You control every aspect of the layout.

Format preservation that actually works

The useColorState hook preserves your input format while giving you all formats instantly:

const [{ colorInput, colorState }, setColor] = useColorState({ 
  type: 'hsl', h: 240, s: 100, l: 50 
});

// colorInput stays as HSL - no format drift!
console.log(colorInput); // { type: 'hsl', h: 240, s: 100, l: 50 }

// But you get all formats instantly
console.log(colorState.hex);  // "#0000ff"
console.log(colorState.rgb);  // { r: 0, g: 0, b: 255 }
console.log(colorState.hsv);  // { h: 240, s: 100, v: 100 }

No conversion drift. No state fighting. Just the format you want, when you want it.

Tailwind-first styling approach

Instead of shipping custom CSS that you have to override, react-beautiful-color uses pure Tailwind classes. Your design system uses Tailwind? Perfect integration. Custom design tokens? Just pass different classes. Dark mode? It just works.

No CSS overrides, no specificity wars, no style conflicts. The components are unstyled by default and accept whatever Tailwind classes you want to apply.

Modern browser APIs

Built-in support for the EyeDropper API means users can pick colors directly from their screen — no complex implementations or polyfills required.

TypeScript from day one

Complete type safety with discriminated unions means you catch color format errors at compile time, not runtime. IntelliSense works perfectly, and refactoring is safe.

The result: happiness

Building with react-beautiful-color feels different. Instead of fighting the library, you're composing with it. Instead of working around limitations, you're building exactly what you need.

The compound component pattern means every use case I've encountered from simple color inputs to complex design tools can be built elegantly without hacks or workarounds.

You get a truly flexible compound component API that adapts to your design system instead of forcing your design system to adapt to it. Every component is independently stylable, positionable, and composable.

Sometimes the best solution isn't finding the perfect library — it's building the library you wish existed.

Documentation and examples: react-beautiful-color.dev