Redner.
Video creation should feel exactly like writing.
The Problem
Modern video editing is inherently broken for the average creator. The paradigm hasn't changed since the early days of Premiere Pro: complex multi-track timelines, detached asset bins, and a steep learning curve just to sync audio with visual states.
I wanted to build a web-first system that abstracts the complexity of the timeline. If you can type out a document, you should be able to orchestrate a video.
Architecture & The Stage Engine
Building a video editor in the browser is fundamentally an exercise in state management and rendering performance. The core of Redner relies on two distinct systems: the Timeline Playback mechanism and the Stage Preview engine.
Engineering Challenge: The WebAudio API
Syncing visual state changes with audio playback in a browser is notoriously difficult due to JavaScript's single-threaded nature. To solve this in Phases 2.3 and 2.4, I decoupled the audio playback layer from the React render cycle. By leveraging the WebAudio API clock as the absolute source of truth, the Stage Engine independently polls for state updates, ensuring frame-perfect synchronization without dropping frames during heavy UI renders.
The frontend architecture avoids traditional heavy DOM manipulation, leaning instead on optimized canvas rendering and strict separation between the "editor state" and the "player state."
Takeaways
- 01State is everything. Complex local state in a web app can't just rely on React Context. You need deterministic, immutable stores to handle fast-scrubbing on a timeline.
- 02Browser APIs are incredibly powerful. You don't always need WASM immediately. Maximizing the WebAudio API and RequestAnimationFrame can get you 90% of the way there.
- 03UX dictates architecture. The decision to make video editing feel like "writing" meant throwing away traditional data models for tracks and clips, and engineering a completely new schema.