We have written before that HTML can be a production medium for humans and models, and that Speedrun slide visuals need template rigs rather than magic.
That was the authoring lesson.
The app adds the runtime lesson.
When a digest is rendered into one video file, playback is mostly a video problem. The player buffers the file, seeks through frames, and shows controls. The slide system has already been flattened.
When a digest is HTML, the player has to run the digest.
It has to load rigs, assets, source cards, slide inputs, presenter clips, captions, controls, and animation state. It has to make the sequence feel as simple as video while keeping the structure that made HTML useful in the first place.
That is a different product.
A Digest Becomes Data
The useful shift is that a digest is no longer only a media file.
It becomes structured data: which slide types appear, in what order, with which inputs, which assets, which presenter clips, which source cards, which visual variant, and which timing rules.
That structure is why HTML is powerful. The product can choose a different rig, fix a color, swap a source, adjust a caption, or rerender a slide without regenerating a whole video.
But structure creates responsibility.
The app has to load the right data at the right moment. It has to know which rig owns which input. It has to preserve the selected variant. It has to keep the player stable when the user scrolls, pauses, seeks, or replays.
The benefit is editability.
The cost is runtime complexity.
Video Hides State
Video is blunt, but it hides a lot of state.
The animation has already happened. The transition is already encoded. The timing is already fixed. Seeking backward simply shows an earlier frame. The player does not need to understand why a stat moved, when a quote fades in, or whether a caption belongs to the narration or the slide.
HTML does not get that for free.
If the user seeks back, the animation state may need to reset. If a slide loads late, the player needs to avoid flashing broken intermediate states. If the user scrolls quickly, the controls should remain predictable while the content changes. If a digest mixes HTML slide rigs with presenter video, those layers need to stay synchronized.
The runtime has to make HTML feel native.
Otherwise the user experiences the structure as glitches.
Variants Are A Runtime Feature
Variants are not only an authoring feature.
Once the app can select slide variants at runtime, the product needs rules for how those variants are stored, chosen, tested, and repeated. A quote slide can have several coherent layouts. A source slide can have light and dark treatments. A stat slide may need more careful constraints. Some variants will work across content; others will fail with longer copy, different images, or awkward source names.
The model can generate options. A human can choose the best ones. But the runtime has to apply them consistently.
That means variation becomes product state.
Not a folder of experiments. Not a one-off design pass. A selected variant becomes part of the digest definition.
If the same digest opens tomorrow, the user should not get a different slide because the app randomly picked again. If the team is debugging a layout issue, they need to know which variant was used. If a variant fails with a certain source card, that should improve the rig or the selection rules.
Controls Are Part Of The Medium
Moving HTML into the app also changes the controls.
Tap to pause, scrub behavior, loading indicators, safe areas, captions, and landscape handling are not decorative details. They decide whether the digest feels like media or like a web page trapped inside a phone.
The app should not expose the implementation.
The user should not care that one part is HTML and another part is video. They should feel that the story loads quickly, responds predictably, and preserves enough source provenance to be trusted.
That takes real product work.
Controls must remain stable while content changes. Loading states should be delayed enough to avoid flicker but clear enough when something is genuinely slow. Source cards should show provenance without turning every URL into visual noise. Captions should support the user without fighting the slide.
The runtime is where those decisions land.
HTML Is Still Worth It
The runtime complexity does not mean HTML was the wrong choice.
It means HTML has moved from production format to product substrate.
The same structure that creates playback work also creates leverage. Slides can be inspected. Variants can be controlled. Sources can remain attached. The web player and iOS player can share a digest model. A studio tool can author content that the app can play without flattening everything into one opaque file.
That is the reason to accept the complexity.
A rendered video is easier to play. A structured digest is easier to improve.
The Product Is The Player
For Speedrun, the player is becoming part of the generation system.
Not only the last screen where output appears, but the place where the structured output proves whether it is real.
If the player handles timing, variants, controls, assets, sources, and presenter clips well, HTML remains a production medium all the way to the user. If it does not, the product will be pulled back toward flattened video because video is simpler.
The serious path is to make the runtime good enough that structure survives contact with the app.
That is when HTML stops being only a way to make slides.
It becomes the way the digest exists.
