Opacity and affine transformations cover most animations that people want, though certainly not all. SVG is also generally more amenable to GPU powering. (And if they’d catch up with Firefox’s WebRender, then even more would be done on the GPU.)

Beyond that, though, you’re underestimating what browsers are capable of. You’ll certainly hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank), but it’s not hard to drive layout-affecting animations at 144Hz provided you careful about isolating the affected areas. The “don’t touch layout, animate transformations” narrative that got pushed hard some years back was much more about mobile than desktop—desktop can be more efficient with transformations, but even layout-based animations will generally be smooth on desktop platforms. (In the past, Firefox struggled more than Chrome on those sorts of things, but WebRender has helped to completely reverse that.)

As an absolutely toy pathological example, on my admittedly powerful laptop (Ryzen 5800HS, using integrated GPU) in Chromium (since we’re talking Electron and not WebRender), moving a series of ten inline-block 80px emojis by setting their margin-left to random layout-dependent values every frame (so that’s ten forced relayouts per frame, and quadratic layout behaviour) tends in profiling to take around 3–4ms, occasionally spiking briefly just above the 6ms budget my 165Hz display gives and causing jank (… not that I can tell visually with the emoji flickering all over the place anyway, but the profiler tells me!). For comparison, just one emoji (dodging the quadratic stuff) tends to take around 1ms, showing that a lot of the costs here are constant. URL for the code:

  data:text/html;charset=utf-8,<style>body{overflow:hidden}div{display:inline-block;left:0;position:relative;font-size:5em}</style><div>%F0%9F%99%82</div><div>%F0%9F%99%81</div><div>%F0%9F%A4%A8</div><div>%F0%9F%98%AE</div><div>%F0%9F%98%9B</div><div>%F0%9F%98%80</div><div>%F0%9F%98%86</div><div>%F0%9F%98%A2</div><div>%F0%9F%98%95</div><div>%F0%9F%98%92</div><script>function f(){document.querySelectorAll('div').forEach(e=>e.style.marginLeft=Math.random()*(innerWidth-e.offsetWidth-e.offsetLeft*0.1)+'px');requestAnimationFrame(f)}requestAnimationFrame(f)</script>

> it’s not hard to drive layout-affecting animations at 144Hz provided

And you've literally written how hard it is: "hit limits much sooner, and it’ll be more sensitive to other system load (thus more prone to jank)" and then you couldn't reliably animate 10 emojis. Ten. Ten. And you call animating ten emojis a pathological case.

I’m calling it a pathological case because it’s forcing style recalculation and layout ten times per frame, and that there’s a quadratic path in the layout involved, being done ten levels deep. Neither of these are realistic: an even vaguely sensible approach will not force style recalculation or layout during the callback at all, and trigger no quadratic layout path. Also in cases where you do need to animate something that’s part of the layout (not particularly common, by the way), it’s decidedly rare to want to animate more than one or perhaps two such element at a time—ten is massive overkill for the sort of thing we’re talking about (general-purpose desktop software). And alternatives to the web are normally not actually going to be better—the web has had an insane amount of effort put into making something not particularly amenable to good performance faster than it has any right to be, so that it tends to be able to outperform the theoretically potentially superior, even if it sometimes requires some care to achieve that. (By this, I mean to intimate the vague idea that by using a browser you’re not painting yourself into a corner where it’s simply impossible to get good performance without rewriting from the ground up, which is absolutely a problem with mainstream desktop GUI frameworks.)

Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case) or forced recalculations (as you should be doing) and you’re back down to mostly just over 1ms. A hundred elements is then normally 2.5–3ms, with occasional brief spikes of 6–7ms (the spikes at this point are larger proportionally to the baseline than in the pathological ten case). And to remind you, this is for animating a comparatively large number of decent-sized independent elements in the most expensive way possible. It’s significantly more complex than a realistic UI animation test, though certainly a far cry from what is possible in something designed for the purpose, or even Firefox thanks to WebRender: it’s still comfortably hitting over 100fps at a thousand of these emoji, including all this layout recalculation—change a non-layout property instead and it can go way further. (Meanwhile, I try pasting my thousand-element 23KB data: URI into Chromium, and it completely locks up, and killing the process is my only recourse.)

> I’m calling it a pathological case because it’s forcing style recalculation and layout ten times per frame

It's only pathological because the web makes it pathological. Phones routinely do complex layout animations that are unimaginable on the web. And yet, "we're doing layout calculations on ten emojis, it's pathological" is the norm on the web.

> t’s decidedly rare to want to animate more than one or perhaps two such element at a time

Yes. It's rare on the web. Because the web is unbelievably inefficient and slow when it comes to any animations beyond a very limited subset.

> And alternatives to the web are normally not actually going to be better—the web has had an insane amount of effort put into making something not particularly amenable to good performance

I have no idea where this verifiably false mindset comes from. Anyone you ask is "yes, the web is very performant, you can't do better, the alternatives can't be better". And yet you use apps, and frameworks, and approaches that are magnitudes faster, more performant, and create significantly more complex interactions and layouts than the web could ever hope to achieve.

Yes. I'm talking about your phone. I'm talking about your desktop. Right now my iPhone screen with two notifications displays more animations, at a smoother framerate than your "pathological example".

The supercomputers in our pockets and on our desks can output this: https://www.youtube.com/watch?v=EFyWEMe27Dw And yet, "it's rare to animate more than two things, other cases are pathological, I doubt anything else can perform better". You're talking about performance available to 1984 Macintosh https://www.youtube.com/watch?v=2B-XwPjn9YY

> Anyway, take my ten emoji example and reduce it to no layout dependencies (the usual case)

Ah yes. The usual case. That's why it's still impossible to animate height: auto, or an item being removed from a list without complex hacks because on the web everything simple is hard beyond all reasoning, and everything hard is impossible.