Move gallery apps to shinyapps.io

[gshotwell]

I did some tests and the shinylive apps on the gallery take about 25s to load on my machine. This is too slow for such simple applications and since the user likely doesn't know the internals of shinylive they'll think "Shiny is pretty slow" instead of "wow isn't it amazing that these are running in the browser!"

Hosting the apps has some additional benefits as well:

• More friendly to users with bad internet connections
• We can provision some apps to be always running
• It encourages more complex apps

[wch]

I agree that 25s is too slow for an app to start up.

Just to be clear, the reason that many (not all) of the gallery apps are deployed on shinylive.io is not just because we thought it was cool for them run in the browser. We had discussions about it and weighed pros and cons.

I think the biggest difference in your experience is probably the speed: I suspect that CloudFlare (the current host for shinylive.io) may not have good performance where you're located, resulting in slower loading times for you than for most others. I think it's likely that moving to AWS will improve performance for you and others who aren't well served by CloudFlare, so that's something we should do.

Some pros of having examples on shinylive.io as opposed to shinyapps.io:

• No need to redeploy apps when we update Shiny (they automatically use the version of Shiny that's on shinylive.io), and no need to manage/maintain the deployments on shinyapps.io.
• Many apps load faster (for me) on shinylive.io than a cold-started app on shinyapps.io. For example, the orbit app on shinylive.io loads in about 5s with a hard reload in the browser. An app that has lighter Python dependencies (Wordle) loads in about 2s. That said, if the apps are configured on shinyapps.io to stay running, they will be able connect faster (see comment about that below).
• The user can easily see the code alongside the app, and experiment with it.

For any apps that we have on shinyapps.io, they definitely should be configured to keep a process running. I just looked at the Airmass app, for example, and it took 17s to start. After the initial startup, a reload only takes about 1s.

[gshotwell]

Right, so a few options:

1) We could redeploy the apps from CI as part of the release process which would trigger the update. 2) Are you testing those shinylive apps from a clean slate? I don't quite understand how the whole pyodide initialization process can be faster than connecting with a running application just because it's sending so much more data 3) Could we include a link in the application which would let people open it in Shinylive for editing

I guess my intuition about it is that mostly people look at the gallery to get a sense of the user experience rather than the developer experience. So fast load times are more important than being about to edit and reload them.

[gshotwell]

We modified the gallery account so that we can now keep the apps alive on shinyapps.io for two days since their last visit. So that would probably mean that 99% of people would hit a running app and wouldn't need to wait for a restart.

[icarusz]

I do think an "see and edit the code in the browser" type button to shift to shinylive could meet the "The user can easily see the code alongside the app, and experiment with it." But moving to AWS to speed things up and getting a handle on the "average load times" seems hard. Do we need to do some benchmarking? Load times really do matter quite a bit. (We are all in loud agreement on that!)

[nealrichardson]

You could add a "shinylive button" to the apps easily enough, provided that you already had a copy of the code in shinylive to put as the href. That makes for a different problem of ensuring that the code stays in sync in both places, which we could solve with a publishing script that updates both places, or something. Or just rely on code comments to remind us to do it and count on there being few updates to the example apps to worry with.