Chartd: responsive, retina-compatible charts with just an img tag | Hacker News Reader

Chartd: responsive, retina-compatible charts with just an img tag

chartd.co

67 pointsingve16 comments

A few folks were asking about open-source alternatives. I've found Quarz's Chartbuilder is really nice, though not able to throw-parameters-in-a-URL which is a super handy feature.

Use: https://quartz.github.io/Chartbuilder/ Source: https://github.com/quartz/Chartbuilder/

Chartd looks super awesome for a variety of use cases though, especially if you've got regularly updated data you want to visualize.

if Google has taught us anything, it is that this is a bad idea. Sooner or later this service will shut down as it has no business model taking your app with it. It should be available as open source to deploy if you need to do so in the future.

Oh. I assumed this was open source and you host it on your own server. Yes, not a good idea to use a free hosted product provided by a company where you're using the service anonymously over the Internet.

It's funny that you mention Google. Google used to offer a web-based chart API a lot like this one. Well, it looks like they're technically still offering it as Image Charts [1] but it is deprecated. I think it used to be called just Google Charts, but that brand was repurposed to a client-side JavaScript library. I'd say it's virtually certain that they pull the plug on it at some point, given Alphabet and the whole "era of fiscal responsibility".

I've actually written a clone of Google Chart API for private use. It relies on ChartDirector though which isn't free; it's basically a URL skin over that product. If this would be useful open source to anyone I could see if my company is willing to agree to release it. However I had sort of assumed that web-based charting APIs were dead by this point in favor of client-side ones.

Edit: Is this a paid API? StatHat looks like something that's a paid service but I can't tell if the feature in the article is paid.

[1] https://developers.google.com/chart/image/docs/making_charts

At the very top of the page. I thought it was already gone.

"Warning: This API is deprecated. Please use the actively maintained Google Charts API instead. See our deprecation policy for details."

Disclaimer up front; party in back: I'm about to discuss a freemium service that I built & operate related to this :)

I looked around for a solution like this for a while last year while building a new weekly email for Ramen[1]. I tried a bunch of services but ran up against a bunch of issues mentioned in this thread:

- GET query string character limit

- Stress around unreliability of free alternatives

- Need to be able to handle large spikes of image generation when sending emails

So I ended up building a service and turning it into a freemium product: ChartURL.com[2]

It is:

- Free for low usage w/ branding

- Based on C3.js[3] (for major flexibility)

- Supports datamaps.github.io[4]

- Has an API whereby you can POST huge datasets and get back a short URL that can be used in an img tag

- Supports retina & `srcset` via a `retina=1` option

You need to sign the URLs which means it's not a simple "just drop the data in the URL" but it's close.

I'll hang out in the comments here for a while if any of you want to ask questions about it.

[1] https://ramen.is

[2] https://charturl.com

[3] http://c3js.org/reference.html

[4] http://datamaps.github.io

First, despite the reservations expressed by others so far, I think it's a good thing that something like this exists; it's a big shame that Google abandoned their own equivalent.

Having said that, I would be surprised if there weren't good open-source alternatives (anyone?); maybe the problem is that server-side requirements might get a bit awkward, even if you can find a good solution in the language of your choice.

> All chartd charts look great on retina displays. The SVG charts are vectors and render perfectly. chartd generates all the PNGs @2x the resolution so they scale appropriately.

Is this why when I view an image directly [1] it's twice the size of the requested dimensions? I'm viewing this on a 'retina' screen, in case that affects things. Is this the best way of handling retina displays, to make everyone else's image 4 times bigger than it needs to be, and scaling it in-browser?

[1] e.g. http://chartd.co/a.svg?w=580&h=180&d0=SRWfaZHLHEDABKKTUYgpqq...

It's a bit stale, but I've used Eastwood in the past as an open source substitute for Google Charts

http://www.jfree.org/eastwood/

Plotly is now open source and is amazing. https://plot.ly/

One shortcoming: these requests are always HTTP GETs, and various web browsers/servers/proxies will impose different limits on the length of the request. In the best case, it looks like you're going to get 8k requests, and if you're dividing that up among multiple timeseries, it's not a _whole_ lot of data points.

You'll also end up needing to do a length check client side, since the degradation is probably not graceful as you approach the request limit (fine, fine, fine, fine, fine, HTTP 414).

That's probably fine for a lot of use cases, but if you adopt this charting library / system and then later want to do more complicated things with it, you're going to end up needing to rip it out and replace it with something else that doesn't have this limitation.

I don't see a way around it, you can't make the browser POST to get the img tags AFAIK.

'get' to a shorter url which has more of the params you want which POSTs, then passes through the img data back? might be more trouble than it's worth?

I agree with the previous comments about a project like this not being open source isn't a great idea. Hard to monetize on GETs and anyone who invests a lot of time developing to the url's API will have to redo their app when you deprecate your service, as google did with the chart API.

Still, having it as a hosted service doing image charts can be great, you just need to give folks a backup plan.

To show responsiveness, it would be better to place the "don't care about responsive?" in a separate page...

Wrapping on the <pre> tags is broken. You need to specify white-space: pre-wrap;

Hi, I'm the author of chartd.co. Let me know if you have any questions!

I don't see pricing info. Will this be free forever?

The revenue from StatHat supports it.

Reply on news.ycombinator.com