Blogging with Metalsmith

30 Jun 2015

I'm switching blogging platforms once more. Moving from Wordpress to Jekyll enabled me to no longer deal with the multitude of updates and protected me hacks I could be susceptible to, but Jekyll being written in Ruby (a language I'm not overly familiar with) has been a problem. I've been able to cobble together scripts to deal with the custom parts of my blog build, but it's never felt like home.

I've decided to start using Metalsmith - a static site generator written in Javascript. It's existed before my switch to Jekyll and now seems to have enough of a plugin ecosystem in order to provide a collection of plugins to provide behaviour I need to make use of.


Metalsmith operates much like a task runner like gulp, where a set of functions manipulate a number of files, one after another in order to eventually build a static site to your liking. A simple build script could be as follows:

var Metalsmith = require('metalsmith'),
    markdown   = require('metalsmith-markdown'),
    templates  = require('metalsmith-templates');


This is just standard node script with dependencies installed via npm. Metalsmith assumes defaults of src and build for the source of markdown and destination of html. An example of markdown containing some useful front-matter might be as follows:

title: Blogging with Metalsmith
author: Ian
date: 2015-06-30
year: 2015
month: 2015/06
  - Javascript
  - metalsmith
  - javascript
I'm switching blogging platforms once more...

It also assumes a default template directory under templates, containing a default post template 'post.html' - which in the example is written in a swig template as below.

    <div class="post">
    <h1><a href="/{{ path }}">{{ title }}</a></h1>
    <div class="post_date">{{ date | date('d M Y') }}</div>
    {{ contents | safe }}

I've managed to reduce my build time (though I'm not currently compiling sass and have added a new sitemap), but am much more familiar with the toolchain in question. Hopefully that'll lead to further, more frequent updates not just in content, but also the design of my company site and this blog.

I'll be adding future blogs about my metalsmith toolchain and hurdles with that I've overcome.

Tagged metalsmith, blogging, javascript, | Leave a comment

The Problem with Full Stack JS Applications

03 Apr 2013

Whilst node.js heralded an era of being able to use a single language for both server and client side development, nobody mentioned the confusion such an approach could cause. It’s inevitable that there’s going to be similarities in code that constructs data on the server and that which presents it on the client. The fact that the two are written in the same language and the structure of them is so tightly coupled can make it easy to lose track of where you are and what you’re doing when knee deep in code.

Having primarily been using a full js stack (express on the server, backbone on the client) for side projects over the last year or so, I’ve certainly found myself tied up in this kind of knot. For example, if I’m looking at event.js, which represents an event on a calendar it could be the server event representation, used as an accessor for a db or a client side backbone model presenting the events attributes as part of a view. Usually (if you’re using a sensible class naming scheme) it is enough to know the file (.php or .js) within which you’re working and if that’s not enough, then the language syntax usually is a dead giveaway for where you are in your codebase. But this isn’t the case when working in one language. My guess is you’re going to have to take a second glance in order to figure out where you are, which isn’t a big issue, but is frustrating.

Currently my apps typically are structured like this:

server.js (Main node/express file)
-lib (Classes for DB Calls)
-node_modules (Node requires)
-public (Client backbone app)
        -lib (Backbone and other dependencies)
-routes (Contains the main express routes)

But I actually think the following is a better approach:

-client (Renamed from public)

At least with the second approach, it is easier to have a clear idea of where to find classes on first opening them. Unfortunately, this doesn’t however solve my problem of moving between server side and client logic and pausing for a moment before realising I am where I need to work. This is a first world problem for which I don’t believe there is a solution.

Tagged javascript, web development, | Leave a comment