Chartist: Simple Responsive Charts in SVG | Hacker News Reader

Chartist: Simple Responsive Charts in SVG

github.com

67 pointshomarp14 comments

For a library producing visuals, the README.md doesn't seem to show a single chart example. Instead you have to click links which load codesandbox.io pages for which you have to wait until the code is executed and rendered. Suggestion: include pre-rendered images directly in the click-to-open sections, next to the codesandbox.io links.

The author went through the effort of creating a marketing site with documentation and examples.

https://gionkunz.github.io/chartist-js/

This is becoming quite common - the projects need to make sure to reference it because people are still linking to the direct repository.

EDIT: but that marketing site is for the 0.11 version, you have to find the expandable >Examples inside the readme...

It is referenced. It’s at the very top of their GitHub repo under “About”.

I wish the author all the best in developing his library; at the moment it seems quite incomplete, so if you want SVG charts today, I recommend Observable Plot[1] or Vega-Lite[2]

[1]: https://github.com/observablehq/plot

[2]: https://vega.github.io/vega-lite/

Did you check the examples?

There is a massive list [1].

[1] https://github.com/chartist-js/chartist#examples

Yes I did, chart libraries have a very large surface to cover and that's not a massive list of examples, relative to what you will find for the libraries I mentioned

I did, it's still a bit short of the good stuff, but I do like the cut of his jib.

I second Vega for the really hard-to-source graph types like geo graphs and stats plots, even though Vega support on Kroki has been dodgy if I use the remote API. Not really Vega's fault there, aside from it being a little (understandably!) verbose.

> It's important to understand that one of the main intentions of Chartist is to rely on standards rather than providing it's own solution to a problem which is already solved by those standards.

This is a great intention. Let the browser solve the issues that already have solutions. Well done.

A great intention all else being equal. Unfortunately all else is not equal in this case. They say other libraries use "the wrong technology" (canvas). In my opinion this uses the wrong technology. SVG is much slower than canvas as soon as you have a few thousand points.

This might be fine for very small graphs but canvas is better in general.

I believe SVG and canvas both have strengths, and weaknesses, and should be used where it makes the most sense for each technology. When it comes to charts, SVG has an obvious benefit in that it comes with responsiveness built-in, and is far easier to style (and animate) via CSS. More importantly, but rarely mentioned, SVG is far more accessibility-friendly than the canvas element[1].

That said, I was also surprised by the assertion "use the wrong technologies for illustration (canvas)". It takes a lot more work, but canvas based charts can be made to be responsive, interactive and accessible[2][3].

[1] - CSS-tricks article on SVG and accessibility - https://css-tricks.com/accessible-svgs/

[2] - I outlined how someone could build a charting library based on my JS canvas library in a couple of lessons starting here - https://scrawl-v8.rikweb.org.uk/learn/eighth-lesson/

[3] - The final result from the above lessons can be seen here - https://codepen.io/kaliedarik/project/editor/AMVKPx - suggested improvements to the lessons, and the UX of the result, are always welcome.

I've been using Chartist for the last couple of years for line charts. The ability to style with CSS has been a useful benefit. For example, I have dark/light mode just by setting a class on the body element of the page and this flows throughout the site including the graphs with no extra effort.

I tend to agree. Canvas is a more direct route to leveraging the GPU.

I'm puzzled about why each axis label is in a <span> wrapped in a <foreignobject> instead of just a <text>. For the pie and donut examples I checked, <text> elements were used for their labels.

There's also a lot of unnecessary inline CSS.

Reply on news.ycombinator.com