|
|
|
|
|
by eyelidlessness
437 days ago
|
|
SVG complexity is a good counterpoint to “why this instead of SVG”. But I don’t think we need to even address the claim that most tools for SVG generation use JS, if the concern is JS on the client. Realistically, on a scale beyond very few graphs, it’s pretty likely some sort of software is going to be used to process data into markup. At which point, if the desired result is static markup, it doesn’t really matter (to the end user) whether that software is written in JS or some other language. That’s a toolchain concern. It probably doesn’t matter much if at all (to the end user) whether the resulting markup is HTML or SVG. There may be some imperceptible performance difference, or slightly different accessibility requirements. But neither requires users to run JS. If I were evaluating this choice, it would almost certainly come down to what’s most familiar, or what most readily integrates with other parts of the project’s stack and/or data sources. And I could easily imagine even that evaluation being a wash. |
|
If you want to address the generation of charts on the client, then, yes, JS is something that needs to be addressed, because SVG (or Canvas) are not in and of themselves systems for generating charts. There isn't a <PieChart> primitive within the SVG spec, to my knowledge.
The entire purpose of this library seems to be generating charts in pure markup without any scripting language dependencies. Trying to pretend that isn't relevant, or suggesting that "SVG" is, in and of itself, a viable substitute is just really weird.