The culmination of such an approach is realized in the Beaker Notebook (http://www.beakernotebook.com). You can not only switch between languages, but the environment allows you to share datasets between Groovy, Python, JS, Julia, Ruby etc ..
It's a work in progress, but something to watch out for, imho
Well this is what iPython is morphing into. iPython is going kernel agnostic and you can actually use dozens of languages already. Juypter is the new name.
Since the post linked to my ggplot2 tutorial, I should probably mention that I'm really not a fan of interactive charts/D3 for static content, because a) loading the data can dramatically increase the loading time of the webpage and b) interactive charts will break on mobile devices, so you need to invest time to QA that.
Somewhat close in spirit to what seems like a never-ending side project I have: https://dl.dropboxusercontent.com/u/7702253/AlthingiJS-1.mov Here I show Javascript and APL, but the plan is to eventually include at the very least also R. But so far I'm still rewriting what I have until I'm happy with it, so it's taking ages.
That's cool, but... code or it didn't happen. Are you running an APL interpreter client-side or shuttling the code and data back to the server? If it's the latter, are you sandboxing in some way the arbitrary code being executed?
Yes, that's the thing. At the current point it is usable (barely) as an APL/javascript REPL, but there are several corners that are very rough, not counting unhandled data structures and such. Every time I have some spare time with some clear mind I work a little on it, so it's not stalled, but has been going for quite a few months already without much improvement.
As for your question, data goes back to the "server" (there's go code interacting with the APL interpreter and sanitising inputs and outputs, converting to JSON, etc) but this is expected to be used as a local service (using a port not listening to the outside world), so no, no arbitrary code execution failsafes (if I were to deploy it in some real, server-ed way I'd isolate interpreters via sessions in the go 'middle' layer).
R is a very powerful tool, but I fail to see how it's adding value in this case. It seems like the author is advocating just using R to clean up the data and put it in JSON. The same can be done (without overhead for context switching and server-client architecture) in JS itself. Tools like Crossfilter [0] can be seamlessly integrated with D3.
2) Use R to turn the raw data into analytically data
3) Use R to do exploratory charting etc
[Most project stop here]
4) Final Product: RMarkdown (For static reports), Shiny (Interactive variable charts), or now D3 if I want to have interactive charts. My interactive charts would be very few.
I wouldn't want to do the first three steps with javascript.
I think the strongest use case for interfacing R with JS (be it through plot.ly, Shiny, rCharts etc) is when there is more serious statistical modelling going on (i.e. plotting things like credible intervals or model coefficients). But often you find that you add a 'statistical layer' after you already have an existing plot (i.e. adding a confidence band to a line plot). Maybe it makes sense to have one tool that handles all these cases.
I have been using ggvis for a little while. It is very flexible in terms of changing variables for exploratory use. (My favorite personal use). I haven't done much with Shiny yet but I think D3 is more in lines with RStudio's html widgets. http://rmarkdown.rstudio.com/developer_html_widgets.html
It's a work in progress, but something to watch out for, imho