Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

Nice, but its a re-implementation of the Google Chartserver right? (same model, URL describes charts which are returned)

The issues Google ran into were as it gets popular you need a more server horse power, and the work of keeping things secure is pretty high.

That said I always enjoyed using chartserver :-) so I presume I would enjoy using this. But what I'd really like is a package for python or perl I could load up behind an nginx instance and make this a local feature.

View on HN

I work for the team that maintains Chartserver. It's being deprecated for a number of reasons, none of which you've listed. Mostly, we feel the service has been replaced by JS charting solutions (Google Charts, d3, etc.) which are more flexible and don't have the privacy concerns of Chartserver. Most importantly, the team that developed it has moved on to other work and it hasn't been restaffed.

We revisit the deprecation of Chartserver every couple of months (I believe it's had two stays of execution), so there might be some life left in that old code.

I've done a ton of work with Chartserver, and I'm continually impressed by how elegant it is in every detail of its implementation. Although, I'm also a huge fan of D3. Not every chart should be built in JavaScript. I can embed it, I can drop it in an email, I can serve up 20 charts on a page in milliseconds, and I can do it equally quickly anywhere in the world.

Services like this, are one of the things that keeps up 'Google's not just in it for the money' cred, I'm going to be really sorry to see it go.

It's not dead yet.

> Most importantly, the team that developed it has moved on to other work and it hasn't been restaffed.

Isn't that right there an example, or warning, or admonition, or something, suggesting that you not use external services for essential features? I know that no page is likely to last more than five years, but there are going to be many pages that outlast services like this.

Or am I missing the target use case?

I'm not quite sure what you mean by "no page is likely to last more than five years," because a large portion of the Web is composed of pages that, once posted, remain indefinitely. If your site is one of them, you wouldn't want to depend on an external source for your charts, or your archived pages could be broken by a third party--which seems to be your (very good) point, so I'm a bit confused by your wording.

I'm assuming that a page has a life, I picked five years. The implication being if your page isn't going to last long, it's not that big a deal if you rely on an external resource. But if you're one of the few (or the many) that are going to last longer than the expected life of one of these ephemeral services, you shouldn't rely on it. That's as opposed to paying for the services of, say, an established, paid and hopefully long lived CDN or similar.

Also the look is brilliant, especially with the current trends in flat design. I so infrequently see it used to it's full potential.

Check out: http://smashrun.com/chris.lukic/overview It uses both D3 and ChartServer, but there's no way I'll ever get the page load to something comparable using only d3.

When is it depreciated exactly. Says 2015, but is that going to be January, or December? (I need to replace them in my app at work).

https://developers.google.com/chart/terms

Again, Chartserver has had a number of stays of execution. Officially, we're killing it in 2015, but it would surprise me. Usage numbers just haven't been what you would expect from a deprecated product.

I don't think Google Chartserver offered SVG, though, did it?

I think that's a significant difference, in that the <object> variant of this API has the potential for access to the chart elements for styling and interactivity.

Well Chartserver did offer SVG at one point, although at the time SVG was (and kinda still is) under supported in the browser space AFAICT.

Having recently rediscovered the non-joy of putting somebody else's javascript on a page (in that case WebRing) I am a bit gun shy of the whole model[0].

I really like the idea of 'server driven charts' for easy web pages and illustration. But I would rather have it be something I could put on an Raspberry Pi in my network so that I didn't have to worry either about the privacy issues or it going away (as Chartserver has been trying to do :-).

[0] Imagine what will happen if placekitten.com gets sold to some porn aggregator.

That's an interesting comment - we're building a SaaS 'point and click' style D3-based chart designer (http://chartblocks.com) but hadn't really given much thought so far to people that prefer to self host.

But that way you are throwing away the only benefit - that it works without javascript. It's really expensive to draw graphs and it's better to be offloaded to clients.

I can't think of many reasons for building them serverwise.. except for when you don't have access to javascript or you are limited by the power as well.

I disagree, as even if you did use Javascript the service is still far more accessible to a novice developer than something like the d3.js library (which I love, but has a rather steep learning curve).

Additionally, you would be surprised at how much could be accomplished in that department with just CSS.

That's a limitation of d3.js, not JavaScript. gRaphaël is pretty easy to use: http://g.raphaeljs.com/

Reply on news.ycombinator.com