Show HN: Easy SVG charts for your static site, no JavaScript | Hacker News Reader

Show HN: Easy SVG charts for your static site, no JavaScript

chartspree.com

129 pointscolevscode39 comments

"no Javascript" is very misleading. There are several <script> tags embedded in each svg, including at least two scripts that are loaded from external sources.

In fact, nearly 1/3 of the data transferred for the first graph is javascript[0].

https://gist.github.com/hughes/c876b02aa06f897c99e2

Hm, how does this work? How can JavaScript be executed like that when it's included as an image?

Curious about that too. If I load an svg in the address bar with embedded script I can show alert(), but linked into html using <img> tag, alert does not run. Sandboxed? Otherwise I could execute JS just by loading in using svg via <img>.

Looks like it's not sandboxed at all?

> Any functions defined within any script element have a global scope across the entire current document.

[0] https://developer.mozilla.org/en-US/docs/Web/SVG/Element/scr...

As images / targets, SVG documents have their own global scope, much like a page in an iframe.

Is that just for fallback and also tooltips?

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.

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.

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/

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.

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.

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'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.

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.

> 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.

Not to nitpick or anything, but the first example on the site shows a bar chart with the example code being:

However the actual embedded code for the example and the resultant chart is:

My immediate reaction to seeing the wrong chart being displayed for some example code was that your system just didn't work properly.

As this is the first thing anyone sees when visiting the project, it might be a good thing to change.

One small thing is that the responses aren't consistent.

For example, sometimes this is funny, and sometimes it isn't, depending on which label is assigned to which color (seemingly random).

http://api.chartspree.com/pie.svg?Crips=35&Bloods=20

I agree it's odd that the order isn't consistent, but I don't get the joke which ever way it is, what am I missing?

The color of each gang is quite important.

Man, this brace.io gang is really making me happy. First formspree, now this. Making Middleman (et al.) sexy.

Edit: I guess Middleman isn't the only SSG :)

Nice! We just built a feature in our app using the deprecated chart service that Google offers. This looks like a much nicer implementation. But I lack a few things. Here are som ideas for improvement:

- Let me choose the colors

- Let me add or remove bullets on the line charts

- Let me control the axes

- Let me add a grid

Love it! Keep it up.

+1, Great idea and execution. Wondering, do these charts work well when used in emails?

Oh cool, I'll just send you all my data in the url params.

The first image on the page shows a series of data 1,1,2,3,5

but the chart shows the last bar going to six.

The URL makes it apparent that it's just a typo, but it's the literally the first thing on the page :)

http://api.chartspree.com/bar.svg?Foo=1,1,2,3,6&_height=250p...

This is a good idea. One thought for the team as you're building this: Is it possible to make an alternative version of the link that loads up the same graphic in JPG format?

I could see this going viral on sites like Pinterest or Tumblr, but I found that when I added this into Tumblr, it wouldn't save the post.

Has anyone looked at SVG frameworks like snapsvg[0]? After using d3.js for awhile, I like the idea of doing something more low level in terms of rendering and interacting with svgs.

0: http://snapsvg.io/

I used Snap for an animation on my homepage[0], though that was a relatively simple thing. My impressions of it were generally good, although there was a bug or two with version 0.1 that I was using that caused issues in some browsers, requiring me to move to the dev branch. I see they've released 0.2 now, which should have the fixes.

[0] http://kronopath.net/

The best tool I've ever seen. Thanks for providing this.

always on the look out for a replacement for google image charts api..... which remains super useful as long they continue to support it past EOL hehe

Why does it look like 5 = 6?

Didn't knew about pygal, what a fantastic chart framework.

Easy is my middle name.

I like it.

Reply on news.ycombinator.com