I’m the developer of Transitions DJ (https://dj.app/). If anyone can connect me with the team at Apple Music, I would be interested in doing an integration.
On the M1 Mac I actually measured lower CPU usage during audio playback on WASM compared to the native desktop version which uses Rosetta. I'm not sure if the slowness is due to Rosetta or a performance bug on the Mac port.
It is rendering using the 2D canvas API. There's a device context class (wxDC) for each wxWidgets port that implements primitive drawing ops (DrawLine, DrawText, etc). For the WASM port, I created a glue library in javascript [1] that wxDC calls into for each primitive.
I originally developed a WASM port of wxWidgets for https://dj.app/. When it came time to open source wxWidgets-wasm, I decided to port another complex app as a test case, and Audacity seemed like the obvious choice. In the process, I also needed to write a new host API for PortAudio for playback and recording in the browser.
I believe they are using a non-standard crossover operator in this implementation. A standard crossover operator will generate some permutation of the genes of the two parents: either you inherit the gene from your mother or your father. This implementation creates a new gene that is a weighted average of the genes of the two parents. This will probably cause rapid convergence of the gene pool, which may or may not be intended. Changing Math.random() to Math.round(Math.random()) in crossVars would change this to the standard crossover operator. I'd be interested to see how this affects performance.
I would target people who are not completely satisfied with the competitor's product. If I see people tweeting competitors asking for feature X, where my product already has X, I will send them a message.
I haven’t tried a Bloom filter, but I think for my application, the simple bit array might give better performance. The nice thing about the bit array is it works great on the worst-case. After the user has typed in 3 or 4 characters of their query, the search space has been narrowed enough where the performance isn't an issue. It’s that first or second character when the search space is large that gives problems. Using the bit array in the single character case, the 1 to 1 mapping of characters to bits gives the result directly.
I recently used this algorithm for speeding up an iTunes style search function. Originally I did a strstr over every item in the database, but it wasn't quite fast enough. I precomputed a 32-bit mask - 1 bit per alphabetic char, 5 bits per digits, and the last bit for special characters - for every database item, and used that as an initial search filter. I only needed to use the more costly strstr on items that made it through this filter.