Blog Template & the current state of JavaScript

I decided to recompile userland & kernel on the machine this blog is running on and naturally this will take a while. So why not use the time to write my first proper blog entry…

In the last days I spend some time taking a closer look on the template for this blog.

The reason why I decided to use Attila as theme is that it seems to care a little bit on privacy.

If you click through the demos on template marketplace for ghost themes you’ll notice that a lot of them are loading assets from external sources.

For me privacy is very important, and loading external ressources from third parties is an absolute no-go! This is not something I want to experience personally, and therefore this is nothing I want to force on my visitors.

Scrolling through the changelog of Attila one can see, this theme never was designed in terms of “privacy first”:

Please don’t get me wrong - I do not want to rant about the template - the template is great, it looks very good, is very usable, and even comes licensed as open source. Awesome! Thanks!

I am very well aware I am complaining on a very high ground.

But there is still a thing that bugs me - The logo from the top left corner is still fetched from casper.ghost.org. I do not want that and maybe I could patch it out..


So I set up a local development installation of Ghost, cloned the repository, and replaced that logo by a local one.

Easy task, five stars - would do again!

And while we’re on it I removed the comment feature for Disqus (because privacy)…

Then I noticed that this template was using JQuery for it’s JavaScript logic. At least it is bundled inside the template and is not loaded via some third party content distribution network.

But the bundled version is a pretty old one (version 1) - nowadays version 3 is recent. The old ones aren’t patched anymore.

For most parts JQuery isn’t needed anymore - So I thought it could be possible to remove it completely by rewriting some parts of the source code.

It turns out that there are some plugins inside the template which require JQuery.

For example FitVids.js which resizes embedded videos from YouTube and Vimeo.

Ok - there is fluidvids.js which has no dependencies and does the same. Great.

So I started to fiddle around inside Grunt - the JS build tool used in this project…

After updating most NPM dependencies inside the template, I started updating them to a more recent version.

While fixing all the trouble I caused by updating all those packages I stumbled across the information that nobody is seriously using Grunt anymore…

Sigh. While we’re on it - let’s also replace the complete toolchain. Most blog posts mentioned webpack as state of the art build & bundle tool.

It can do anything, but most of it only via external packages - yay more dependencies, more problems.

To configure webpack builds the documentation is very well written to get started, but leaves you in the dark with a lot of corner cases.

To make the require and import statements work (I guess) the build output is inflated by some JavaScript code - over 100 lines of weird stuff, bundled right into my Hello World test script… Why is it there, what does it even do?!?

Better - I set up building .scss files into CSS like it is recommended in the documentation. And all I got was a style.js file. What am I supposed to do with that?!?


Every once in a while I take a journey into JavaScript-Land. And I don’t really like what I see.

It becomes more complicated each time - I don’t get it why there are always at least three competing solutions for the same problem.

If there is something new, no one can tell you if it is worth the effort to learn about it or if it is already gone next year. Tooling in JavaScript-Land is still an issue. After all this time. A lot has become better, but there is still a very very long way to go.

The thing I don’t understand is that most problems JavaScript tooling is trying to solve has already been solved in most of the other languages.

You don’t need much - You have some source files there, want to process them in some way, and copy them somewhere else.

This is something a makefile can do best - And as long tooling in JavaScript is such a mess, I will always help myself by writing a makefile for my tasks.

It is not the shiny new technology, and has a steep learning curve, but it has proven to be very solid and flexible. It was not invented to be used for JavaScript (it is much older than the language itself) - but it can accomplish the job better than most native tools in JavaScript.

I think the situation is just sad, let’s see if my next journey into JavaScript-Land will bring up something useful.

I’m now done with my rant and off, writing a makefile.

So long.