When the early versions of Shiny were released in 2012, my career changed forever.
I’m not exaggerating. Shiny generalized data analysis – instead of tweaking code and parameters and plots every time a client needed to see a slight variation of existing output, I could build a user interface that would produce the same analysis for ANY inputs.
The researcher could check for themselves, without needing a round trip back to me. We could move faster, and more effectively.
Five years late, Shiny has no equal.
The package can be downloaded and installed effortlessly in any modern version of R, on any platform. I use it on 3 laptops with different operating systems and browsers. It abstracts away the tedium of fiddling with the user interface (unless you really want to do that, in which case you can).
So where are its competitors? Do SAS and Stata care? Have they attempted anything like Shiny, and if not, what does it mean for their futures?
I’ll admit I don’t follow news from SAS and Stata like I do for R and RStudio, so there was a chance I just wasn’t up to date.
When I searched for a Stata web application framework, all I found was a proposal slide deck from a group of users (not Stata employees).
Their slides talk about the same pain points that Shiny addressed: you can’t count on a user having the right version of Stata and user-written packages, let alone even having Stata installed in the first place. It’s also difficult to take analysis code and translate into a more commonly-used web development language/framework.
This is important: it’s easier to develop and maintain one system (your server) that can communicate with others around the world in a standard protocol (HTTP) than it is to hope people around the world can make your code work on their machines. That’s what they propose:
While they discuss Shiny a bit (and mischaracterize of the concurrency limit), they missed an opportunity to talk about OpenCPU. They system they proposed (above) is actually much more like OpenCPU than Shiny.
But there’s still a huge problem: Stata probably (presumably) doesn’t want this to happen. Any time a proposal has phrases like “user impersonation” (to get around Stata’s limitation on running as a system user), your plan is in trouble.
That’s not a shot at the developers – I actually think it’s great they were thinking about this, and now I want to try it! Rather, it’s a shot at Stata. Why isn’t there a way to integrate Stata code into a web app without having to trick the system?
Alright, I’ll give Stata a rest and move on to SAS. There actually is a SAS-sanctioned (no user impersonation here!) approach to building an HTTP-based web application.
It’s called SAS Stored Process Web Applications, and I’ll admit right now that I’ve never used it. I’ll also say that I would use it and offer a review if it made economic sense to pay for this instead of just using Shiny. SAS, if you’re listening…
So what follows is a review from quite a distance, for full disclosure. I’ll mainly comment on excerpts from the online documentation. Like this:
Streaming output stored processes deliver their output through the _WEBOUT fileref. You can write directly to the _WEBOUT fileref by using PUT statements, or you can use the Output Delivery System (ODS) to generate output.
Put statements and ODS output. No way to simply and systematically create JSON? I bet I have to paste it all together myself if I want that.
I’ll give them a break on the configuration page, since all configuration pages look like a foreign language until you’re familiar with the system AND absolutely need to solve a problem.
The SAS Stored Process Web Application is set up to use the SanitizingRequestFilter to check for invalid requests. If an invalid input string (for example, <script>) is found in input parameters, then a status code 403 is returned to the Web browser.
SAS earns some respect for making this work with basic web forms (including file inputs for uploading data), and also for having built-in input sanitization.
I’m impressed that there’s more potential to build SAS web applications than I expected.
But I still think there are some big pieces missing to make this anywhere near a Shiny competitor for my use cases:
- Most simply, a way to try this online, without downloading or installing anything. Apparently the installed version comes with a bunch of demos – why not put them online here too, so I can see before I pay?
- As far as I can tell, a Stored Process Web App returns SAS output as a file of text and/or images, not an effective standard like JSON, which I could manipulate or use subsets of or use with any other tool that can send HTTP requests.
- Again, no free usage tier means I have no reason to explore this. If I could try it for free, I would, and I might even build a few apps and let my clients tell me what they think. But I haven’t heard anyone ask about this – they ask about Shiny, so I’m not paying up front to offer them something else.
So what should we make of this? Is Shiny only capturing a huge market of users who want an open-source and low-cost solution, without generating much interest from big players?
I don’t think that’s true, based on the profiles of our own clients who have specifically requested Shiny applications without asking for alternatives, but is that what SAS and Stata think? Surely if there was a lot of money to be made enabling and support web applications then SAS and Stata would have entered a user-friendly solution within the past five years?
Or maybe not – I think R (and subsequently RStudio) were underestimated from the start, and maybe it was natural for Shiny to be the next new, widely-used thing that SAS and Stata ignored. I’m not sure why, though. I’d love to know more about it if anyone really does know.