I'm Luke, the builder of SpinWheelNames. My app uses SvelteKit and an HTML5 canvas, with the stopping position decided in the browser using crypto.getRandomValues. Here are the boundaries I find useful when thinking about that implementation, the test that exercises it, and the separate presentation needed for a stream overlay.

1. Distinguish the application boundary from the drawing boundary

There are two separate architectural questions: where the application runs, and how the wheel gets drawn.

My SvelteKit configuration uses @sveltejs/adapter-node. That does not mean a Node server chooses the winner: the wheel's random stopping position is decided client-side. Deployment and selection are different responsibilities.

Likewise, using Svelte does not mean every animated shape needs to be a DOM element. The wheel itself is drawn on a canvas; the surrounding interface lets people enter names, customise colours and change options.

For me, that is a useful division of labour. Svelte is a fit for an interface that changes with user input, while the browser's drawing surface handles the wheel graphics. Canvas is not a replacement for the application interface, and the framework does not need to replace the drawing API.

If I were reviewing another canvas-heavy app, I would start with those same questions: which work actually needs the server, which state belongs to the interface, and which work is just drawing?

2. Reason about stopping angles, not just random numbers

The random source matters, but it is only one part of the argument for fairness.

SpinWheelNames uses the browser's cryptographically secure crypto.getRandomValues, rather than Math.random, to choose the extra rotation. On a computer, the wheel makes between five and ten extra turns; on phones it makes fewer so the animation stays smooth. Wherever it stops, the entry beneath the pointer wins.

The important detail is that the random movement spans a whole number of revolutions. That means a uniform distribution over that span covers every stopping angle equally. It does not mean that each spin adds only an integer number of turns: that would keep returning the wheel to the same orientation.

This gives a geometric way to describe the result:

• With equal-sized slices, each entry occupies the same fraction of the wheel and has the same chance.
• With weighted entries, the slice sizes change in proportion to the weights, and the chances follow those sizes.

For example, three equal slices each cover one third of the circle. If their weights are instead 1, 1 and 2, their shares are one quarter, one quarter and one half. The larger chance should be visible in the geometry, not hidden behind a wheel that still looks equally divided.

The engineering lesson is to check both the source of randomness and its mapping to the visible outcome. A strong random source alone cannot demonstrate that the angle-to-entry calculation is correct.

3. Exercise the selection path without waiting for animations

My in-browser fairness test runs 100,000 spins using the same code the real wheel uses to choose the turns and read the slice beneath the pointer. It does not animate them, and every visit runs a fresh test rather than displaying precomputed results.

One detail matters here: each trial starts where the previous spin stopped. Resetting the wheel to a fixed orientation for every trial would test a different sequence from normal repeated use.

The test uses ten equal entries. After 100,000 spins, the expected count for each is 10,000, but exactly equal counts are not the goal. Randomness naturally produces differences.

The chi-squared calculation summarises those differences:

χ² = Σ ((observed count − expected count)² / expected count)

For ten entries, the test has nine degrees of freedom. The p-value describes how often a fair wheel would produce counts at least as uneven as the observed counts.

A p-value above 0.05 means the test found no evidence of bias at that threshold. It does not prove the implementation is flawless. Below 0.05 is a reason to investigate, not a verdict by itself: even a fair wheel produces such a result in roughly one test out of twenty.

I would rerun an unexpectedly low result and inspect the counts rather than treating one pass or failure as certification. Repeated tests are useful evidence, but no finite random test guarantees that every biased implementation will fail every run.

There is also a boundary to this particular test: it checks equal-entry frequencies, not deliberately weighted configurations. A weighted test needs expected counts based on the weights, not an assumption that every entry should win equally often.

4. Treat the overlay as a different presentation surface

A wheel on a normal page and a wheel inside a broadcast scene have different constraints. Capturing a browser tab brings along page furniture that does not belong on stream.

My OBS overlay builder produces a separate URL for a transparent 1920×1080 presentation. The setup is:

1. Enter the names in the builder and copy the generated URL.
2. Add a Browser source in OBS and paste the URL.
3. Set the source to 1920×1080.
4. Open the source's Interact window, then click Spin or press Space.

That interaction boundary is deliberate: chat can supply entrants through the streamer's usual bot, but there is no built-in chat command that lets viewers trigger spins. Collecting entries and authorising the draw are separate jobs.

Real transparency is the default for OBS and Streamlabs Browser sources. For capture setups that cannot preserve it, the builder also offers green or magenta backgrounds for chroma keying. Magenta is useful when green slices would otherwise disappear under a green key.

For several prizes, Remove the winner after each spin removes each selected entry before the next round. Refreshing the Browser source restores the entries. That changes the list between draws, so it is a different process from repeatedly sampling an unchanged list.

The overlay is free, requires no account, and shows no ads or branding on stream. That is specific to the overlay: regular site pages carry Google AdSense ads.

What I would check in another interactive picker

These are the questions I would take into a review:

• Does the probability model match the visible slice sizes?
• Does the test exercise the same selection logic and starting-state behaviour as ordinary use?
• Are statistical results described as evidence rather than proof?
• Are weighted draws and removal between rounds treated as distinct cases?
• Is the output surface designed for where people actually display it?

SvelteKit and canvas cover different parts of this problem. The useful result is not just a wheel that moves smoothly, but a selection process I can explain, exercise without animation, and present without confusing the controls with the output.