Pyxley: Python Powered Dashboards (opens in new tab)

And if the parent prefers doing it in python, there's pydashie [1], a python port of Dashing.

[1] https://github.com/evolvedlight/pydashie

Dashing is great, but it's Ruby on the backend, not Python :)

>What Shiny does to get around this is natively 'evaluate' the plots on the backend, creating a rasterized PNG file

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.

You actually do have a screen with 50k pixels. Many more than that.

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.

I've been working with it and it's not bad - won't tear my hair out if it's what I use in the end. But a couple pain points for me are the need to rewrite my code to grab 'session variables', needing to understand how images are returned, especially if you need to return more than one, and so on - versus Shiny, which allows me to more or less drop in the code I've already been working with. Oh, and parallel requests are just not possible.

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.

>The flask dependency is pretty strong because I used the requests module for the api route functions.

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?

Except tons of Python code depends on C. This project depends on Pandas. Pandas has C dependency.

So to run this there's code that needs to be compiled anyway.

haven't linux package managers (e.g. emerge, aptitude, yum, etc.) basically solved the packaging problem?

If GP comes from a more software-dev background, I can understand a general dislike for R. There's lots of things where R can't be beat right now, but for simple data analysis and visualization, there's some damn good python packages like pandas and d3py that GP may find easier to use than dataframes/tables and rCharts in R.

R has no native bayesian library like Pymc 3 (Must use stan which is c++). Also Python is better for ad hoc and agent based modeling and for out of core data with blaze and dask.

So no, R is not ahead in everything.