My blog is now a JavaScript-powered static site

Ryan Weal

April 11, 2017

Today I am re-launching this blog as a static site. Years ago it was a static site powered by bash scripts, later it was imported into Drupal, upgraded, stagnated, and finally converted back to static using node.js-based static site builder, metalsmith.

The rendered version of the site includes no JavaScript itself, and much care and attention was made to ensure I have clean URLs, a nice xml sitemap, rss feeds, and all the other typical blogging features.

Why am I moving away from a CMS?

What about social networking?

In 2017 I'm trying to reduce my level of participation on big social networks. I still post on twitter, but my connections to pump.io and statusnet are long since gone... and I left Facebook even before that. I consider my LinkedIn account virtually read-only, so here we are. Back to blogging.

For now I will be cross-posting blog articles to twitter.

I plan to do more "in real life" social networking at JavaScript-focused conferences.

Why Metalsmith/node.js rather than $X static site builder?

I spent some time in the summer of 2016 "retooling" by doing small projects that brought me back into the JavaScript world. I have worked with Vue.js 1.x and 2.x on a couple "app-like" projects, but for this site I wanted to see how far I could get by making the final product be rendered files. This will hopefully help preserve some of the SEO juice that has built up over the years.

My first Vue.js project was my task-list tool Bulletpad which was the inspiration to my offline talk which I presented at Badcamp in Califoria and at DrupalCamp Northern Lights in Iceland. My second Vue.js project was an Electron app interactive kiosk touchscreen application. Neither of these projects resemble the idea of building "webpages" so choosing Metalsmith was a nice middle ground where I can use JavaScript and familiar tools, but to achive a different outcome (static files rather than an "app").

Since I was already spending a lot of time with Nginx on performance work I customized my configuration there to have URLs as nice as I could get (to match what Drupal does) and I also forked an NPM module to make URL aliases for my old paths - using this most performant Nginx syntax possible, to prevent a mandatory 301 when hitting directory paths. That is now on Github and NPM under the name metalsmith-aliases-nginx. It was my first contribution to NPM! The other redirection solutions involved multiple round-trips to the server. Tuning a static site on the server level is important...

Finally, the most exciging arhitectural feature: each page on this blog is fully self-contained unit! To load this page your browser probably only made one request. That is something that is near-impossible to do in Drupal (which, if you are interested, involves throwing out all of Drupal's CSS and JS, which is never fun!). Making the page a single-request should virtually flatten the loading times around the world since there is only one round trip to the server, and thus, the latency tax only happnes once (or twice, if you count DNS lookup, but DNS is cached regionally quite often so it costs less).

What next?

My plan is to get more JavaScript-related articles posted. I have some drafts in the works. One of the next posts will likely be a technical run-down of how I converted this blog over. I will likely still do the occaional post on Drupal but I suspect that based on my latest reasearch and general interest that there will be a greater focus on DevOps with things that compliment the work I do in JavaSCript.

You probably won't find much more about Drupal Migrate here as I'm largely moved on (although I do still accept migration projects). For the time being I have made a "cheat sheet" that contains the most up-to-date configuration reference at kafei.fyi/migrate.