RUBIK'S CUBE
The cube, and three ways to solve it
A 3×3 cube in 3D you can turn in the browser: scramble it, play with it, and when you give up watch it close. Not with one solution but three — the beginner method, the CFOP of people who go fast, and the optimal algorithm — shown move by move, forwards and backwards, with the name of the stage you are in. Free, no sign-up, all on your own device.
Drag outside the cube to turn the view. Moves come from the buttons or the keyboard: lower case = clockwise, upper case = anticlockwise.
How to use it
«Scramble» applies twenty random moves, the way it is done at a competition. From there you can turn the faces by hand — with the buttons under the cube, or from the keyboard with U R F D L B and the three middle slices M E S. Lower case turns clockwise, upper case anticlockwise.
Press any of the three solvers and the list of moves appears. You can step through it with the arrows, go back, or let it run on its own with «Auto». Above the list you always see which stage you are in: that one line is what turns a string of letters into something you can learn from.
The three solvers
Beginner — the layer method
The one taught to people starting out: cross on the bottom, first layer corners, second layer edges, then the last layer in four steps. About a hundred and fifty moves: a lot, but every stage has a name, and watching it go past really does teach the method. It is written by hand inside the page and comes from no library.
CFOP — the one for going fast
The Fridrich method, the speedcubing standard: cross, F2L (first two layers together), OLL (orient the last layer), PLL (permute the last layer). About sixty-six moves, less than half the layer method. The four stages are shown separately, and the OLL and PLL cases going past are the same ones in the trainer.
Optimal — the two-phase algorithm
Kociemba's algorithm: around twenty moves, often twenty-two. No stage names, no readable logic — it is a search through a state space, not a human method. The first run takes about a second to build its tables, and it builds them in a separate thread so the page never freezes.
Frequently asked questions
Do the solutions always work?
Yes, and it is measured: 1200 cubes scrambled with twenty moves, solved by all three methods, with each solution re-applied to the starting state to check the cube really closed. 1200 out of 1200 for each. On top of that, before showing you a solution the page re-checks it against your own cube: if it would not close, it tells you instead of letting you follow it.
How many moves does each method take?
On the same 1200 cubes: layer method 149 moves median, CFOP 66, optimal algorithm 22. That is the whole difference — the layer method fixes one piece at a time, CFOP fixes two together, and the optimal algorithm fixes nothing and looks for the shortest road.
Can I turn the cube to see the back?
Yes: drag outside the cube and the view rotates. Moves stay tied to the cube's own faces, not to how you are looking at it, so U is always the yellow face even if you have spun it round the back.
Is the cube saved?
Yes, the state of the cube stays in the browser's local storage: close the tab and you find it scrambled exactly as it was. It never leaves your device.
Does it use external libraries?
Two, for two of the three solvers: cubejs for the optimal solution and rubiks-cube-solver for CFOP, both MIT. They are hosted on this domain, not on a CDN: your browser contacts no third-party server. The layer method, the cube engine and the graphics are written here.
Does it need a graphics card or WebGL?
No. The cube is built from CSS 3D transforms, twenty-seven little cubes and nothing more: it runs on any recent phone without touching WebGL.
How it is built
The part I cared about was not the graphics but the engine. Cube permutations are usually written as tables of 54 numbers copied out by hand — and one wrong number gives you a cube that seems to work until you scramble it enough. Here the tables are not written: they are computed from the geometry. Every facelet knows its position and its normal; a move is a 90° rotation of those two vectors, and the permutation falls out on its own. No digit left to get wrong.
The same principle governs the checking: the animation is not «roughly right», it is verified against the permutation. If a colour ends up on one side while the cubie turns the other way, the test catches it. That is the difference between a cube that looks fine and one that is.
Then there is the dull, honest part: two of the three solutions come from outside, so they get tested the way you test something you do not trust. CFOP, for instance, occasionally emits an odd notation — MPRIME2 for a half turn of a middle slice — and anyone who lets it through loses the move and ends up with a cube that will not close, once in four hundred. That turned up because every solution is re-applied and re-checked, not because it was written down anywhere.
It is the same way of working I use on real products: Miraviso is a concrete case, and if you need a hand with something similar this is where to start.