This is an awesome project.
We recently used it to build a statically hosted EC2 instance comparison website, using this for plotting (ggplot2) and DuckDB-Wasm for querying the instance data.
Only the first page load is slow b/c of all the wasm and R packages, but it's fast for interactive querying and plotting and was really easy to create.
Since it's now accepted, I guess I can also share the accompanying paper [1] about cloud hardware evolution; the idea is that every plot in the paper is clickable and opens an interactive version of itself. WebR was perfect for this use case.
Impressive how nice this looks, and I am also impressed by how quickly it runs. I don't know who did this (could not find any "about" info), but kudos on a job well done.
However: Aside from the above, and doing it "because one can", I don't understand why anyone would spend the effort to make this. R is FOSS software, if you can run a web browser, you can run R itself. R is not hard to install or maintain. Running in a web browser requires network, and resources on someone else's machine.
So, I am a strange combination of impressed with this site and confounded trying to figure out why it exists. I'm probably missing something.
This project is brand new to me but I have a use case I'm immediately considering, when combined with the "shiny" dashboard library as seen here: https://shinylive.io/r/examples/
At work we have analysts who sometimes produce web-based dashboards for the business to consume. When we had Python folks, they used Plotly Dash and we had to host a server for them. It's a bit silly--the dashboard just accesses APIs and static data, crunches a bit, and renders some HTML. There's no inherent need for it to require its own server. There is "WebDash" [1] but I have not gotten it to work and it says it's alpha quality.
Now that we're getting into R, I don't have any path to production for dashboards. I want to avoid getting into another Plotly Dash situation where every analyst with a one-time idea ends up creating long-term IT burden. Enter WebR: now we only need to serve static files. That's a lot easier; I can serve essentially an unlimited number of dashboards from existing infra this way. Our client machines are beefy with tons of headroom and our EC2 instances are as small as possible, so shifting work from the server to the client makes sense here. I'm gonna try it and see if I've missed something.
When you want to run stuff client side instead of your server is one question to determine.
For R specifically, it is focused on stats/graphing. So if you wanted an app where someone could upload data and fit a complicated regression model, this would be a good use case. (There are probably javascript libraries for regression, but if willing to live with the bit of start up lag, worth it for anything mildly complicated -- factors in R for example would not like to worry about writing my own code in javascript to make the design matrix.)
In the case where you run the server, the data has to travel to your server, your computer estimates the model, and it sends it back. WASM apps this all happens client side.
It is a good use case for dynamic graphs/dashboards as well. If the data is small enough to entirely fit in memory, can basically have a local interactive session with the data and everything will be quite snappy (do not need to continually go back and forth with your server to query data).
Impressively, this managed to download the large nycflights13 library very quickly, and run a regression on its multimillion-row data in just a second or two.
That entire library/dataset is less than 5Mb compressed, which is barely larger than the size of modern commercial websites. An entire bible in uncompressed plaintext is only about 4Mb (compressed about 1Mb). Computers can really handle tons of data really fast; we've just become too accustomed to inefficiencies everywhere.
there should be another "browser" with better observability features. wasm is turning browsers into a hypervisor for virtual machines that run containers for a variety of languages now, including R.
great that these products are finding a way, but there seems to be an opportunity to do this right.
I use R a lot but I still prefer Javascript libraries for interactivity. Javascript libraries feels lot more smoother than something like webR. Having said that, it is impressive that R is able to transcend in the interactivity with just internet browser.
WebR is awesome and I’m trying to use it more and more instead of in operating fixed figures (https://tkschmidt.me/posts/dagstuhl-problem/). I would really recommend to stay with a fixed webR version (and use a CI/CD) process to check if newer versions are still compatible with your scripts.
Readit News
Since it's now accepted, I guess I can also share the accompanying paper [1] about cloud hardware evolution; the idea is that every plot in the paper is clickable and opens an interactive version of itself. WebR was perfect for this use case.
https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/clouds...
However: Aside from the above, and doing it "because one can", I don't understand why anyone would spend the effort to make this. R is FOSS software, if you can run a web browser, you can run R itself. R is not hard to install or maintain. Running in a web browser requires network, and resources on someone else's machine.
So, I am a strange combination of impressed with this site and confounded trying to figure out why it exists. I'm probably missing something.
At work we have analysts who sometimes produce web-based dashboards for the business to consume. When we had Python folks, they used Plotly Dash and we had to host a server for them. It's a bit silly--the dashboard just accesses APIs and static data, crunches a bit, and renders some HTML. There's no inherent need for it to require its own server. There is "WebDash" [1] but I have not gotten it to work and it says it's alpha quality.
Now that we're getting into R, I don't have any path to production for dashboards. I want to avoid getting into another Plotly Dash situation where every analyst with a one-time idea ends up creating long-term IT burden. Enter WebR: now we only need to serve static files. That's a lot easier; I can serve essentially an unlimited number of dashboards from existing infra this way. Our client machines are beefy with tons of headroom and our EC2 instances are as small as possible, so shifting work from the server to the client makes sense here. I'm gonna try it and see if I've missed something.
[1] https://github.com/ibdafna/webdash
On HN, it seems trivial to install software, but for most people it is not.
Also, tablet and Chromebook users.
I believe it's George Stagg https://github.com/georgestagg
The site is running completely locally. You can disable your network in devtools and it will continue to work.
For R specifically, it is focused on stats/graphing. So if you wanted an app where someone could upload data and fit a complicated regression model, this would be a good use case. (There are probably javascript libraries for regression, but if willing to live with the bit of start up lag, worth it for anything mildly complicated -- factors in R for example would not like to worry about writing my own code in javascript to make the design matrix.)
In the case where you run the server, the data has to travel to your server, your computer estimates the model, and it sends it back. WASM apps this all happens client side.
It is a good use case for dynamic graphs/dashboards as well. If the data is small enough to entirely fit in memory, can basically have a local interactive session with the data and everything will be quite snappy (do not need to continually go back and forth with your server to query data).
great that these products are finding a way, but there seems to be an opportunity to do this right.
https://shinylive.io/r/examples/