The section in the r studio documentation called Computing On The Language is by far favourite feature of R
It lets a function observe the context in which the function was called, which is why R can contextually use formula notations so ergonomically. That also backs pseudo symbolic computing, like plotting a function over a domain and magically getting the right chart titles.
That language support is why Python libraries struggle so much to replicate the ergonomics of the tidyverse.
What does this mean in practice? Does this mean you could start with a blank .html file, and use html, css, and javascript (like normal), but then somehow run R too? e.g. to generate a ggplot using the browser (as opposed to server, as a shiny app may)?
Has anyone got a minimal reproducible examples (e.g. tiny html file that runs, say 2 * 2 in R)? The example linked to in the article has the key line <script type="module" src="repl.mjs"></script>, but that mjs file goes over my head.
Curious/eager/excited to know/see what kinds of real-world applications this has.
Here is my take -- if you wanted some sort of app that required complicated regression modelling to happen client side (and the data is not crazy big), this would be a decent option. So you just serve the html + javascript files, and client side computer does all the hard work.
Say a forecasting tool (pull down data dynamically, and then it auto-generates a forecast). Or smooth out some other noisy data and display in graphics.
There are probably a smattering of other current javascript libraries, but many complicated things will be supported right out of the box with this. (Looks to me they just compiled most packages on CRAN, I can install my R package I have mostly not touched in several years.)
Does it include a decent BLAS? If I remember correctly R ships with reference BLAS, but for decent performance you need something external. Wonder what they picked for wasm based R.
Probably uses LLVM Flang to make the Fortran parts happen, compiling reference BLAS and LAPACK. As the main dev for WebR is also the one who did this [0].
I wonder what kind of edge cases you deal with when blas is your bottleneck in R. Stan code aside, I’ve seen few problems that are neither instant (i.e. sub hours) nor impossible (I.e years of compute).
Yeah the WebAssemblyCompiler.jl works on things that are StaticCompiler-able https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp..., plus a little bit more since it supports the GC. It's not an "official" compiler and it has some things that mean it's on the "not really maintained list", but it shows it's not too difficult. You can also just retarget LLVM yourself to WASM (it's just a backend of LLVM) without too much difficulty if you're using a limited part of the Julia runtime. So... with a bit of effort a good chunk of the language could do this, we just haven't had much of the effort since most of it has been going towards AOT binary building.
I don't think so, not yet. There's been Julia-on-wasm efforts that have been inching along for a while, but it's not nearly at a mature point afaik. I remember reading that some new developments (maybe shifting more of the compiler work to Julia with JuliaLowering.jl, maybe something else) have made wasm a lot more feasible, but it's gonna need some people with a need for it to actually work on it.
(From context I'm assuming you're not looking for something like Jupyter/Pluto/BonitoBook.)
The part that made it much more feasible is that WASM's "new" GC ended up working nicely with Julia's GC, so WebAssemblyCompiler.jl was able to hook into it. With that, a lot more codes suddenly work because array allocations are fine. It means that in this state if someone took it seriously I think a pretty good version could be had in like 6 months, but it would take a real effort to make that something actually part of the "normal" maintained compiler stack.
Pluto needs a server process and simply shows a nice UI, while WebR literally runs R in the browser on your machine with WebAssembly, so it's not the same
Usually they are shipped in a compressed form. If 12MB is compressed it could be that it represents the entire R runtime to support the general R REPL. It could be possible to reduce the payload by compiling only what's necessary to run a particular R program into the wasm binary. That should cut down size considerably.
If you want to use it to create ggplot2 charts, here is an open source demo: https://github.com/QuesmaOrg/demo-webr-ggplot/
I created it as a side project from using WebR to execute code LLM-generated code (https://quesma.com/blog-detail/sandboxing-ai-generated-code-...). While we migrated away from it, I saw that WebR is cool, and I wanted to share it with you.
I really like R. I find it a nice language to work in. I'm glad to see projects like this that make it more accessible.
What is something which you find better doing in R than in another popular language? Not including its standard library.
R and numpy can both be used as wrappers for blas and lapack but R is closer to a proper array language and is nicer to use.
So basically any data operations that don't require python libraries, and especially any statistical programming
The section in the r studio documentation called Computing On The Language is by far favourite feature of R
It lets a function observe the context in which the function was called, which is why R can contextually use formula notations so ergonomically. That also backs pseudo symbolic computing, like plotting a function over a domain and magically getting the right chart titles.
That language support is why Python libraries struggle so much to replicate the ergonomics of the tidyverse.
https://rstudio.github.io/r-manuals/r-lang/Computing-on-the-...
ggplot2 - in my opinion, there is nothing close to it
At the same time, I often do everything else in Python and just do charts in R.
Everything related to stats or dealing with data. For one, R is actually an array language.
Here’s a ggplot2 example: https://webr.sh/#code=eJxtkLFOwzAQhsWapzh5ckSUpEgsSBkY2RAVrN...
Jupyterlite-xeus compiles jupyterlab to WASM.
jupyterlite-xeus builds jupyterlite, Jupyter xeus kernels, and the specified dependencies to WASM with packages from conda-forge or emscripten-forge.
The jupyterlite-xeus docs say that the xeus-r kernel is already supported: https://github.com/jupyterlite/xeus
jupyter-xeus/xeus-r: https://github.com/jupyter-xeus/xeus-r
emscripten-forge/recipes already has packages for "r-askpass, r-base, r-base64enc, r-bit, r-bit64, r-cachem, r-cli, r-colorspace, r-data.table, r-digest, r-dplyr, r-ellipsis, r-fansi, r-farver, r-fastmap, r-ggrepel, r-glue, r-haven, r-hexbin, r-htmltools, r-isoband, r-jsonlite, r-later, r-lattice, r-lazyeval, r-magrittr, r-mass, r-matrix, r-mgcv, r-mime, r-nlme, r-plyr, r-promises, r-purrr, r-rcpp, r-readr, r-rlang, r-sp, r-stringi, r-sys, r-tibble, r-tidyr, r-tzdb, r-utf8, r-vctrs, r-vroom, r-xfun, r-yaml" in WASM: https://github.com/emscripten-forge/recipes/tree/main/recipe...
It looks like xeus-r and webr both compile with emscripten; for which there's emscripten-forge which is like conda-forge but for browser WASM.
What does this mean in practice? Does this mean you could start with a blank .html file, and use html, css, and javascript (like normal), but then somehow run R too? e.g. to generate a ggplot using the browser (as opposed to server, as a shiny app may)?
Has anyone got a minimal reproducible examples (e.g. tiny html file that runs, say 2 * 2 in R)? The example linked to in the article has the key line <script type="module" src="repl.mjs"></script>, but that mjs file goes over my head.
Curious/eager/excited to know/see what kinds of real-world applications this has.
There’s a simplified example here: https://github.com/r-wasm/webr/tree/main/src/examples/eval
Here is my take -- if you wanted some sort of app that required complicated regression modelling to happen client side (and the data is not crazy big), this would be a decent option. So you just serve the html + javascript files, and client side computer does all the hard work.
Say a forecasting tool (pull down data dynamically, and then it auto-generates a forecast). Or smooth out some other noisy data and display in graphics.
There are probably a smattering of other current javascript libraries, but many complicated things will be supported right out of the box with this. (Looks to me they just compiled most packages on CRAN, I can install my R package I have mostly not touched in several years.)
Yes you can use R in the middle of HTML with this ( and even combine R and JavaScript). There should be a bunch of examples in a repo.
Does this also support Rmd?
That would be pretty cool if you could publish an rstudio notebook and have a flow to edit a copy of the notebook straight in the web.
There is a quarto-webr extension to do this. A bunch of real world examples are at https://quarto-webr.thecoatlessprofessor.com/qwebr-community...
it should via the Rmarkdown library.
Does it include a decent BLAS? If I remember correctly R ships with reference BLAS, but for decent performance you need something external. Wonder what they picked for wasm based R.
Probably uses LLVM Flang to make the Fortran parts happen, compiling reference BLAS and LAPACK. As the main dev for WebR is also the one who did this [0].
[0] https://gws.phd/posts/fortran_wasm/
I wonder what kind of edge cases you deal with when blas is your bottleneck in R. Stan code aside, I’ve seen few problems that are neither instant (i.e. sub hours) nor impossible (I.e years of compute).
Since you mentioned Stan, feels relevant to mention https://stan-playground.flatironinstitute.org/, which lets you run Stan in WASM and analyze the results using WebR
Isn’t the linear algebra conventional wisdom that matrix ops are ALWAYS the bottleneck?
I’m sure this is true in scientific computing.
In R maybe a bunch of resampling would be expected to dominate?
Can you install it as a progressive web app, to work offline as well?
Someone did a demo on mobile a while ago, offline, so yes it is possible but I have never seen an actual code example on how to do that.
Is there "Julia in the browser" that runs locally?
Yeah the WebAssemblyCompiler.jl works on things that are StaticCompiler-able https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp..., plus a little bit more since it supports the GC. It's not an "official" compiler and it has some things that mean it's on the "not really maintained list", but it shows it's not too difficult. You can also just retarget LLVM yourself to WASM (it's just a backend of LLVM) without too much difficulty if you're using a limited part of the Julia runtime. So... with a bit of effort a good chunk of the language could do this, we just haven't had much of the effort since most of it has been going towards AOT binary building.
I don't think so, not yet. There's been Julia-on-wasm efforts that have been inching along for a while, but it's not nearly at a mature point afaik. I remember reading that some new developments (maybe shifting more of the compiler work to Julia with JuliaLowering.jl, maybe something else) have made wasm a lot more feasible, but it's gonna need some people with a need for it to actually work on it.
(From context I'm assuming you're not looking for something like Jupyter/Pluto/BonitoBook.)
The part that made it much more feasible is that WASM's "new" GC ended up working nicely with Julia's GC, so WebAssemblyCompiler.jl was able to hook into it. With that, a lot more codes suddenly work because array allocations are fine. It means that in this state if someone took it seriously I think a pretty good version could be had in like 6 months, but it would take a real effort to make that something actually part of the "normal" maintained compiler stack.
Yeah check out https://plutojl.org/
Pluto needs a server process and simply shows a nice UI, while WebR literally runs R in the browser on your machine with WebAssembly, so it's not the same
Cool but 12MB WASM blob. I wish there was a way of making these WASM builds significantly smaller.
The funny thing is that the performance of a 12MB WASM blob is probably superior to most Shiny apps with more than light traffic.
Usually they are shipped in a compressed form. If 12MB is compressed it could be that it represents the entire R runtime to support the general R REPL. It could be possible to reduce the payload by compiling only what's necessary to run a particular R program into the wasm binary. That should cut down size considerably.
eval_js()- allows R code to execute JavaScript and manipulate DOM elements - neat.
Very useful, thanks