This is a question I get asked quite often, where "not the right tool" means either using another BI tool or a more conventional GUI/web framework in javascript/python/java/etc. I'd love to get a discussion going, and potentially have this thread as a resource people could come to for an answer.
To get the ball rolling, I'm going to be lazy and just copy-paste a response of mine from an old thread:
Obviously there are many factors to consider. I'd say Shiny is particularly great for fast prototyping and fairly easy to use for someone who's not a programmer. Java, for example, is not very friendly for people who are not programmers, and it takes longer to develop a simple GUI app.
Shiny is also great for dashboards, where you have some data (such as in a database or a file) and you want to show have a page where you show all sorts of metrics in an interactive way. The availability of many different charting libraries is also a big plus.
The one thing shiny is perhaps not great at is multi-page apps. When I say mutipage apps I don't mean multitab, I mean truly multipage, in the sense that when you click on a link it takes you to c completely new page that makes a new HTTP request and loads new resources and acts as an independent page.
The language that your current analysis code is written in is also an important consideration.
There are a lot more points that can be considered, I hope others will share opinions
I would add on that the among the question there is the future of the prototype. At my company, we have datascientists on our R&D team who use shiny for prototyping web apps for experiment and communication with users. When the experiment is finished, users feel comfortable with the prototype and want to keep using it whereas there is always the question of our IT and projects teams about developing an other more classical apps (conventional GUI/web framework) with live support issue and everything. The aim of the prototype could be part of the choice.
I have likewise found shiny to be magnificent for making data available to users to interact with. Our laboratory uses a largish database of a couple hundred tables.
On the other hand, I have found shiny to be somewhat challenging to use for gathering and saving data to the database. I funderstand other tools, like C# in our case, have better tools for this sort of task.
We have several clients for whom we create interactive visualizations for their proprietary data. With Tableau, we are able to package the visualization and send it to them without it hitting the internet. I have been able to improve on those Tableau visualizations using Shiny, but I don't have a good way to share their proprietary date in an offline fashion.
I'd second this point, particularly in terms of hosting and any authentication for access. Hard to beat Shiny in terms of speed of creating a high quality web app but the people at my company who are going to be responsible for maintaining the necessary infrastructure and performance are not particularly familiar with R, so it becomes an extra set of things for them to understand in order to maintain.
when is Shiny a good choice vs when is it not the right tool for the job?
An (often?) overlooked consideration is how expensive / difficult it is to maintain an application that requires a backend server. I personally find that static websites using RMarkdown are much easier to distribute and work for about 80% of the delivery needs that I see at my company. For example, htmlwidgets allow you to include interactivity into a static application. Parameterized Reports allow you to quickly generate a new RMarkdown document with slightly different parameters. There are even tools like R Markdown Websites and flexdashboard that give you a lot of flexibility in making a static website / dashboard. Basically, if you can fit the data you need for the application in a browser, I think you should nearly always prefer RMarkdown to Shiny!
In my experience, Shiny has proven invaluable for rapidly generating simple web pages to display data from a wide variety of sources (databases/apis etc) and capture feedback/comments in a structured manner to be stored in a database. I have not come across a situation that I was not able to build an app based on the requirements (because of the community and great teaching resources, it is even possible to link shiny with rethinkdb for collaborative editing! https://github.com/Appsilon/shiny.collections)
The issues that I have faced are due to the inevitable success of a shiny app. It is very hard to transition a shiny app to a support team to maintain as they often don't have experience in R. Rebuilding the app in another language often takes much longer and it is unclear to users what the value is - we already have a working application. This means that Shiny apps often become "you build it, you own it", which becomes more expensive over time.
I am sure Rstudio Connect (if you haven't tried it, I would highly recommend it) will solve a lot of these issues over time, but at the moment the gaps that I have are related to how to monitor and maintain my applications.
who uses the app and when
logging of errors
tracking of loading times over time (key user experience is how long initial loading takes and it is unclear to me how best to track it and improve it)
I really like shiny and its possibilities and was interested for a long time in this question, since I wanted to bring more R and shiny in the BI consultancy I am working at.
Typical usecases we have are
Classical Dashboards about KPIs, accounting, sometimes involving forecasts etc.
More "data science focussed" usecases involving predictions, social media, maps and so on.
Lets look at both cases:
You could do all these things via shiny, however, in my opinion, there are often better solutions (for now). So there is a whole bunch of (mostly not free) so called selfservice BI tool like PowerBI (Microsoft), Tableau, Qlickview and so on. In my experience, for most of the described usecases, it is just faster, better maintainable and easier to integrate one of these solutions, IF you have some experts sitting around which use these tools every day and know well about the underlying data warehouse and the modelling stages, and the bestpractices about the language of the tool + workarounds for known limitations. Then combining the drag + drop interface + the language of the tool, make it very fast to build and deploy customizable reports, with linked brushing through the whole report and real (or almost) realtime updating, which look also good on mobile and have "all these enterprise features". I was asking myself for a long time, why there was nothing in the shiny world, that creates a drag and drop interface + linked brushing. It would still be hard to compete to maintain a shiny Dashboard in the same way as one of these self service tools, but it would be a good direction to become competitive in this sector. However, this year I talked to some guys at use!R about this and it seems to be a strategic decision not to go in this "point + click" direction of all these tools. The usecases for shiny would be different from this.
Usecases, which involve predictions and modells in general are sth where R is very good at, so, depending on the usecase and the infrastructure, this might be a good usecase for shiny. However, since one can easily embed R in other software (and most of the relevant BI products do) there are many known ways, to handle predictions and other features of R within those products mentioned above. However, these integrations almost always have limitations and it is really up to the usecase and the alternatives, if it makes sense to switch (often just for one very exotic edgecase) to another product. In my case, I mostly develop sth in R, share it via flexdashboard and when the story lives, we embed it in some other technology, because we have more expertise there (we are not specialised on shiny or use RStudioConnect, so these might also be good alternatives sometimes).
So in the end, what is the real usecase for shiny? In my opinion, you might use shiny for everything, if you have a very good expertise in webdevelopment and really know what you are doing, then it could make sense to compete with these self servise tools in "their" usecases. Apart from that, the power of shiny, really comes into play, when you have a specific problem and not simply a dashboard, you want to look at complex stuff and try different models, then there is nothing, which can compete with the power of R at modelling (including textmining, spatial statistics etc) + flexibility + graphics and shiny for easily setting up an app. I also do research for a hospital and there we have many lonestanding research projects, where my colleagues can be easily impressed by some dashboard or shiny app. I could imagine many usecases in science & research or companies, which really do research, where shiny is a gamechanger (especially in pharma).
Definitely, a great tool to have in your arsenal, while asynchronous request which is not a strong point in the current R programming paradigm is a deal breaker sometimes, whereas Python shines with easy integration with Celery and other such message queues.
Looking forward to the async library been developed by the team which will surely contribute towards increasing in adoption
You’ll be happy to know (or maybe you already do?) that async support in shiny is one of the big features the shiny team is currently working on. @jcheng gave a talk on it recently at EARL so that won’t be a deal breaker anymore soon
Agree with @Tazinho regarding applicability of BI in most cases. Simple Exploratory Data Analysis is simply not strong enough case to develop custom Shiny app. Even if you want to have full control over the visualization and would not ever accept closed-source solutions (for whatever reasons), you can still go with, for example, Apache Superset, tools from Google/Uber and/or other open-source solutions. This is before we start talking about already-available commercial software present in most modern corporations - Microsoft Office (and PowerBI pushed on top of it) or Tableau/Spotfire/QlikView.
Whenever one requires "what-if" scenarios with multiple parameters involving complex statistical models or computations, shiny would be excellent solution, especially if modeling is already done in R and if organization is committed to developing and maintaining R capabilities.
Lots of great discussion! And a lot of different options for BI have been mentioned and compared to shiny.
What about shiny vs other web programming languages for creating interactive apps? Has anyone run into technical limitations or things that are unnatural to do with shiny and decided to use a different language?
@Tazinho, @dmi3k Very good points about traditional BI software but I think there can be an advantage of using shiny for typical dashboard apps for consumption by others.
In my experience with some commercial tools:
the lack of community around the tool makes it hard for non-experts to become experts
capturing user input/feedback within the dashboard in a structured manner is difficult. Users often export to excel/email which breaks the link between the dashboard and the source data.
non-intuitive dashboards are very easy to create which increases the communication overhead
If your clients are Windows users, maybe RInno https://github.com/ficonsulting/RInno (packaging of Shiny apps as Windows programs) is something to consider.
I've had this issue as well. Sending the file for them to run locally is an option, but that can be convoluted and difficult for non technical users or people not familiar with R. If it's not too complicated, I'll do something in markdown and send them the HTML file. I can do cool stuff in one of those without the need for it to be hosted.
Do they have to have Tableau in order to open your visualization?
The lack of async and simple progress reporting of long running tasks is making me reluctant to recommend it for our team at the moment. It's good to hear that async is being tackled though.
Maybe I've just missed how to do it. When I looked into it last week, it didn't seem possible to do natively as it depends first on having something async and second on having some way for the async task to call back to the main R process to update progress bar or whatever.
I commented on your cool medium post too about what I'm used to from C# where you can pass in an IProgress which basically gives it a callback which automatically gets called on the UI thread again. The cleanest way currently in Shiny appeared to be to add bytes to a file from 0 to 100 bytes and watch that file using a reactive file watcher.
I also realise it is possible if I'm willing to not be async and that's what I've done for now, outputting the log messages using shinyJs package.
This is a great conversation - thank you for getting it started!
I'm in the process of prototyping dashboards for the organization I'm working with - we're testing Shiny, Domo, and Tableau, and doing a full ROI analysis of the three products. I'm secretly (or maybe not so secretly?) pulling for Shiny, but having never worked with Tableau or Domo am interested to see the results.
Happy to share our results and findings as the prototyping gets underway.
)
success of a shiny app. It is very hard to transition a shiny app to a support team to maintain as they often don't have experience in R. Rebuilding the app in another language often takes much longer and it is unclear to users what the value is - we already have a working application. This means that Shiny apps often become "you build it, you own it", which becomes more expensive over time.