`. And every new line is an appended `
`. It sounds like it wouldn't work, doesn't it? Any modern engine would freeze, as the expensiveness would be too much — much less changing the color or sorting those lines! [Google actually gives us a couple solutions to dealing with visual changes.](https://developers.google.com/web/fundamentals/performance/rendering/optimize-javascript-execution?ref=jahans.blog) In conjunction with [reducing paint complexity, you can solve scenarios like the one above.](https://developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas?ref=jahans.blog) I took it a step further. Let's take a look at a sample Google gives us for breaking large tasks into smaller, per frame availability.  Immediately when I saw this, I thought about divide-and-conquer algorithms and how this could be generalized for a class of problems *(with easing!)*. ## Quadratic problems. Applying this segmentation to algorithms of \\(\\mathcal{O}(n)\\) time is trivial. Let's take a look at quadratic, which initially may seem confusing. I took a look at bubble sort, being one of the sorts I know very well. Here's a [Codepen of it working](https://codepen.io/jahan-addison/full/ec1b1639f30524a8c7a1a9b0bde2fd2e/?ref=jahans.blog). *[(source code)](https://codepen.io/jahan-addison/pen/ec1b1639f30524a8c7a1a9b0bde2fd2e/?ref=jahans.blog#code-area)* > Although `swap` here is only swapping the height, the result is the same. It causes a repaint. Moreover, some element's height may be the same, causing the visual variation illusion. The code is beautifully straightforward. For \\(\\mathcal{O}(n^{2})\\) (and, by extension, \\(\\mathcal{O}(n^{3})\\)) segment the algorithm at the operation when enough time is available, here being `swap`, calling `requestAnimationFrame` at each 'depth'. It scales, and we can add easing or delay. This approach works for **ANY** `n` as it always runs the nth-depth operation when enough time on a frame is available. Mindblowing. ## Logarithmic problems. > →🦉 Next, I took a look at `quicksort`, also straightforward to implement. The generalization works for all logarithmic and combinatoric problems. [Codepen](https://codepen.io/jahan-addison/full/c3db864195c36f24ed1cd4bb10b7e92e/?ref=jahans.blog). *[(source code)](https://codepen.io/jahan-addison/pen/c3db864195c36f24ed1cd4bb10b7e92e?ref=jahans.blog)* > To demonstrate how powerful this method is, [here](https://codepen.io/jahan-addison/full/5e52921f961431e83d82bcee52709e7d/?ref=jahans.blog) is the `quicksort` **with** buffered segmentation. It does not complete, however, as pivot step atomicity is necessary. Cool. Alright, let's break this down. First off, we notice `quicksort` is async. The operation we segment is the partition, being the base operation for all recursive calls. Because we segment `partition` on available frames, we want it to take its time. So I await a `Promise` to the next `pivot` in the sort — thus scaling the algorithm for all `n`. The segmentation here isn't as fast as our quadratic solution. The atomicity of our `pivot` operation cant be buffered into a time frame. **But the algorithm does complete for all `n` smoothly**. > If there were many base-case operations, or 0th and 1st, we'd segment them together — scaling into recursion. ## Last remarks Some game-changing stuff here. I am completely confident I could build **very large** applications with close-to-native (if not fully native) speed. The research mentioned above has removed many problems regarding DOM applications at scale. If you have questions or thoughts send me a message [on Twitter](https://twitter.com/%5Fjahan%5F?ref=jahans.blog). — Jahan