@coatless.bsky.social also did that few months ago using another approach based on JavaScript.

"Pick your poison" 🙃

github.com/coatless-qua...

I did; but at the end of the day it's just eye candy for a README that I touch once every 3 years. The license section at the end of the README with "GPL (>=2)" is more than sufficient. In the end, I'm trying to pay it forward to my future self on simplifying CRAN maintenance tasks pings.

Aye, I noticed the timeout persisting despite the changes. So, to get ~10 packages update; I'm just dropping all badges in the README sin the R CMD check one.

Ubuntu 24.04 dev preview has some AppArmor issues during development (github.com/coatless-rpk...) but the built AppImage works perfectly.

{flexdashboard} will not work as that requires a genuine R shiny backend. The rest depend on capabilities of webR and what assets are included in r-shinylive.

For persistence, electron does allow writing to disk in the user directory. This isn't supported under the VFS for shinylive variant though

{golem} should work with some creativeness, e.g. place app.R in the package-level directory:

pkgload::load_all(export_all = FALSE, helpers = FALSE, attach_testthat = FALSE)
options( "golem.app.prod" = TRUE)
mygolemapp::run_app()

This side steps the custom WASM compile of the golem app.

Eh, I've tended to stay away from VMware post-broadcom acquisition. Appreciate the note though...

Correct, we're not embedding genuine R (like prior attempts). We're limited by webR/Shinylive capabilities. If the package compiles under webR, you're set!

As of webR v0.5.5, making HTTP requests was addressed by George. But, genuine R embedding is on the feature list.

Agreed. More coming soon...

Should work out of the box on Windows 10. I only have a Windows 11 license to test with.

It’s straightforward under shinylive variants at the cost of needing to be WebAssembly compliant + lowers the security risk considerably (VFS instead of FS access).

Still working on genuine embedded R. Likely possible with outsourcing installer packaging on different OS to GH actions.

Yes, the goal is to create a standalone Shiny application that mirrors a traditional application. For now, the experimental build supports R shiny apps via `r-shinylive`. This will likely be available for PyShiny via `py-shinylive`; but, that's a ways off and maybe a Python package later ;)