DEV Community: Vinamra Sareen

Miraiclip: an open-source engine for building video editors in the browser

Vinamra Sareen — Tue, 22 Sep 2026 05:52:17 +0000

I've been building Miraiclip — an open-source, framework-agnostic library for building video editors in the browser — and it's now on npm under MIT. This post covers what it is, the one design decision everything hangs on, and a few hard-won lessons from making video actually work in a browser.

The problem

Every browser video editor ends up rebuilding the same difficult parts: frame-accurate playback, an undo/redo system that never corrupts state, and exports that match what the preview showed. These are engine problems, not product problems — but there's no engine to reach for, so every team pays for them again.

Miraiclip is that engine. It is deliberately not an editor app. There's no timeline UI, no buttons — the core is headless: project state, a microsecond-precision timeline, and a full command history, with rendering delivered as a separate layer. You bring the UI (React, Vue, Svelte, vanilla — the core has zero UI dependencies).

One design decision: everything is a command

Instead of calling imperative methods that mutate state, you dispatch descriptive commands. Every command is deterministic, validated against a schema, serializable, and invertible.

import { createProject } from "@miraiclip/core";

const project = createProject({ width: 1920, height: 1080, fps: 30 });

project.dispatch({
  type: "asset/add",
  payload: { id: "intro", kind: "video", src: "/media/intro.mp4", durationUs: 12_000_000 },
});
project.dispatch({ type: "track/add", payload: { id: "video-1", kind: "video" } });
project.dispatch({
  type: "clip/add",
  payload: {
    kind: "video", id: "clip-1", trackId: "video-1", assetId: "intro",
    startUs: 0,            // timeline position in microseconds
    durationUs: 5_000_000, // 5 seconds
  },
});

// Batch commands into one undoable transaction
project.transaction(() => {
  project.dispatch({ type: "clip/split", payload: { clipId: "clip-1", atUs: 2_000_000, newClipId: "clip-1b" } });
  project.dispatch({ type: "clip/move", payload: { clipId: "clip-1", startUs: 1_000_000 } });
});

project.undo();
project.redo();

Three things fall out of this decision without being bolted on:

Undo/redo — commands are invertible, so history is exact, replayable, and inspectable.

Collaboration — every state change is emitted as granular RFC-6902 JSON patches. Command and patch streams are the substrate for multiplayer editing:

project.events.on("patches", ({ patches }) => {
  // [{ op: "replace", path: "/clips/clip-1/startUs", value: 1000000 }]
});

AI control — commands are plain descriptive data with a published catalog and JSON schemas. An LLM can read project state and generate valid edit sequences; the command catalog doubles as a tool definition. A human clicking a UI, an LLM planning an edit, and a sync layer replaying a collaborator's changes all speak the same language.

Playback and export

The rendering layer (@miraiclip/renderer) is a WebCodecs decode pipeline plus a WebGL compositor (PixiJS), with an audio-master clock:

import {
  createPixiBackend, createPlayer, exportProject,
  openMediabunnyDemuxer, createWebCodecsDecoderFactory,
  createWebAudioOutput, openMediabunnyAudio,
} from "@miraiclip/renderer";

const backend = await createPixiBackend({ canvas, width: 1280, height: 720 });
const player = createPlayer(project, {
  backend,
  openDemuxer: openMediabunnyDemuxer,
  createDecoder: createWebCodecsDecoderFactory({ maxOutputDimensionPx: 1920 }), // proxy preview
  audioOutput: createWebAudioOutput(),
  openAudio: openMediabunnyAudio,
});
player.play();

// Offline export, faster than realtime — same compositor as the preview
const bytes = await exportProject(project, { format: "mp4", quality: "high" });

The export renders through the same compositor as the preview, so preview/export parity holds by construction rather than by testing luck. Output goes to MP4 or WebM, and it can stream straight into a file (showSaveFilePicker writable) so long exports don't accumulate in memory. There's also @miraiclip/server-export, which runs the identical pipeline in headless Chrome from Node:

miraiclip-export project.json --out final.mp4 --quality high

Keyframe animations (cubic-bézier easings), effects (color adjust, blur, chroma key), transitions with equal-power audio crossfades, and karaoke-style captions with SRT/VTT and ASR word-timestamp import are built in — and they render identically in preview, browser export, and server export, because it's one compositor everywhere.

Things the browser made me learn

A few lessons that shaped the engine, in case you're building anything media-heavy:

"Frame-accurate" means presented frames, not scheduled ones. Callbacks tell you a frame was scheduled; only reading pixels back tells you what the user actually saw. Miraiclip's test fixtures encode each frame's index as its color, so tests assert on what's really on the canvas — that's how several seek and playback bugs were caught that callback-based tests would have blessed.

Export memory must be independent of timeline length. Mixing an hour of audio in one OfflineAudioContext buffer costs ~1.4 GB; encoding into an in-memory buffer costs the whole file. Miraiclip mixes audio in bounded sequential chunks interleaved with the frame walk and streams encoded output to disk — a demonstrated one-hour export (86,400 frames plus a full hour of audio) peaked at 165 MB of JS heap, running at 1.6× realtime on a dev laptop.

Trust nothing you can't verify with a second decoder. Exports are validated by a corpus that re-decodes every file with ffmpeg — an independent decoder — checking every frame's timestamp and pixels, audio gain, and A/V sync (measured offset: 0 ms at both ends of the file). A muxer bug can't hide by round-tripping through the encoder that produced it.

Status

Miraiclip is pre-1.0: the core model is stable in shape, but expect API changes between minor versions. Current packages: @miraiclip/core, @miraiclip/renderer, and @miraiclip/server-export. Chromium-family browsers are the target for rendering and export (WebCodecs-based); the core runs anywhere JS runs, including Node.

If you're building anything with video in the browser — an editor, a clip tool, automated video generation — I'd genuinely value your eyes on the API before it hardens.

GitHub: github.com/comaniacs/miraiclip
Docs + live examples (the code shown is the code that runs): comaniacs.github.io/miraiclip
npm: @miraiclip/core

Questions and issues welcome — and if you try it, I'd love to hear what you build.

How fastify performs better than other frameworks ?

Vinamra Sareen — Tue, 13 Apr 2021 12:11:12 +0000

What is Fastify ?

Fastify is a web framework for developing the backend of an application based on its powerful plugin architecture. Fastify efficiently handles the resources of the server and helps you serve the max number of requests per second.

It is the most popular framework in town not because of it’s user base but because of the fact it is the most fastest framework available.

Why use Fastify ?

There are many alternatives in market, then why focus on fastify ?
If you have worked with backend applications before you might have heard of some popular frameworks such as express, koa, hapi or restify. Out of these the most popular framework has been Express.js, due to its wide use and community support it is always at the top of charts. But in terms of performance it is not.

A good way to understand is by comparison.

Have a look at these comparisons I did between fastify and express.

The first image is of express, where we have used autocannon (a benchmarking tool).The number of requests served by express is 14k

When compared to fastify, it outperforms express. The number of requests served per second is 28K, two times than that of express.

You can also checkout this link, for benchmarks with other frameworks : Benchmarks

Reasons for performance

One of the primary reasons for the performance of fastify is because of its dependencies. Some of the dependencies that fastify uses:

find-my-way
pino
fast-json-stringify
fastify-helmet

And might be few others too.

If we take a close look at each of these dependencies.

For routing they use find-my-way which avoids closure allocation, is built on a radix tree and safe to use. Those who are not aware of closure based problems in javascript:

1. Variables used by closure do not get garbage collected.
2. Memory snapshot of the application increases if closures are not used properly

Fastify uses pino for logging which is more performant than other logging libraries available (bunyan, winston).
JSON.stringify cannot be optimized by v8, so they use fast-json-stringify which is schema based JSON rendering and generates code based on schema, which greatly reduces the computation overhead for identifying field types for JSON serialization.
Fastify-helmet performs better than other libraries

That’s been said about dependencies, there is another reason behind fastify’s performance.

Its life cycle.

It's not just about dependencies it uses but it has been designed in such a way that it optimizes with v8 in the best possible way.

What code developer writes is used by fastify which is pre initialized so it is available at the time it is requested which makes it faster, the pre initialized data structures are fast and improves and the efficiency of the fastify framework making it more performant.

Please, let me know everyone if you have anything to add, or correct.

References: Fastify

How to improve database performance for insert queries

Vinamra Sareen — Sun, 28 Feb 2021 07:55:09 +0000

Hey all, this is my first blog, I have recently started working as a full stack web developer at Adda52Rummy and I was assigned with a task to insert some records in database, which I thought I handled appropriately. But my manager gave me csv file of 5K records to insert to database. It was synchronous code and took some time.

About tech Stack, I was working in Node.js with MariaDB and Fastify framework (performs better than express and other sever frameworks or library). I used Sequelize as ORM library, it is a promise-based Node.js ORM for Postgres, MySQL, MariaDB, SQLite and Microsoft SQL Server. To improve the performance of my operations, I needed to run insert operations in multiple batches and those batches had to run in parallel. Aha! Sound nice, but to how to implement it. After spending ample time of searching I found some solution on how to do it.
Thanks to Evan Siroky.

The solution was to use bulkCreate to insert multiple batches and use asnyc.cargo function to run batches in parallel. After using this I was able to insert data in 2 seconds and guess what, I was able to insert 100K records in 5 ~ 7 seconds.

Let's jump straight to code:

In my controllers, coupon.js

const Coupon = require("../models/coupon");

// exports.createCoupon = async (row) => {
//   await Coupon.sync();
//   return Coupon.create({
//     coupon_code: row.coupon_code,
//   });
// };

// Here I am using bulkCreate
exports.createCoupon = (tasks, inserterCb) => {
  Coupon.bulkCreate(tasks).then(function () {
    inserterCb();
  });
};

I have created a utility folder, where I have created a csv-to-db.js_ file:

const fs = require("fs");
const path = require("path");
const async = require("async");
const csv = require("csv");

function csvToDb(filename, fn) {
  let input = fs.createReadStream(
    path.resolve(__dirname, "../public/assets", filename)
  );
  let parser = csv.parse({
    columns: true,
    relax: true,
  });

  let inserter = async.cargo(function (tasks, inserterCb) {
    fn(tasks, inserterCb);
  }, 1000 // -> task size); 

/* you can specify how many task you want to handle, I have set it to 
1000 tasks at a time parallel, I can say for 100K let's handle 
50K - 50K to take much less time, but it doesn't work that way,
 it will take maybe two or more seconds to execute input of size 50K,
 as it is large input. So take a size which execute faster but handles
 many task as possible. */

  parser.on("readable", function () {
    while ((line = parser.read())) {
      inserter.push(line);
    }
  });

  parser.on("error", function (err) {
    throw err;
  });

  parser.on("end", function (count) {
    inserter.drain();
  });

  input.pipe(parser);
}

module.exports = csvToDb;

Now, when I call this route 'http::/localhost:3000/coupon', this is the code that gets executed.

const Coupon = require("../controllers/coupon");

module.exports = function routes(fastify, options, done) {
  fastify.get("/coupon", async (req, res) => {
    csvToDb("filename.csv", Coupon.createCoupon);
    return { statusCode: 200, message: "sucess" };
  });

  done();
}

Thanks to read out.

All references: