Chartist – Simple responsive charts | Hacker News Reader

Chartist – Simple responsive charts

gionkunz.github.io

194 pointsjcklnruns49 comments

Looks very pretty, but doesn't seem to offer hover states or actions / tooltips. I think this is a dealbreaker for a lot of users who wish to add contextual information to their charts.

When I think responsive it's in a mobile first paradigm. There is no hover on mobile.

There is no hover on mobile, but in this context, touch/press works as an analog for hover. In other words, you want more information/detail on a particular data point, on desktop you hover, on mobile you press.

which is essentially on click. You don't want the details to only show up while your big fat index finger is in the way.

True, but "mobile first" is not "mobile only". The point of responsive design is for things to work well on multiple platforms, not just one.

correct. So why not use a multi-platform interaction like on click?

Because hover saves user two clicks (one to access a tooltip, another to dismiss it) and desktop users are already familiar with additional information displayed on hover.

If a hover tooltip has a clickable content then yes, using on click to lock the tooltip in place is a good idea. For example, hover navigation with subcategories can be awkward to use and on click navigation is a better choice here. But for a simple caption in an interactive chart it would be an overkill on desktops.

Agreed. There is no mention of it in the "Important missing stuff", although their Getting Stated page does finish with

ADDING BEHAVIOR TO YOUR CHARTS

Coming soon...

Hopefully that means enabling chart interaction. Of course, by the time they add in the basic functionality which make data visualization useful, they'll have just repro'd ChartJs, HighCharts, or any of those other libraries.

Was thinking the same thing. Especially with financial charts, it saves a lot of time eyeballing and guessing. Sure, you can look at the data source for the raw values, but I'd rather just hover my mouse over the points.

XSLT can create client-side charts without JavaScript. For example:

http://davidjarvis.ca/world-politics/xml/resources.xml

The source code is hosted on BitBucket:

https://bitbucket.org/djarvis/world-politics/src/master/xml/

Without JavaScript, the interactivity of the charts is limited.

XSLT is kind of like complex regexs, it's a write-only language. I've written a few XSLT transformations over the years for various things and every single time without fail I realize at the end it was a huge mistake.

Also most data is in CSV or similar delimited format and won't be usable with XSLT.

Are people still adopting XSLT for new projects? It seems it has fallen out of favor.

I use XML/XSLT to transform data into multiple output formats (currently XHTML and ConTeXT/PDF):

https://recipefiddle.com/recipe/15316/truffles (web page)

http://i.imgur.com/T71WhDJ.png (editor)

https://recipefiddle.com/book/examples/recipefiddle_sweet_tr... (printable ebook)

https://recipefiddle.com/book/examples/recipefiddle_sweet_tr... (recipe cards)

Each recipe was created from the same XML recipe data, transformed using two different templates. To my knowledge, JSON cannot be directly transformed into *TeX, but XML can.

To achieve the similar results with JSON, you'd have to first transform it to YAML, then Pandoc, then LaTeX, then finally PDF. Then you'd have to use a different infrastructure to render JSON as XHTML.

Architecturally, in this case, XML/XSLT is the simpler solution. If you only care about mobile apps, and don't need to create beautiful ebooks, then XML/XSLT is not a good choice.

If you have a hammer everything looks like a nail. Or in this case if you already have XML then XSL looks like the solution.

I suspect XSL has fallen out of favor because a lot of people don't have XML anymore, they instead have JSON which is more naturally processed using a JS library (per the OP).

In order to process JSON with XSL you'd have to go through the rigmarole of first converting it to XML and then exporting that as an iFrame which can then be rendered into HTML/CSS/JS via XSL. And nobody has got time for all of that, least of all when we care about creating "mobile first" properties which XLS was just never designed for (and, yes, the underlying HTML/CSS which it outputs CAN be designed for mobile-first, but XSL itself offers no functionality there).

TL;DR: I'd never go XSL in 2014 unless I already had XML. It offers little or nothing if your data source is either straight from the database or JSON (just adds an additional intermediate layer, you'll still ultimately outputting to JS/HTML/CSS). It does remain useful for generating CSV however (as you can set the output encoding type to text, strip XML headers, and so on). Which is not true for JavaScript.

As somebody who has worked a lot with many javascript charting libraries over the years, one important lesson we have learned is to "never roll your own charting library" and accept the feature set of the library. Too much customization will lead you down a windy path that can lead to nowhere. Pick your library first and keep that library's limitations in mind during the design process to save yourself a world of hurt

This library looks to appease a lot of the design customization so far though, great job and kudos to the author for what looks like a really good start.

Sounds like a nice business opportunity: a chart library that is as easy to use as it is to customize.

Looks great. I use Highcharts.js responsively by simply setting the chart width to % rather than pixels. After all, scalable is a key part of SVG.

Noting that Chartist is much leaner than Highcharts, how do you envision differntiating this project and avoid feature creep to make it like Highcharts.js 2.0?

good question

Given that this doesn't work on Android 2.* stock browser (and I assume IE8), it would be good to see some kind of fallback - preferably canvas and if that's not supported then a table of the raw data, which would be better than the current blank space.

I bet that not supporting those are intended. I don't get why there is always this need to support old tech. Can't we not just move forward?

I don't get why there is always this need to ignore old tech, despite so many people around the world still relying on it, likely not by choice. In the case of Android, 14% of users are still on 2.3.* or less [1]. Sure, library developers are free to ignore them but it restricts how widely their code is likely to be deployed. It's not about not moving forward, it's about providing fallbacks.

[1] https://developer.android.com/about/dashboards/

Both my android devices run 2.3 and I'm using highcharts without problems on both. Which is why I won't probably be using this.

Why? You're like one of those people who still uses Windows XP. Spend $100 and get a device that runs something released in the last SIX years.

But 2.3 (Gingerbread) was released in December 2010, so his device indeed runs something released in the last six years.

In an ideal world (for software and hardware vendors, at least) we would be replacing devices with their latest versions as soon as they come out and backward compatibility wouldn't be a problem. However, I can imagine a situation where spending $100 on a new phone is a luxury and not everyone can afford it. If a phone makes calls, sends text messages, and connects to the Internet, it's still usable.

You're right about the release date. Not sure why I thought 2008.

Like XP, Gingerbread has unpatched security vulnerabilities. Having a mobile phone with up-to-date security is well worth spending $99 (for a Moto G, for example).

I get that not everyone can afford something like that, but it's like car insurance. You absolutely can't afford to have your identity stolen.

I think it's more like an old car versus a new car. Having a new one is a better choice since it has more features, it's safer, it's more fuel-efficient, it pollutes less. Yet there are consumers who consciously choose older cars because in their mind lower price outweighs potential benefits of a new car.

I agree that having your identity stolen is something you cannot afford. But then again we are both frequenting Hacker News so we are aware of how technology works and how damaging compromised security can be. An average user however might not realize that an outdated Android version has unpatched vulnerabilities. They are just happy that they can send Snapchat messages to their friends and can watch Youtube videos when they are waiting for a bus.

Also, how long before Moto G stops being supported with updates and becomes vulnerable as well? What should happen next?

Very pretty, but doesn't seem to be able to match the functionality of dygraphs, or the number of chart types in the google chart library (or similar).

I will definitely keep an eye on this project though.

I rarely have a need to display static charts. My common use when I reach for a chart is to display live streaming data. Usually doing so involves accessing a points list directly and managing the addition/deletion/updating myself.

Is there any chart system that is made with live updating in mind?

Yes, rickshaw.js: http://code.shutterstock.com/rickshaw/

And it's built on top of d3, so the possibilities for customization are almost limitless (as another commenter has said).

http://fastly.github.io/epoch/ is built for real-time streaming data. It also uses d3

This website is using SVG graphics, very nicely. Is there a tool (GUI) that does that? Is it an export from a program like Illustrator, or is there something easier --and cheaper-- to do this?

XaraXtreme - http://www.xaraxtreme.org/

InkScape - http://www.inkscape.org/en/

Karbon - https://userbase.kde.org/Karbon

Thank you.

Inkscape is a nice open source SVG editor.

Why prefer this over Chart.js [1] which is responsive as well?

[1] https://github.com/nnnick/Chart.js/

I've run into some serious performance issues with chart.js on Firefox with moderately sized datasets.

SVG in general falls over with very large datasets, I find html canvas based libraries such as maybe Flot better for thousands upon thousands of datapoints. I love d3 as much as anyone and all of it's offspring, but SVG is too slow in most browsers (especially Firefox) for lots of datapoints.

It is interesting that you cannot copy SVG out of your browser. When I visit the page in Chrome, mouse over the graph and "copy," it doesn't copy either the BMP buffer OR the raw SVG (XML).

I was going to try and copy/paste into Outlook, but that's obviously no-go if you cannot copy at all. Interesting limitation of SVG that I wasn't aware existed until now.

Yet another bonus of canvas, something vaguely akin to:

var canvas = document.getElementById("canvasElement");

var image = canvas.toDataURL("image/png");

document.write('<img src="' + img + '">');

It sounds like you're looking for the SVG Crowbar: http://nytimes.github.io/svg-crowbar/

To be fair, that's not an intrinsic limitation so much as a browser implementation limitation.

File a bug report?

Chart.js is not being actively developed or patched. Dealbreaker.

how so? the last commit was 10 days ago.

Ok, something is happening now. But as you can see from the graph[1], nothing was really happening for a long time.

I was following several issues that the author wasn't even responding to, even though many people were asking after it. Around 25% of the issues are a year old, and many more are 8+ months old.

Finally, someone made a fork of the project with a lot of the requests that people were making. A "people's fork" wouldn't have been created if it were sufficiently active.

[1] https://github.com/nnnick/Chart.js/graphs/contributors

Looks interesting - does this library do animation of states from old to new (e.g. adding new data) in the same vein as, for example, c3.js?

Can I send these charts as images in emails? Google Charts is killing that features and we use it at work. SendGrid does the same thing.

It's generating SVG charts, which would probably work, but it uses JS to generate them, which certainly won't.

If you pre-generated them with something like node.js, you might be able to.

Are bar value labels supported?

labelInterpolationFnc? Really? :P

Looks cool though.

Reply on news.ycombinator.com