Your comments reads in bad taste. Maybe be more constructive?

Can you please try it again? the issue was not related with the component itself https://zzarcon.github.io/react-circle

let me know if you still experience that issue

If you turn off animation it's snappy.

I'd recommend either killing that altogether as it definitely gives the perception of bad performance.

Or... at least take into account the delta of the progress change when doing animation. For instance, if going from 5 to 10%... a slower animation is fine. If going from 0 to 100%, the animation should be much quicker.

The performance is still bad. It's spending roughly 20ms doing JS work per frame.

React profiles are not very easy to interpret but perhaps you're doing a lot more work per frame than you should be?

Here's the profile: https://perfht.ml/2F7ohwx

This file is the entire source of the component: https://github.com/zzarcon/react-circle/blob/57bb4d19df08b73...

A lot of the work seems to be the React diffing? The only thing that changes between frames when dragging the slider is the style attribute.

Furthermore, the author seems to have included the development version of React. And the author used development settings for the webpack compilation. The compiled JS is full of eval() calls.

It might be slightly better, but still far from performance I would expect from that component

https://gfycat.com/TerribleWeeArmadillo

Is this Edge? I can confirm poor performance in Edge, but every other browse I've looked at seems to be ok.

Interesting... will have a deeper look into it, if you have any idea on how to make it better you are welcome

> low latency Java

(Does not compute)

Sure it doesnt ;)

The think that myth is coming from the fact that JVM is heavy (150MB?), so it takes time to start, and hot-spot needs some iterations on a source code before it can fully apply JIT, but other that that, Java is really good.

Given there's only a single svg element changing I'm not exactly sure you could have done it better.

It might just be that the ease-out transitions for the stroke are not efficiently implemented in whatever browser you're using.

If you've tried and check out and understand the code you'd see there's so little being done in JS that this stuff is surely not the bottleneck.

Use a canvas and render the component directly? You’re rendering a circular progress bar, that should be easily doable in microseconds if not nanoseconds. There’s no need to use the overly bloated DOM for everything.

I suggest taking a look at Android’s views or even Flutter.

But there's only 3-4 DOM elements. I'm pretty sure doing this in canvas is not as trivial as this.

Of course it’s not as trivial. But you can control the animation much better, and you can have much better performance.

Yeah, more than likely the only problematic part is the transition animation. The main problem was another component breaking the performance in the examples page, not the component itself. Should be fixed now :)