New Stack ― Choo, Enoki, Netlify

The design and the type of this site has changed many times over the 2 years of its existence, but the technologies on which is built on, remained nearly the same. Until now. With some features I was unsatisfied, some I missed and others have been removed. What ― Why?

This post is a bit out of date, as the site is using stakit now. Will write about this soon.

The last time I've changed the infrastructure was, when the new Enoki, including the Enoki Panel, was released. It was a big change from Enoki's UX perspective, but the format of the content (as this is one of the main ideologies behind Enoki) and the use of Choo as a framework, remained the same. This was also the time, when Enoki and the site became peer-to-peer first. I was very happy about this back then, but keeping the DAT and HTTP versions in sync was cumbersome and uncomfortable.

As I'm not a "self-titled peer-to-peer web power-user" anymore, I've already stopped updating the DAT version quite some time ago.


Nothing has changed in the source of the site, it's still the same Choo architecture that (for me) is the most natural way of building for the web. A slight difference is that I've moved away from the original enoki module and started using my fork, as Jon-Kyle hasn't accepted my pull request, yet. The fork introduces a preloaded variable in the state and if it's present, it skips the first re-render of the app (usually loading state). Small thing with a huge difference.

This was required, because the primary goal of the change was to make the site static, or at least static-first. Two months ago, I've started working on a little script that generates static files from an Enoki formatted site. For some inexplicable reason, I thought that this is not working, but the generated site was almost perfect on the first run.

To don't end up in a situation as the one with two separate sites for DAT and HTTP, I've decided to make this version HTTP-first, for a few reasons. The most important is that the peer-to-peer site was a JavaScript application, so it was not usable in <noscript/> web-browsers and inaccessible for tools like Dropout or search-engines. Using a server-side renderer would have been an overkill, so I've decided next to the static-site version, which is also faster and can be more lightweight. In reality it still loads the Choo app onto the static layer, but only to enhance the experience with quicker view changes and the pagination of the Writings page. Feel free to disable JS if you'd like to.

The purpose of this site doesn't require any SEO, but since I focus on that as part of my work, I've started to see it as a great technical challenge and decided to focus a bit more on it (of course, in a users first, Google last priority). I was quite glad when I saw the 100% PageSpeed Insights results, which is, of course, a success of Netlify.

Screenshot of PageSpeed Insight results

Hosting / Deployment

To automate the deployment, the site is now hosted on Netlify and is generated on-the-fly using enoki-build. I didn't want to use the pre-rendering solution provided by Netlify, to keep the site independent from platform specific features. If I would like to move away from this host, I can do it without problems ― anyone can host a static site nowadays. So far, the experience with Netlify is over my expectations. Great platform, with useful products / solutions, cutting-edge performance and clean UI.

The site is still accessible through DAT, at a new URL, but you might see work-in-progress states there, as I still preview my front-end projects using Beaker (it's unbeatable in that). I use Beaker less nowadays, but the site should be seeded by my Hashbase instance. We'll see how this works out in the longer run. I still recommend to "seed it if you need it!".


My editing workflow has also had to adapt. I've stopped using the Enoki Panel and started to edit the files using the following process:

  1. Edit the file in micro
  2. Check the result in Beaker (with live-reloading enabled)
  3. Run $ g co "changes" && g sh to publish

It's clean, it's simple and almost automatic for a programmer. To make a new page, I simply copy another one with $ cp. I was thinking about making a generator script, but right now I find it unnecessary.

The format used by Enoki still resonates with me. I find it very logical, dynamic and future-proof, while staying human-readable and editable.

Directory structure of the content folder

If you are more interested in the format used by Enoki, have a look at the source of this page on GitHub.

~ July 2019 / Linz