21–30 of 30 posts
Earlier quoted context omitted.
If the URL is public, it would be neat to see if you want to share it.
Sure! https://cloudspecs.fyi/ (feedback welcome!) 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...
Earlier quoted context omitted.
Sure! https://cloudspecs.fyi/ (feedback welcome!) 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...
I love this, thanks for sharing! Linking to interactive versions of figures is such a great idea and use of WASM.
Since it's only static files, you can also imagine "reproducibility archives" that you can just run in the browser (hopefully) years later w/o installing anything.
Earlier quoted context omitted.
Sure! https://cloudspecs.fyi/ (feedback welcome!) 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...
This is great! Thanks for sharing!
Can R be meaningfully run against datasets small enough to fit in the browser?
Earlier quoted context omitted.
Sure! https://cloudspecs.fyi/ (feedback welcome!) 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...
(Disclosure: I work on https://quarto.org , for the same company that the author of WebR works on) Thanks for sharing that PDF link. It's so good! Would you be willing to write a bit about how you produced that PDF? It's a great example of what places like CIDR should be encouraging in terms of academic publications.
cloudspecs encodes the entire state (sql code, R code, view state) in the URL compressed and base64 encoded, since we wanted to be able to send links around to share interesting plots/tables with each other and revisit old plots if the data changes, e.g., if new EC2 instances come out.
The PDF is produced by good old latex, and the state-in-URL mechanism allows us to just use regular hyperlinks for the clickable plot. The limit is the max URL length browsers allow, but we haven't hit it.
Since we use R+ggplot for research anyway in the local environment (emacs+RSS), we just copied the code into cloudspecs, then copied the resulting link into latex. So a bit of manual work if we want to change the plots in the paper.
Let me know if you're curious about specific things or want to collaborate. Cheers!
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 i…
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).
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 i…
Use case: teaching classes. On HN, it seems trivial to install software, but for most people it is not. Also, tablet and Chromebook users.
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 i…
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.