4 ms·
Using a non-proprietary platform also has the distinct advantage of supporting whatever APIs you want to use and not having to deal with extracts of data. Havin
by sailfast 7y ago
Using a non-proprietary platform also has the distinct advantage of supporting whatever APIs you want to use and not having to deal with extracts of data. Having to wait for one of these platforms to support JSON from a web URL is really quite silly when you could write the query quickly (in python or whatever) and pass the values to your view.
Or, you know, use PyGal or another server-side charting library:
http://www.pygal.org/en/stable/ http://www.pygal.org/en/stable/
- inferiorhuman 7y agoOr, you know, use PyGal or another server-side charting library: http://www.pygal.org/en/stable/ http://www.pygal.org/en/stable/ Is there much of a market for server-side rendering? I've been putzing around with a d3-inspired charting library in Rust mostly as a brain teaser though.
- dreamcompiler 7y agoI very much prefer to generate svg charts on the server. Not only is this more sensible when you have a huge number of data points, but it even works with js turned off (unless you need interactivity).
- sings 7y agoNot disagreeing – I do this often too – but the downside can be having a very large dataset which in turn generates a very large response, which might be more efficiently sent as data and constructed client-side. Less importantly, Google’s lighthouse tests for a certain number of DOM elements, which a complex chart can easily exceed.
- inferiorhuman 7y agoYeah my server-side use cases are for times when I'd want to use a graph outside of a browser (e.g. PDF reports, printing, email distribution). If you're targeting a browser IMO it only makes sense to move away from the browser and/or JS if you're trying to create a static, raster image.