Why I chose R Distill on Firebase for my homepage

Briefly on why I chose to use R distill and host it on Firebase Hosting.

I thought I might briefly share why I’ve chosen Distill for R Markdown as the “framework” for my homepage, and why I prefer to host it on on Firebase Hosting.

Why Distill for R Markdown

Perhaps most importantly, it is really easy to set up and deploy (kudos to the RStudio team 👏). After having made an RStudio project of a Distill blog, it is very easy to add blog posts from within RStudio and then push to Github (more on Github integration with Firebase below).

Thomas Mock’s summary on Pros and Cons of R distill sums it up nicely. Here is my “personal” list on essentially the same:

• No Hugo or other build dependencies. If I want to add a new blog post, I simply write a new distill R Markdown document and compile/Knit it to static HTML, then push to Github. No framework build step or anything. This as little overhead as I can imagine.
• No version dependencies. I am not sure I’ll blog very often, but when I do I want it to be hassle-free; I want to focus all my time and effort on making the blog post, not getting the blog to work. Even though, say, my next blog post might be in two years time, I could confidently update all my R packages and be sure that as long as my blog post compiles to HTML it can easily be added to my blog. This is in contrast to frameworks like Hugo, where you’d risk running into compatibility issues and you’d need to occasionally update your Hugo version (with the risk of screwing things up since I’ve long forgotten how to set up this damn blog.)
• distill::import_post() Some times I think it would make more sense to write the blog post in the repo of the project that I’ve been working on rather than the workflow of 1. create project and 2. create blog post about it in this homepage RStudio project. import_post() easily enables this.

And, of course, I really like to work with R Markdown in RStudio for creating reports/blog posts, and Distill articles seems to be a sort of an enhanced version of “vanilla” R Markdown (I especially like the nice code folding and easy control of width of tables and figures).

What about Python?

A current learning goal is to get more familiar with deep learning frameworks like Tensorflow and PyTorch, so I am likely to spend more time in Python than in R on my side projects. I haven’t panned out exactly how I could easily integrate my work in Python on this blog, but I am pretty sure I will figure something out. There’s the excellent reticulate package which certainly could be suitable in some cases. However, I think that if I spend most of my time working in Jupyter Notebook/Colab, I am hoping a can find a way to embed such notebooks in my blog posts rather than “rewriting” them with reticulate. Update: it doesn’t look that easy. I tried to convert a Jupyter Notebook to markdown, and then embed that in a blog post, and it didn’t look good at at all. I guess I’ll rather just link to the notebooks on Github in the blog posts then.

Why Firebase

The primary reason for chosing Firebase over Github pages, Netlify etc. is the simple integration with Cloud Functions. I am very fond of Google Cloud Platform’s Cloud Run, which I would use to host the dashboard apps or APIs for my side projects.

Firebase has nice Github integration, which enables one to work on blog post drafts in git branches. In addition, It could be fun to try out some of the Firebase ML integration with Google Cloud ML services.