After implementing #15 there are still a ton of things make a faster solver. This is where it gets exciting because there are a lot of options open to us that would be very difficult with BurrTools. Here are some ideas:
TypedArray
WebGPU - The successor to WebGL, allows for general purpose GPU computations.
WebAssembly - Many directions this could go. Take a look at AssemblyScript, which can compile from a restricted subset of TypeScript. SIMD instructions are also possible in WebAssembly (see Feature Extensions).
Performance testing tool built in. See JS's performance API
Multithreaded solver
Parallelization of the Dancing Links Algorithm - In this paper, they simply implement the obvious method of splitting each row choice into tasks up to a certain depth (empirically determined). Their implementation is slightly different since they can take advantage of shared memory. They store nodes in a list and reference them by index instead of pointers (See Section VII) since they must copy the data structure (BurrTools stores nodes in one big flat list like this).
Bitwise operators (with dancing links probably) to solve cover problem
Distributed computing solver - This shouldn't be hard after multithreaded solving is implemented. Make a simple worker node that runs with node.js, then allow the user to enter the URL of as many worker nodes as they want.
Any other way to speed things up? GPU computing like node-rapids?
After implementing #15 there are still a ton of things make a faster solver. This is where it gets exciting because there are a lot of options open to us that would be very difficult with BurrTools. Here are some ideas:
reducemethod which simplifies the cover problem by eliminating rows. This is the "removed %i rows and %i columns" printout when running in the console. See: https://github.com/burr-tools/burr-tools/blob/master/src/lib/assembler_0.cpp#L1011