Key takeaways
- Before adopting a second video rendering framework we built the same two clips in both and rendered them, rather than comparing feature lists.
- The finished frames were a tie. Both sit on the same browser and encoder underneath, so the same math produced the same pixels.
- The new one won on everything around the render: about half the code, no per project install, and a check command that caught a real bug before a single frame existed.
- The verdict was a split, not a switch. The older framework keeps the one job it already does better than anything else.
- Nothing gets a slot on the content calendar until one real production piece has shipped through it.
We already had a way to render animated video from code. It builds the kinetic typography Shorts, the ones where words land one at a time on the exact frame they are spoken. It works.
Then a second framework showed up that does the same category of thing from plain HTML instead, with no build step. The tempting move is to read both websites, decide which one sounds better, and start migrating. Michael asked for the opposite. Build the same thing twice, render both, then talk.
The same two clips, twice
We picked two pieces of work that between them cover most of what we actually make. A vertical brand sting, the short animated tag that opens a Short. And a two scene stat reveal with a crossfade between the scenes and a number counting up.
The second one matters more than it looks. A crossfade is where timing systems break, and a counting number is where a framework either gives you real interpolation or makes you fake it.
Both got built. Both got rendered locally. Then we looked at the output.
The frames were a tie, and that was the useful finding
The rendered video was the same. Not similar, the same. Both frameworks drive a headless browser and hand the frames to the same encoder, so once the animation math matches, the pixels match.
That sounds like a boring result and it is the most useful thing the exercise produced. It killed the entire quality argument in one afternoon. Neither tool makes better video. So the decision had to be made on everything except the video, which is a much more honest place to decide from.
What actually separated them
Three things, in the order they mattered.
- Code size. Roughly half the source lines for the same clip. Not a dramatic difference on one file, a very real one across a year of them.
- Install cost. The newer one shares a single cache across every project on the machine. The older one installs its own dependency tree per project, several times larger, every time. If you make a lot of one off graphics that difference compounds fast.
- It checks itself. This is the one that decided it.
The new framework ships a check command that reads the composition before rendering anything. On our crossfade test it found a genuine bug: two captions overlapping during the transition, both visible for a few frames, in a piece I had already looked at and thought was fine.
It caught that in seconds, without rendering. The older framework has no equivalent, which means the same bug there is found by rendering the video, watching it, and noticing. That is minutes instead of seconds, and it only works if the person watching is paying attention on the right two frames.
Automated correctness checking is worth more than it sounds when the output is video. Video is the worst medium for review, because the only way to check it is to sit through it in real time, and a defect that lasts four frames is genuinely easy to miss.
The verdict was a split
Here is the part that keeps this honest. The recommendation was not to switch.
The older framework does one job nothing else covers well: it turns a folder of screenshots into an animated product walkthrough. That is the shop ads, the client demos, the how it works videos. Its ecosystem is also years old rather than weeks old, and if a contributor already thinks in that programming style it is the more natural fit.
So the split is new framework for new short form graphics, old framework for the screenshot walkthroughs it already owns, and neither one touches the existing overlay system that burns our logo and captions onto finished video. That system already produces correct transparency, and correct transparency was hard won.
Three tools, three clearly separated jobs. That is a worse headline than we replaced our video stack and it is a much better outcome.
Why this matters for a Go High Level Bay Area business
You are going to be sold a replacement for something you already own roughly once a month. The pitch is always the same shape: newer, faster, cheaper, and look at this demo.
Three things that make those decisions cheap to get right:
- Rebuild one real thing you already have. Not the vendor's demo, your actual work. Their demo is chosen to make them look good. Your work is chosen by your customers.
- Ask what the tool does when you are wrong. Anything can produce the right output from the right input. The difference between tools shows up when the input is wrong, and whether the tool tells you or ships it.
- Let the answer be a split. Most migrations should be partial. The question is not which tool wins, it is which jobs each one deserves.
The honest lesson is that we spent an afternoon on this and would have spent a week guessing otherwise. Two comparable builds and a render is not a big investment, and it produced a decision nobody has to revisit.
And the rule that came out of it is the one we now apply to everything: no tool earns a permanent slot until one real piece of work has shipped through it. A test project proves the tool runs. A real deliverable proves it survives a deadline.
If you want systems chosen this way rather than by whoever pitched last, that is most of what we do. Have a look at optechsol.llc.