Demo: traveltron.replit.app
Github code: https://github.com/shehuphd/traveltron
Most examples of “quantum randomness” are boring. They usually stop at a coin flip, a dice roll, or a number between 0 and 1. These are technically correct, but conceptually flat. I wanted to explore a slightly more human idea: choosing where to travel next.
The inspiration was the old idea of throwing a dart at a world map and going wherever it lands. That act is appealing because it embraces chance, removes overthinking, and introduces surprise. TravelTron tries to recreate that feeling, but with actual quantum-simulated randomness instead of a classical random number generator.
The result is a small web app that spins a globe, waits for a “measurement,” and then reveals a country, its capital, and its currency.
What TravelTron does
At a high level, TravelTron does four things:
- Visually presents uncertainty using a spinning 3D globe
- Accepts soft preferences (north/south, hot/cold) without becoming deterministic
- Uses quantum simulation to generate randomness
- Reveals the outcome only after the “measurement” completes
The globe spins first, and only once the spin finishes does the app commit to a result and reveal it.
Why not a coin flip?
A coin flip collapses to two outcomes. Travel decisions don’t.
A world map gives you hundreds of possible outcomes, unevenly distributed, with geography, climate, and hemispheres baked in. That makes it a better mental model for probabilistic systems.
Using a globe also helps people intuitively accept bias without determinism. You can “nudge” the system toward warm places or the southern hemisphere, but you never force a specific result.
This mirrors how quantum systems behave: shifting probabilities without necessarily guaranteed outcomes.
The quantum part
The backend uses a quantum computing library in simulation mode. The approach is simple:
- Multiple qubits are placed into superposition using Hadamard gates
- A single-shot measurement is taken
- The resulting bitstring is converted into a floating-point value in the range [0, 1)
- That value is used to perform weighted sampling over the country list
There is no fallback to Math.random, random.random, or any classical pseudorandom source.
Bias without determinism
The hardest design constraint was allowing preferences without breaking randomness. TravelTron supports four toggles:
- North
- South
- Hot
- Cold
Opposites cannot be selected at the same time. Selecting North automatically deselects South, and the same applies to Hot and Cold. Internally, these toggles do not filter countries out. They only change weights.
If you select “South,” southern hemisphere countries become more likely, but northern countries are still possible. The same applies to climate.
I chose this approach because filtering would turn the system into a deterministic subset selector. Weighting preserves uncertainty.
The globe
The globe is built with Three.js. The key design choices were:
- A textured sphere using an equirectangular Earth map
- A subtle wireframe overlay to keep a “computational” feel
- A 23.4° axial tilt to mirror Earth’s real orientation
- A slow idle rotation, with faster rotation during “measurement”
Two poles extend from the globe, cheekily labeled |0⟩ and |1⟩, representing the north and south poles.
Technical constraints and trade-offs
The backend is a small FastAPI app. The frontend is plain HTML, CSS, and JavaScript. The globe is the only visually complex component. This kept the app cheap to run, easy to understand, and easy to modify.
- No React, Vue, or build system
- No server-side persistence
- No tracking or analytics
- No heavy physics or shaders
Several things broke along the way:
- SSL certificate issues when generating country data
- Python environment conflicts with quantum libraries
- Three.js coordinate mistakes that put the poles in the wrong place
- Browser caching masking visual changes
- Replit hosting throwing timeouts during spins
If I extend this, I might add…
- Real quantum hardware backends
- Region-based weighting instead of climate heuristics
- Animated “measurement collapse” effects
- Saving past spins to show distribution over time
But the core idea already works.
Final thought
If someone walks away from TravelTron understanding that randomness can be biased without being controlled, and that outcomes don’t exist until measurement, then I’ve succeeded.
Bonus points if they actually book a flight.
