71–76 of 76 posts
By the author of the library > This was achieved through showing Claude Code and Codex the browsers ground truth, and have them measure & iterate against those at every significant container width, running over weeks https://x.com/_chenglou/status/2037715226838343871?s=20 There was another comment about using Autoresearch probably for this but I might be misremembering
Earlier quoted context omitted.
What you're missing is that each segment (typically a word) only needs to be measured once, in the setup phase. The canvas gets thrown away after that, and subsequent layout passes all reuse the cached measurements. If you only perform layout once, it doesn't save any work. If you need to reflow many times, it saves a lot.
Are you sure the browser doesn't similarly cache it's own layout calculations?
This thing isn't trying to do standard text layout faster than the browser, it's trying to enable more exotic/dynamic/custom layouts while keeping reasonable performance. Take a look at the demos linked in the repo's readme; those are things which the browser's layout engine can't do on its own.
Has someone ever found a good solution for long / infinite lists / grids virtualization not breaking browsers native text search? Maybe for this we need a new web "Search" API instead of JS. Not sure it can be done otherwise without browser's help.
https://wicg.github.io/virtual-scroller/#find-in-page-apis As far as I can tell, this went basically nowhere. Except this: https://github.com/WICG/display-locking https://developer.mozilla.org/en-US/docs/Web/API/Element/bef...