[jimrandomh]

This article says that using `transform` is faster than using `left` and `top` because `transform` is handled on-GPU, while `left` and `top` are not. This is a myth. I tried the demo page in the Firefox profiler; neither the optimized nor the unoptimized version missed frames. I tried it in the Chrome profiler; the unoptimized version missed frames, but the time was clearly labelled by the profiler as being GPU time, not reflow. Neither browser did reflows (or, all reflows were fast enough to not have any profiler-samples associated.)

The reality is that browsers contain large piles of heuristic optimizations which defy simple explanation. You simply have to profile and experiment, every time, separately.

[b_e_n_t_o_n]

Yep. At one point it was probably the case that it always caused reflows but browsers have had so much investment into optimizations that it probably realizes those layout changes don't require reflows and skips them.

[pharrington]

Moving an absolutely positioned element never caused a reflow, by design. The AI slop is just wrong.

[luciodale]

Thanks for the input! Indeed, the reflows were incredibly fast because I was using position: absolute, which meant the squares were not affecting anything else in the dom, but just their position (so cheap operation). I will add a note on the article on that... also I am improving the 'bad' example so the shuffle button triggers reflow in a significant way.

[tux3]

Same experience here. Both consumed a lot of CPU, but they looked very similar on the perf graph, and neither missed any frames.

[MountDoom]

This article is almost certainly AI-generated.