How We Ditched Backend Rendering and Went Full Client-Side with framewebworker

The Problem with Server-Side Video Rendering If you've ever built a video editing app, you know the pain: users create clips, hit "render," and then... wait. The video gets shipped to a server, processed with ffmpeg or Remotion, and eventually comes back. It's slow, expensive, and creates a terrible user experience. At ClipCrafter , we lived with this architecture for months. Our rendering pipeline involved Inngest background functions, six dedicated API routes, a beefy Docker image with Chromium and Remotion dependencies, and a Deno runtime layer. Every render meant a round-trip to the server, and our infrastructure costs were climbing. Last week, we ripped it all out. Enter framewebworker The key insight was simple: modern browsers are powerful enough to handle video rendering directly. We replaced our entire backend rendering stack with framewebworker , a lightweight library that processes video frames in a Web Worker. The migration touched almost every layer of the app. Here's what