DEV Community: Dor

I built a tool that races you against the marathon world record

Dor — Mon, 01 Jun 2026 11:53:50 +0000

A quick fun one. I took the running app I work on, pulled out the Daniels-Gilbert VDOT model, and wired it to a question every runner secretly wonders: if you and the world-record holder started together, where would you be when they finish?

You put in one race result. It predicts your equivalent time at 5K, 10K, half, and marathon, then animates a little race for each: your runner and the pro both set off down the track, the pro reaches the finish line, and a green bar fills up to wherever you are when they cross it. The marathon one is brutal. For a 22:00 5K runner, Sabastian Sawe finishes his 1:59:30 marathon while you are still about 18 km from the line.

Try it: https://runnerapp.pro/tools/vs-the-pros

A few build notes for anyone doing similar:

The math is tiny. VDOT is two equations (an oxygen-cost curve and a percent-of-max-you-can-hold curve) plus a bisection to invert it. I open-sourced that part: https://github.com/dortaldt/vdot-runner

The animation is just CSS custom properties + transitions. Each lane sets --up (your position) and --p (the pro at 100). The runner markers transition left, and a fill div transitions width, both driven by the same variable:

.track-fill { width: min(calc(var(--up,0) * 1%), 100%); transition: width 1.9s cubic-bezier(.22,.61,.18,1); }
.runner.you { left: min(calc(var(--up,0) * 1%), calc(100% - 26px)); transition: left 1.9s; }

Set the variable to 0 in markup, then to the target in a double requestAnimationFrame so the transition actually fires:

requestAnimationFrame(() => requestAnimationFrame(() => {
  fill.style.setProperty('--up', pct);
  you.style.setProperty('--up', pct);
  pro.style.setProperty('--p', 100);
}));

No signup, no tracking, all client-side. The whole thing is one HTML file. Runner figures are inline SVG (SF Symbols are licensed to Apple platforms only, so they are not legal on the web, which trips people up).

It is a toy, but it is the kind of toy runners screenshot and argue about. Curious what percentage you land at.

How race time predictors actually work: Daniels VDOT vs Riegel, with the JavaScript

Dor — Mon, 01 Jun 2026 10:52:20 +0000

Every race time predictor on the internet is doing one of two things. It is either fitting a power law to your result (Pete Riegel, 1981) or running you through a physiology model (Jack Daniels and Jimmy Gilbert, 1979). I implemented both in plain JavaScript for a running app I work on, so here is how they actually work, with the code.

Method 1: Riegel's power law

Riegel was a mechanical engineer and a competitive runner. In 1981 he fit a simple relationship to world-record performances: finish time scales with distance raised to a small power above 1.

// T2 = T1 * (D2 / D1) ^ 1.06
function riegel(d1, t1, d2) {
  return t1 * Math.pow(d2 / d1, 1.06);
}

// 20:00 5K -> predicted 10K
riegel(5000, 20 * 60, 10000); // ~2497s = 41:37

The exponent 1.06 captures the fact that you cannot hold a pace forever. Double the distance and time slightly more than doubles. It needs no physiology and almost no input. The weakness is that 1.06 was fit to world records, so it flatters amateur marathon predictions.

Method 2: Daniels and Gilbert's VDOT model

Two years earlier, Daniels and Gilbert went through physiology instead of around it. Two equations. The first is the oxygen cost of running at a velocity v in metres per minute:

function vo2(v) {
  return -4.60 + 0.182258 * v + 0.000104 * v * v;
}

The second is the fraction of VO2max you can sustain for a race lasting t minutes:

function pctMax(t) {
  return 0.8 + 0.1894393 * Math.exp(-0.012778 * t)
            + 0.2989558 * Math.exp(-0.1932605 * t);
}

From a race you derive a fitness score, VDOT, then solve for the time at a new distance where oxygen demand matches what you can sustain:

function vdotFromRace(d, t) {           // d metres, t seconds
  const tMin = t / 60, v = d / tMin;
  return vo2(v) / pctMax(tMin);
}

function timeForDistance(d, vdot) {     // bisection on duration
  let lo = 1, hi = 600;
  for (let i = 0; i < 100; i++) {
    const mid = (lo + hi) / 2;
    const implied = vo2(d / mid) / pctMax(mid);
    if (implied > vdot) lo = mid; else hi = mid;
  }
  return (lo + hi) / 2 * 60;
}

They mostly agree, until the marathon

For trained runners predicting between nearby distances, the two methods land within a percent or two of each other. The marathon is where both break down. Vickers and Vertosick (2016) studied recreational runners and found real marathon times ran about 4 to 5 percent slower than the prediction, with much wider scatter.

The reason is not the math. A 5K tests your aerobic ceiling. A marathon tests fat oxidation, glycogen, fluid replacement, heat tolerance, and pacing discipline, none of which a 5K loads. A predictor tells you what is possible if you do the training. It does not tell you what you will run on an untrained marathon.

Showing both is the honest move

The practical takeaway I landed on: run both methods and show the spread. When they agree, trust it. When they diverge by more than a couple percent, that gap is itself information about how far you are extrapolating.

I put both behind a race time predictor and a set of goal-time pace charts if you want to see the outputs without wiring up the code. References for anyone going deeper: Riegel (1981), American Scientist; Daniels and Gilbert (1979), Oxygen Power; Vickers and Vertosick (2016), BMC Sports Science.

I built an on-device marathon coach for iPhone and Apple Watch (no account, no server)

Dor — Mon, 01 Jun 2026 10:51:27 +0000

For a while now I have been building a running app called Smart Runner, and the whole thing is a bet against how the category usually works. No subscription. No account. No server. Everything lives on the phone. Here is why, and the parts that were actually hard.

The bet

Most serious running apps are subscriptions, and your training history sits on their servers. If you stop paying, you lose access to years of your own runs. If the company gets acquired or shuts a feature, your data goes with it.

I wanted the opposite. Pay once, and the data never leaves your device. The app reads from Apple Health and writes to local storage. There is no Smart Runner backend to leak, sell, or sunset.

The stack

SwiftUI + SwiftData for everything local. No backend at all.
HealthKit for reading workouts, heart rate samples, and writing structured workouts back.
WatchConnectivity to push the planned workout to the Apple Watch and pull the result back.
A native watchOS app that plays the workout back with live pace and HR zones.

The part that bit me

WatchConnectivity plus SwiftData is where I lost the most time. I was handing SwiftData model objects to the off-thread send, and the model context would get touched off its own thread and corrupt state. Intermittent, ugly, hard to reproduce.

The fix was to snapshot the planned workout into plain value types (a dictionary of [String: Any]) on the main context before the background send, so nothing model-bound ever crosses a thread boundary:

// Wrong: passing the SwiftData model into the off-thread send
session.transferUserInfo(encode(plannedWorkout))

// Right: snapshot to value types on-context first, then send
let snapshot = plannedWorkout.asTransferDictionary()   // [String: Any], no model refs
DispatchQueue.global().async {
    session.transferUserInfo(snapshot)
}

Obvious in hindsight. Most concurrency bugs are.

The training engine

The coaching side is built on published running science rather than a black box:

VDOT for pace zones, from Daniels and Gilbert's 1979 oxygen-cost model. One race result gives you Easy, Marathon, Threshold, Interval, and Repetition paces.
ATL / CTL / TSB training-load tracking, the same acute-versus-chronic load model endurance coaches use, so the plan knows when you are fresh, fit, or cooked.
The plan recalculates after every run instead of being a fixed 16 week PDF.

If you want the math, there is a free VDOT calculator that exposes the numbers.

Why on-device at all

Three reasons that turned out to matter more than I expected:

Your training history should outlive any subscription. Pay once, keep it forever.
There is no account step, so onboarding is just opening the app.
No server means no server bills, which is part of how the pay-once model even works.

The trade-off is real: no web dashboard, no cross-platform sync beyond Apple Health, iPhone and Apple Watch only. For the runner who wants a private, owned training tool, that trade is the point.

If you want to see it, it is here: Smart Runner. Happy to get into the watch sync or the training-load math in the comments.