Support multiple rendering engines

[synw]

It could be good to add support for multiple rendering engines. The plan is actually to replace Amcharts by Charts.js. We could take the opportunity of refactoring to implement it. This would make the module extensible and less tight to one library. There are a lot of great ones in javascript that we could benefit from.

I will implement this so that we can keep the actual working js library as default, work on the switch, and just change the defaults when it is done then we kick out Amcharts after that.

I am actually learning Bokeh which renders charts directly from python. It would work differently but has significant advantages: it generates chunks of html so that it is much less work in frontend maintenance and zero javascript fatigue. It can also produce png and svg images which can be nice as a lightweight alternative for embedded material: once generated they would be way much cheaper to serve and render than js and db hits.
This approach could match the case of using pre-agregated data that is in the proposal #10 as it always has to pregenerate the charts, on-demand would be too costly. I may later make a branch to see if it could fit in the mix, when I will be more comfy working with Bokeh.

[brylie]

Great idea! I like the sound of a common core module with extensions for specific charting libraries.

As a related aside, there is a really interesting talk from PyCon 2017 called The Python Visualization Landscape by Jake VanderPlas:

[brylie]

zero javascript fatigue

Woohoo!

[synw]

Okay I reorganized the templates folder and did small modifications in views to support multiple js rendering engines.

We can now add additional engines by creating folders in templates/chartlo and use the generic view with a engine = "chartjs" value to start developing with new libraries. This modification only affects the generic view for now

[synw]

A new branch has been created for server side rendering #16 where the charts are generated by python. It is efficient but can not replace the current approach as the charts are pregenerated: it can not chart streaming data for example.

[synw]

The Vega Lite rendering engine has been implemented in a branch #15

[synw]

To follow up on this: we now have Vega Lite by default. We still have to make a first implementation of another rendering engine to find the best design for this. I plan to research in two directions:

• For the javascript rendering engines: generate VL json files just as we now generate the html. These files can be used in templates by the js libs as data source. I'll implement the json generation quickly so that we can start working in this direction

• For Bokeh it is a special case: it has its own encoding and does not use VL. At some point I will try an implementation because their rendering engine is nice, providing interactivity on the charts. This is for later as Bokeh recently made some breaking changes so I'll concentrate on other tasks while waiting for the lib to be a little more stable

I think we can implement a per-chart rendering engine option: each chart could declare what rendering engine it wants