This is very interesting technology. The only concern is that it seems very slow. (justifiable, as it's generating a full plot each time which takes a bit even on my local machine)
See the full web page example [1]. It might be hard to scale a full website using the tech but it is useful in a pinch, especially if you already have a script to generate plots. (of which I personally have many)
It's true that Shiny isn't designed for blazing performance (it's built on R, after all) but the pensions app is particularly slow--I believe it's actually the calculations, not the plotting, that's so slow. It is also running on one of our free hosting accounts, that only allocates a single, single-threaded R process to service it; so you're competing with all the other visitors to that app for the attention of a single thread.
I'd encourage you and anyone else who might find Shiny useful to try it with your own data and your own scripts. You might be surprised at how decent the performance can be, especially once you've gotten your head around reactive programming and learn how to structure your code to take advantage of it.
That said, Shiny is definitely not designed to be a general purpose web development framework. It is specifically designed for R users to build single-page apps for analyzing and/or visualizing data. Rather than replacing Rails, it is aimed at replacing PDFs and LaTeX documents, which is the usual way R users pass their results around.
In the Shiny framework we think less about short-lived HTTP requests, and more about long-lived (websocket) sessions. Reactive expressions cache their results within or across sessions, depending on where they are declared (this is just a natural result of R's lexical scoping).
Joe Cheng and the rest of the team at RStudio have done an excellent job with this. It allows a statistician to spend their time on scripting the analysis instead of web development. Combine this with knitr/pandoc and you have a great toolkit.
Projects like this give me hope that the holy grail will soon be within reach: an iPython-like notebook that allows me to host both Python code, R-code, and possibly JavaScript in one complete package (maybe including Sage analysis, too).
And, when the data sets are small enough, I should be able to compile all of the interactivity features of the notebook into straight JavaScript with embedded data, so that it may be run on any generic web server, such as an internal corporate intranet server.
The IPython notebook can already mix Python and R code, and we're working on communications with Javascript running in the frontend, which would allow interactive widgets embedded in the notebook. Compiling the whole lot to Javascript isn't in our plans, though.
We've been working on an iPython-notebook-like system for R, called RCloud: http://github.com/cscheid/rcloud. It's not nearly as full-featured as you want, and still very heavily in development. Still, it does R-to-Javascript RPC (and back), allows you to develop and share your R scripts directly in a browser, and provides a rudimentary way of doing interactive Javascript plotting (so you can use write code that uses d3 to visualize R data, for example).
The issue is one of evaluation: I am prohibited from using the software at all, even on toy problems, to determine whether I'd like to buy a commercial license. Crazy, perhaps, but that's how hostile the AGPLv3 is to businesses.
This seems incorrect, unless you are prohibited purely by fiat (in which case it's a demonstration of how hostile your particular business is to the AGPLv3, not vice-versa). Requirements of GPL or AGPL licenses don't encumber you if you're not interacting with others (distributing software to them, or - with AGPL - providing a service).
Could you define what kind of toy problem that would be hindered by the license?
I could speculate. Maybe your company has patents covering RStudio software and wants to go suing its customers. That would indeed pose a problem with AGPLv3.
Maybe your company produces devices which have web servers in them, and those servers are going to host "toy" pages which uses Shiny, and the devices are locked down with DRM which prevent modification to Shiny. I guess it would be possible...
Or maybe the company does not want to ever give out code under any circumstances, regardless if it's a toy project with no inherent value to the company. This is clearly possible, which is why a dual licensing scheme sometimes is a good choice.
Gotcha. Well, I'm sure we can arrange an eval if you e-mail us.
Forgive us for not having these options on our website (yet), it took us a little bit by surprise that some companies might want the option to relicense.
For those interested in utilising the R language on the JVM (and thus relevant to web applications and thus to this post) there is the renjin [http://www.renjin.org] project which has been making steady progress implementing the complete functionality of R. For example they now claim that 'most' packages work with it, including many with C/Fortran dependencies.
I tried the online demo. A simple x <- rnorm(1000) was VERY slow (it took a couple of seconds). Any idea why? It did not seem to be initial-class-loading one-time issues; the slowness persisted upon retrying.
Shiny is really outstanding - I use it internally in our department to quickly make apps for biologists to explore their data while the downstream analysis is queued. It's also promising for its ability to very easily create a front-end to command-line R scripts and workflows.
Shiny is definitely a cool project! I wish I would've known about its existence before I started my own project along similar lines. Our requirements were slightly different, since most of the stuff we want to do is pretty long running (Monte Carlo Markov Chain, shameless plug: http://mcda.clinici.co / https://github.com/joelkuiper/patavi). But for a quick interactive system, it's really cool! And once matured a bit more we'll probably end up using it in production.
I wonder how to debug a web app in R. Rscript has the habit to tell you that there is an error, but not to tell you what file or line number. So debugging Rscript requires print statements to circle the problem. No something I enjoy to do, and certainly not something I want to for webdev.
It generally tells you the line number of the error, either in the web browser itself or in the R session that you're serving it from. I've never had a real problem with debugging the web app itself.
As for debugging the R code itself, options(error=traceback) is useful (though honestly usually unnecessary) as well.
Sorry for the shameless bump, but I thought some might find it interesting. I have had this idea in mind for over a year, and as a matter of fact myself and a couple of folks from Stanford have just started implementing it and we would certainly welcome any Python/JS devs who would like to contribute. It's a gevent/websocket-based Python backend with a shiny-like reactive computing engine with planned support for pandas as the primary data format; and an AngularJS-based frontend which allows for some crazy reactive/lazy evaluation not only on server side, but in the browser as well. Graphics-wise, we intend to create wrappers for matplotlib (which is pretty straightforward) along with some cool JS libraries like NVD3, Vega, sigma.js and other. The public repo will be on github in the next few weeks or so, please ping me on twitter @aldanor if interested.
I'm interested. Have been looking for an OSS project to work on and have been wanting to pick up some more JS experience. I will keep an eye out for that repo.
Their project is called Bokeh and it's available publicly on GitHub. There are some cool ideas there, however I wouldn't call it lightweight and it is a certain bit messy. We are currently starting to implement a somewhat similar JS/Python web framework with AngularJS on the client side, see my comment above :)
I am familiar(ish) with ipython. I think what Shiny seems to offer, that ipython doesn't, is a gui like interface to the data (whereas ipython provides the ability to interact directly with the code). I think shiny is a great idea when presenting to non-programmer types (whereas ipython seems to be designed as a presentation tool for more technical audiences).
We at RStudio are actually working on a hosted version of Shiny which may be of interest. We have modeled it after the Heroku model, but obviously very much tailored towards hosting R sessions. If you would like to be part of the early alpha please sign up here: http://shinyapps.io/ and we will reach out as soon as it is ready for some people to bang on it and give us feedback.
There's actually a chap on the mailing list who is from heroku and helping to make changes to allow it to run as in a worker. Not sure whether it's working yet, but the blocker was that shiny required root, but the devs have released a patch which fixes this.
See the full web page example [1]. It might be hard to scale a full website using the tech but it is useful in a pinch, especially if you already have a script to generate plots. (of which I personally have many)
[1]: http://glimmer.rstudio.com/pioneer/pensions/