How I Built a Fair Name Spinner (and Why Math.random() Is Good Enough for Your Classroom)

#javascript #tutorial #webdev

Every classroom has the same problem: "who answers?" If the teacher picks, students audit the teacher's preferences within a week. If students volunteer, the same three hands rule the room.

The fix I wanted was a spinner wheel — but with three constraints that most "wheel of names" tools get wrong:

Zero sign-up. Teachers won't create an account mid-lesson.
Zero upload. A class roster is minor data. It should never touch a server.
Visible fairness. The class watches the selection, so the selection has to be actually random, not shuffled-looking.

I built it as a single static page — vanilla JS, one canvas, no framework — and shipped it at randomstudentpicker.online. Here's the part that matters if you're building something similar.

The shuffle: Fisher–Yates, nothing else

Randomness in a picker usually happens twice: picking one name from N, and (for "no repeats" rounds) dealing names out in order. Both are just one algorithm done right: the Fisher–Yates shuffle.

function shuffle(arr) {
  for (let i = arr.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [arr[i], arr[j]] = [arr[j], arr[i]];
  }
  return arr;
}

Two properties make this "fair" in the way classrooms need:

Every permutation is equally likely — no position bias, no "the first name gets a head start."
It's in-place and O(n) — a 200-student roster shuffles in under a millisecond.

The tempting wrong version is arr.sort(() => Math.random() - 0.5). It looks identical in a demo and is not uniform — the comparator-based sort skews toward certain orderings depending on the engine's sort implementation. If your wheel "feels" rigged after a few rounds, this is usually why.

Is Math.random() actually random enough?

Honest answer: it's a PRNG, not a CSPRNG. Its seed is predictable if you know the algorithm, and the sequence is deterministic.

Does that matter here? Think about the threat model. A "rigged classroom wheel" requires someone to (a) know the seed, (b) predict the next ~30 outputs, and (c) care enough to exploit it during a 5th-grade reading circle. None of those are realistic. The fairness that matters in a classroom is procedural and visible — equal slice per name, in front of the class — not cryptographic.

If you're building a raffle with real money attached, use crypto.getRandomValues(). For a classroom, Math.random() is the right tool: fast, everywhere, and statistically indistinguishable for human-scale draws.

The wheel geometry

Fairness on screen comes down to one thing: equal arc angles. For N names, each slice gets exactly 2π / N radians:

const slice = (Math.PI * 2) / names.length;
// draw arc i from i*slice + rotation to (i+1)*slice + rotation

The spin animation is just easing toward a final rotation, where the final angle is chosen so the pointer lands on the pre-shuffled winner. The wheel is theater; the shuffle decided the result. That separation — decide first, animate second — is what keeps the animation smooth and the outcome honest. Don't read the winner off the animation.

The privacy design

The whole page is static. The roster lives in a <textarea> and in localStorage on the teacher's machine — that "remembers your class" feature people ask for is just localStorage, nothing else. There's no backend, no analytics on the roster field, and no "improve your experience" checkbox hiding a data pipeline.

For minor data, the architecture is the policy: it's impossible to leak what you never receive.

What I'd do differently

The canvas rendering could move to requestAnimationFrame-driven state (it's a bit chatty during long rosters).
A "weighted" mode would be a mistake — the moment you allow weighting, you re-introduce the teacher's bias. I've deliberately left it out.
The 10-language versions were an afterthought that turned out to be the highest-ROI feature: the Spanish and Hindi pages rank in markets the English-only competitors never looked at.

If you're building classroom tools: keep the roster local, make the randomness procedural and visible, and never ship a sign-up wall in front of a 30-second task.

Try the result: randomstudentpicker.online — group generator, seating chart, and raffle tools are on the same site, same architecture.

DEV Community