Tag: Jekyll

Jekyll Build Time

I wonder what website build performance will be like when he gets to 4,000 posts. Slow build times are why I have ruled out converting my website to Jekyll or Hugo. I've got over 4,000 active posts (and many with images) on my 14-year-old website. I create about one to three new posts per day. I can't imagine writing a post, waiting several minutes for the website to build, and then copying the files over to a server each and every time.

He made a lot of customizations to make things work faster. If he changes themes at some point In the future, he’ll need to redo the customizations.

I think the challenge for static site generators is that they were designed to be used for sites that don’t change often; e.g. corporate web sites. In other words, ststaic content. But now we have people, trying to shoehorn it for use with sites that update more often; e.g. blogs. Hence, the need to hack together work arounds. It’s klugely.

Best to use a system designed for dynamic web sites that have frequently updated content: e.g blogs. Ghost, WordPress, etc. do that well.

Building Static Web Sites Suck

Man, do static sites suck. by Vicki Boykis (veekaybee.github.io)

I like clean stuff and I like tech blogs. So, I decided to give Jekyll, the most popular of the static sites, a try. At the same time, I’ve been revamping my main website to include some other WordPress blogs, so I decided to see how long it would take to install WordPress on Bluehost versus Jekyll on Gitpages.

Twice I’ve tried to setup a Jekyll website. I was successful once. The effort involved was much more than the QuickStart on the Jekyll website led me to expect.

So far I have Jekyll running on macOS but my process was.

  • Install HomeBrew — after realizing that I needed Git.
  • Install Git
  • Install Jekyll
  • Install a theme
  • Create a new page and modify front matter.
  • Launch Jekyll server

I already knew Markdown but I am unfamiliar with all the front matter stuff. If I have to learn Ruby or use a third-party web service to get anything done, I will abandon the project. Ruby sucks.

The Downsides of a Static Site Generator

The Downsides of a Static Site Generator by Martyn Chamberlin (Drinking Caffeine)

Database-driven architectures are better than file-driven ones. Who knew?!

Although Martyn later changed his mind about switching to WordPress, from my experience, his points are valid.

The challenge I have with using a static site generator or daily blogging is the amount of time needed to create a new post.

I like to create posts with featured images and many of my posts have several images. My current workflow for WordPress is:

For static site generators, the workflow is.

  • Export images to a folder
  • Open terminal and navigate to the content folder
  • create a new post — don’t forget to add font matter for the date, post title, etc.
  • Insert text and images —more challenging since I have to copy paste path and name of specific images. Lots of back and forth between text editor and files system
  • save file
  • build the ENTIRE site -- wait. Wait some more.
  • move files to the production web server

I don’t want to do that for every blog post. Too much work. It’s friction that gets in the way of content creation.

If I want to, I can create a WordPress post directly from my iPhone while travelling using the WordPress app. Or from my iPad.

Because Jekyll and Hugo have not front end, the way to create a post from a mobile device with a static site generator is to string together a solution using GitHub and Dropbox and a bunch of other third-party services.

I think Static Site Generators are great for creating static websites. For example, a business, church or organization website that doesn’t update very often. I think they are the wrong solution for a blog.