The size of the React and Victory libraries in the demo is close to 800 KB. How can this be reduced? For instance, it took ~12 seconds to render the chart with network and CPU throttling.
No, because there’s a limit on the amount of JavaScript code that low-end devices can process before the user experiences significant delays, and that limit is pretty low. Most of us westerners don’t own these low-end devices, so it’s not easy to test.
I replaced ChartJS with Victory on a recent project for charting investment performance, and was generally very pleased with the experience.
The focus on composable components fits well with the React way of working, and enables easy customisation (which was one of the main reasons for moving away from ChartJS) - you can even directly add SVG elements inside your Victory chart components if you want custom graphical elements.
Another interesting result of the switch was that the rendering quality of the vector (SVG) charts rendered by Victory was a lot nicer than the raster (Canvas) ones rendered by ChartJS, and it particularly fared much better at rendering smooth interpolation curves for a chart with a fairly large amount of data which looked "bumpy" with ChartJS.
Overall I'd highly recommend giving Victory a go if you need charts which aren't too specialised but do require some customisation. It seems like some of the paid-for solutions such as Highcharts are probably still the best option if you require something more niche.
For basic charting I'd have to agree with you. D3 has some awesome utility functions (scales, SVG path generation, the entire geo side of things... ) but their method of binding to the DOM was always hard for folks to wrap their mind around. So replacing the confusing part with React/JSX has made a lot of visualization code MUCH cleaner.
Doing animations gets a little harder and I still haven't found a really nice way to do it. If anyone has any good suggestions I'm looking. I've done some stuff with React Motion but it was much harder than the equivalent d3.transition call.
For me, the problem with D3 is how low level it is. It gives you the underlying structure and calculations to do visualization, and that means you can do incredible things with it, but it's a long process. I felt like I was building things from first principles.
Most charting frameworks tend to have default configurations which demonstrate more features than necessary as an advertisement of their competence for potential users, who are likely to copy default configuration and also take demo charts as cues on what charts should look like. It isn't the only dynamic which causes charts to tend to have superfluous or untuned features but it has some effect.
You should let them know specifically what problems you ran into! I'm sure they'd be willing to improve their documentation, they just need to be given constructive criticism :)
I've used Victory and didn't run into any issues, but then my usecase was very similar to their examples.
We take the idea of a beta release super seriously, and so we want to make sure Victory is rock solid before we put the beta label on it. That said, Victory is already being used in production apps.
I'm not sure I understand this comment. The title says "ReactJS" library. Do you mean it isn't compatible with React Native? Or did you really expect it to be compatible with Angular and other libraries?
There is a React Native version of Victory that reuses a lot of the same code base with different render targets (react-native-svg components). The api is identical. Check it out: https://github.com/FormidableLabs/victory-native
