Big screen on wall with 6 or so boxes. Each box displaying data which updates in real time. Such as
- scrolling list of source control commits
- graph of busy/idle slaves
- single big number, pending builds
- graph of open ticket counts
- etc
I can't tell if this is one of Pyxley's use cases? - https://github.com/allegro/tipboard
- http://tipboard.readthedocs.org/What Shiny does to get around this is natively 'evaluate' the plots on the backend, creating a rasterized PNG file. A similar approach could work for Pyxley (using matplotlib or Seaborn to render the plot, and then sending that image file to the front end) but I fear with so much development time spent on d3 support such an approach would not be natively implemented.
I don't think that's the case for D3 charts, because that would kill the interactivity that is so great about D3. I use RCharts to inject D3 into my Shiny applications, and have ran into into performance issues with just a couple hundred data points. I think this is because all heavy lifting is done by the client (browser), not the server.
A continuous heat map over two dimensions, at 500x500 pixels, is 250,000 pixels. Of course, to generate the heat map, you have to aggregate (binning on two dimensions), but you don't have to downsample.
My guess is that with Python being a more general purpose language, this should be easier..
Of course, most of these issues are understandable and possibly by design, especially since OpenCPU was designed for embedded systems. That's fine - it just makes creating webapps or dashboards around R a more complicated usecase.
Not sure I understand? Are you talking about Kenneth Reitz's requests module? Why would that tie you to Flask or any other framework or library?
If you have the original source in an interpreted language, it supports your ARM raspberry pi or chromebook just as well. With the C variation you need to build / package / install.
I've kinda just come to accept that code re-use cross language has never been good except with the unix pipe.
So to run this there's code that needs to be compiled anyway.
So no, R is not ahead in everything.