My path planning simulator lets someone draw obstacles on a grid, place a start and a goal, and compare three planners. The first thing it needed was not a nicer animation. It was a limit.
An interactive planner is an open invitation
Anyone can draw any map. Without limits, a large enough grid or an awkward enough obstacle layout turns a search into something that freezes the page or ties up the server. So the simulator caps the size of the grid, the number of obstacles and the number of steps a search may take. A request that would exceed them is refused or stopped, with a clear result.
Three planners, the same measurements
A* uses an estimate of the remaining distance to steer the search toward the goal. Dijkstra expands outward by cost with no estimate, so it visits more of the map to reach the same answer. The sampling planner explores by picking random points, which gives a path that is usually valid and rarely the shortest.
Each run reports the same things: path cost, cells visited, running time and whether it succeeded. The animation is drawn from those results. It is not the only way to judge what happened.
Logic separate from the screen
The planners are plain functions with no knowledge of the interface. That is what makes them testable. The tests cover known shortest paths, maps where no path exists, invalid input and what happens when a step limit is reached.
The browser runs its own copy of the planners so the demo responds instantly, and the same logic is available from a small API.
Why the limits come first
A demo that can be made to hang by a hostile map teaches the wrong lesson about planning. On a real robot, a planner that cannot be bounded cannot be trusted to return in time.