Updates: 6 new posts for 2026-08

content/posts/2026-08-10-aval-interactive-video-format/index.md

@@ -0,0 +1,60 @@
+---
+title: 'Aval: an open source format for interactive video on the web'
+summary: 'I built Aval, an open source container and runtime for interactive video on the web: a built-in state machine, frame-accurate transitions, and packed alpha transparency, decoded through WebCodecs. Here''s what it does, why the web needed it, and what has landed since launch.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+I've just open sourced **Aval**, a new format for interactive video on the web. It ships with a built-in state machine, frame-accurate transitions, and packed alpha transparency, and it's probably the craziest thing I've ever built with Codex.
+
+I'd been dreaming about this technology for years, mostly because every time we wanted a piece of video on a landing page to *react* to something — a hover, a scroll position, a click, a state change in the UI — we ended up building a pile of workarounds instead of shipping the idea.
+
+## The problem: video on the web is a black box
+
+A `<video>` tag is great at one job: play this file from start to finish. The moment you want something more interactive, the cracks show up fast.
+
+Say you have a product hero: a 3D render of a device that sits idle, then smoothly opens when the user hovers a button, then loops in an "open" state until they move away, then closes. That's four pieces of motion — idle loop, open transition, active loop, close transition — and a set of rules about which one plays when.
+
+With plain HTML video, you have a few bad options:
+
+- **Multiple video files and swap the source.** Every swap means a new load, a new decode, and a visible flicker at the seam.
+- **One long video and seek to timecodes.** Browsers don't seek to exact frames reliably. You ask for 2.400s and land somewhere near it, and "near it" reads as a jump.
+- **Image sequences or sprite sheets.** Frame-accurate, but the file sizes are brutal — you're throwing away video compression entirely.
+- **Lottie or a vector animation.** Wonderful for illustration and UI motion, but it can't represent a rendered 3D scene or real footage.
+
+And then there's transparency. If you want video composited over a page background — a floating object with no rectangular box around it — your options in browsers have historically been narrow, inconsistent, and expensive.
+
+## What Aval is
+
+Aval is a container format (`.avl`), a compiler that produces it, and a runtime that plays it in the browser. Three ideas hold it together.
+
+**A built-in state machine.** Instead of a single timeline, an Aval file describes states and the transitions between them. Idle, opening, active, closing — declared inside the asset, not stitched together in your application code. The runtime exposes those states, so your app just says "go to active" and the format handles what has to play to get there. If you've used Rive for vector animation, the mental model is similar, except the source material can be any video the compiler can eat: a Blender render, screen capture, real footage.
+
+**Frame-accurate transitions.** The runtime doesn't ask the browser to seek. It decodes frames itself through WebCodecs — the low-level browser API that gives you direct access to the decoder instead of the opaque `<video>` element — and composites them on the GPU. That means a transition starts on the exact frame it's supposed to start on, and states join without a flash or a stall.
+
+**Packed alpha transparency.** Alpha channel support in web video codecs is patchy at best, so Aval sidesteps the problem: the compiler packs the alpha channel into the video frame alongside the color data, and the runtime recombines them at draw time. You get transparent video that survives normal video compression, in codecs browsers already decode in hardware.
+
+<Video src="https://video.twimg.com/amplify_video/2077405925183279104/vid/avc1/3840x2160/cPmxGScXFcFhivSb.mp4" width="3840" height="2160" controls muted poster="./video-cover-1.jpg"></Video>
+
+## How it got built
+
+This started as a weekend project with the 5.6 Sol Ultra model. Two things went into the queue: an agentic-first remote FFmpeg service, and a WebCodecs playback and compositing engine. The second one was the gamble.
+
+Codex worked for about 20 hours straight on it. I was honest about the odds at the time: either we get something really dope out of it for the whole community, or it's a complete waste of tokens. What convinced me to let it run is that the models have approached a level where a project like this is worth attempting solo — a custom container format, a compiler, and a GPU compositing runtime is not a weekend's worth of work by any historical measure, and it's the kind of thing that would previously have needed a small team and a quarter.
+
+The first project turned out to be genuinely useful on its own: a remote FFmpeg service designed to be driven by an agent rather than by a human typing flags. It optimizes videos, runs quick quality comparisons between encodes, and extracts stills from footage. If you've read our notes on [creating web-optimized video with FFmpeg using VP9 and H.265](/blog/web-optimized-video-ffmpeg), you know how much of that work is iterative guess-and-check — encode, look, adjust, encode again. Handing that loop to an agent with a service that can actually run the encodes and diff the results removes most of the tedium, and it fed directly into getting Aval's compiler output right.
+
+## What has landed since launch
+
+Thank you to everyone who's tried it and filed issues. Several updates are already in the repository:
+
+- **Safari compatibility fixes.** Multiple issues resolved. Safari's WebCodecs behavior differs from Chromium's in ways you only discover by running into them.
+- **H.265, AV1, and VP9 support** across the `.avl` container, the runtime, and the compiler. Aval no longer assumes one codec: you can pick based on the tradeoff you care about — hardware decode coverage, file size, or browser support — and the format carries that choice through the whole pipeline.
+
+## A word of caution
+
+This is still an early project. It's open source because I think the web needs a shared answer to interactive video, not because it's finished, hardened, and ready to carry your production traffic tomorrow. Expect rough edges, expect the format to change, and please open issues when you hit something.
+
+If you work with motion on the web — product heroes, in-page 3D, transparent overlays, anything that has to respond rather than just play — I'd love for you to try it and tell me where it breaks.
+

content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/index.md

@@ -0,0 +1,72 @@
+---
+title: 'Four creative tools we built with Toolcraft, and why they aren''t toys'
+summary: 'Since publishing our Toolcraft starter kit, we''ve used it to build four real creative tools: a math-driven three.js scene, a sticker-and-shader mockup app, a web UI that renders in Blender, and a purpose-built animator for a single website section. Here''s what each one does and why it matters.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+When we published the [Toolcraft starter kit](/blog/how-to-craft-personal-design-tools-with-toolcraft), the idea was simple: instead of waiting for a SaaS product to support the exact thing you need, build the small tool yourself and throw it away when you're done. Since then we've been eating our own dog food while building Toolcraft's own website, and four tools came out of it.
+
+I'm sharing them because the most common reaction to anything made this way is "cute demo." A gradient generator. A pattern maker. Something you screenshot once and never open again. Fair enough — a lot of AI-built demos are exactly that. These four aren't, and the reasons why are worth unpacking.
+
+## The one that's actually about math
+
+If you look at the first demo and assume it's a render from Blender, look closer. It's not — and honestly, it's not that good. It's a [three.js](https://threejs.org/) app, which means everything you see is drawn live in the browser by your GPU.
+
+<Video src="https://video.twimg.com/amplify_video/2078121239156064256/vid/avc1/3840x2160/hKysjY-IaYAeGe10.mp4" width="3840" height="2160" controls muted poster="./video-cover-1.jpg"></Video>
+
+The interesting part isn't the rendering, it's where the shapes come from. Nobody modelled them. There's no mesh someone sculpted by hand in a 3D program. Every surface is the output of a formula — feed in a few numbers and you get a curve, twist it around an axis, repeat it, offset each copy by a fraction of a rotation, and you have a form that looks designed but is entirely computed.
+
+That's what makes it a tool rather than a picture. Because the geometry is math, every input is a parameter you can expose as a slider: number of segments, amplitude, rotation offset, thickness, easing. Move one and the whole thing re-forms instantly. You're not editing a shape, you're exploring a space of shapes, and you can drop the result into a hero section, an explainer animation, or a background loop.
+
+![A three.js scene of computed, repeating geometry rendered live in the browser, with parameter controls for the underlying formula](image-1.jpg)
+
+This is the sort of thing designers historically outsource: describe what you want, wait for a motion designer, get one variation back, ask for the same thing but slower. When the math is in front of you, that loop collapses to seconds.
+
+## Stickers, shaders, and product shots
+
+The second one started as a detour while working on Toolcraft's site. It was inspired by a post from [Fons Mans](https://x.com/FonsMans), mixed with [Paper shaders](https://github.com/paper-design/shaders).
+
+You upload a 3D model, drop your stickers onto it, tweak the shader settings, and shoot. "Shader" is the piece of jargon worth translating: it's a tiny program that runs on the GPU and decides the colour of every pixel. In practice it's what gives you the animated gradient behind the object, the grain, the iridescence, the way the light rolls across a surface. Paper shaders is a library of those effects with controls attached, so instead of writing GPU code you're moving sliders.
+
+<Video src="https://video.twimg.com/amplify_video/2077096663953408000/vid/avc1/3840x2160/DQGFY-Ji6WButLah.mp4" width="3840" height="2160" controls muted poster="./video-cover-2.jpg"></Video>
+
+Here's the concrete reason this earns its place. Say you're launching a feature and you want eight variations of the same 3D object for social, docs, and the changelog — same model, different sticker placement, different background treatment, consistent lighting. In a normal design workflow that's eight rounds of manual file wrangling. Here it's one upload and eight exports, and because the tool is yours, you can add whatever control you find yourself missing on the third export.
+
+![A 3D model in a web app with stickers applied to its surface and an animated shader background behind it](image-2.jpg)
+
+## Customise in the web, render in Blender
+
+The third tool is the one I'm most pleased with, because it steps outside the browser entirely.
+
+While everyone is vibe-coding flat pattern generators, or at best a three.js scene, we went one further: no three.js, no fake web-based depth of field, no emulated focal length. You customise in the web, and the actual frame is rendered by [Blender](https://www.blender.org/).
+
+<Video src="https://video.twimg.com/amplify_video/2074492797260870072/vid/avc1/3840x2160/jAsgCrGo2tZ4Dv29.mp4" width="3840" height="2160" controls muted poster="./video-cover-3.jpg"></Video>
+
+Why that distinction matters: browsers cheat at photography. Depth of field — the soft, out-of-focus falloff behind a subject — is usually faked in the browser with a blur applied after the fact. Focal length, the thing that makes a 35mm shot feel wide and a 105mm shot feel compressed and flattering, is often approximated too. It looks fine until you put it next to a real render, and then it looks like a website effect.
+
+Blender doesn't approximate. It simulates a camera with a real lens, so a wide aperture gives you genuine bokeh, and changing focal length changes perspective the way it would on a physical set. The tool's job is to hide all of that: the web UI is where you position the object, pick the lens, set the focus distance and the materials, and the render happens on the Blender side with the settings you chose.
+
+![A web interface with camera and material controls next to a Blender-rendered frame with real depth-of-field falloff](image-3.jpg)
+
+So instead of "here's my 3D scene, now let me learn Blender's UI," a marketer or designer gets three sliders and a render button, and the output is production quality rather than good-enough-for-a-tweet.
+
+## A tool built for exactly one website section
+
+I don't usually share work in progress, but this last one is the clearest example of the whole idea. It's a creative tool we built specifically to design and animate a single section of a website. Not a general-purpose animation editor. One section.
+
+<Video src="https://video.twimg.com/amplify_video/2079925057673994240/vid/avc1/2880x2160/oaOPNgsyXH_ubvxl.mp4" width="3840" height="2880" controls muted poster="./video-cover-4.jpg"></Video>
+
+Everything in it is under your control, and if a control is missing, you add it. That's the part that no off-the-shelf product can offer. When you're tuning a motion sequence, the thing you need on the fifth iteration is almost never in the menu — the stagger delay between items, the exact curve of the easing, the pause before the loop restarts. In Figma or a video editor you work around it. In a tool you own, you spend two minutes adding the slider and then spend your remaining attention on the design instead of the workaround.
+
+The result is a section that's tuned rather than approximated, and a build process where the designer, not a handoff document, decides how it moves.
+
+## What this set is meant to prove
+
+Taken together, these four cover a decent spread: computed geometry, GPU shader effects, a real offline render pipeline, and a single-purpose animation editor. None of them is a product. All of them solved a specific problem on a specific project faster than the alternative, and each took hours rather than sprints.
+
+That's the argument. The interesting question about AI-built software isn't whether it can produce another gradient generator — it's whether it lowers the cost of a bespoke tool far enough that building one becomes the obvious move. Once it does, the ceiling on what a small team can make stops being "what features does our design tool support" and starts being "what do we actually want."
+
+You can try the live demos for the first three on the Toolcraft site, and if you want to start building your own, the starter kit post has everything you need to get going.
+