Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
55 lines (35 sloc) 5.16 KB
title: New Stack ― Choo, Enoki, Netlify
view: entry
date: 2019-07-13
location: Linz
excerpt: 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?
text: 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.
### Architecture
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](/blog) 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](/content/blog/new-stack/speed-test.png)
### 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](dat://89a2ea9d96ade0d182e1ed1d70640c523d3d3dc79114c30cf492d4c5482fd47e/), 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!".
### Content
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](/manifesto).
![Directory structure of the content folder](/content/blog/new-stack/directory-structure.png)
If you are more interested in the format used by Enoki, have a look at the [source of this page]( on GitHub.
visible: true
You can’t perform that action at this time.