But it isn't wrong, is it? Democracy elected Hitler, Hitler ended democracy in Germany. I'm not saying that is going to happen here, but your flippant comeback to a valid point is not a rebuttal.
No - CSS and JavaScript are two ways of defining the same thing, an animation. Safari runs its accelerated animations with CoreAnimation - is CoreAnimation a CSS animation?
The UK has been described as an Eastern European economy with London bolted on. Poverty is very obviously increasing there, for anyone familiar with the country.
Most CSS animations aren't hardware accelerated. Only a few values like opacity and transform.
Updating the DOM (as in innerHTML) is always expensive because it triggers layout. This is true whether you're doing it from JS or a CSS trick like on this page.
Finally this approach is using CSS custom properties. These are slow - slower than JS for most things.
If you stop all animations on this page and profile it via Chrome you can see this in effect. The root node is animating a CSS variable. 117 elements have their style recalculated. Every frame - yet no animations are running. There's also a tiny paint triggered too, obviously there's been no changes so it is tiny in this instance, but a paint is always triggered when a CSS variable updates.
This is why animating x and y separately via CSS and a style like `translate(var(--x) var(--y))` would be worse than animating them via JS ala Framer Motion/GSAP.
If that's the book I'm thinking of I was also initially impressed until like chapter 6 when, after spending the book talking about how simple and elegant this theory was, it opens with "what if there wasn't just one string but lots of strings, and they were n-dimensional etc etc..." and threw it all out the window. I put the book down.
Not really - watches are historically round because of roundrel clock faces. A square is a better form factor for literally everything else that an Apple Watch does. So it is the Apple move to shape the watch to perform best at 95% of its tasks, and a Google move to shape the watch to perform best with a subset of available watch faces.
This isn't even new. Casio etc have designed digital square watches for decades because they don't need to be round without clock arms.
They might carry on improving the quality for the Pro (although this also has limits and diminishing returns) but they don't need to do that if they're targeting a sub $1000 headset, they just need to make these screens cheaper.
Yes and no - IE was hated in part for deviating from standard/showing weird behaviour. But more than that it was dragging its feet on implementing new CSS and JS standards so they couldn't be used for years after introduction. It was nightmare.
Your intuition is correct - there's nothing to indicate any delay.
Look at your profiler. Notice any significant overhead? You don't.
Implement this same thing using events and `.style` directly. You will get the exact same result.
The pointerEvent => style feedback loop is unfortunately very slow, more or less so in different browsers/operating systems.
Interesting that you would know so little about this and yet feel confident enough to make a proclamation like this is evidence of React's performance.
> It seems the US and allies no longer just wants UA to hold their own against RU, but actually win the war
There is no "hold their own". This would be a state of perpetual warfare. The only way to end the war is to allow Russia to claim Ukraine or push Russia out of Ukraine. Personally I would rather the Russian border to be as far east as possible.
I have the opposite problem recently where a very common class of spam (usually "you have won") just slips straight into my inbox no matter how many times I flag it. It looks so obviously like spam it's quite shocking it doesn't get picked up.
This is a home-grown solution but the version in Framer is extensively tested (though still not perfect ofc).
The version in Framer has stuff like infinitely deep scale correction and shared element transitions so because of the filesize overhead (~10kb) I would only use this for complex stuff that is otherwise prohibitively tough (shared element transitions, layout etc).
However I do want to make the point that this approach should be more robust and simpler to maintain for even simple examples.
If you imagine an iOS-style pill toggle. The "simplest" way to animate this would be to have `translateX(0)` when off and something like `translateX(100px)` when on.
However, if there were no animations, this isn't how you'd write it. You'd probably do something like switch `flex-start` to `flex-end` on the parent.
This is easier to change the design and also maintain between breakpoints. But it can't be animated. Except with these technique, where you'd simply write
Additionally to the sibling comment, we do expose a secret API that can be used to fix distortion on other properties.
To take border from your example, in the Framer app we add correction that fixes border. But border is tricky because it only renders rounded values and triggers layout - exactly what we're trying to avoid. I always recommend a two element approach, one with an inset. More performant and visually nicer.
We also use this API to do more advanced stuff like this <LayoutCamera /> component for React Three Fiber/Framer Motion 3D. https://www.framer.com/docs/layoutcamera/
This camera renders the scene pre-distorted so when the layout transform is applied, everything looks correct.