First Crack Release Notes, May 2020

I have wanted to add this to First Crack for a while now, and this month, I finally did it: First Crack now supports post categories.

As a brief refresher, First Crack supports two article types: linkposts, which use a link as their title to refer readers elsewhere, and original articles, which do not. When I copy a new post into the deployment folder, First Crack detects the post type and builds a header based on it, like the one below:

For original articles, the header structure remains the same but some of the values change:

First Crack now stamps each post with the category on line five; clicking that link will take you to an index page with all other articles in that category sorted by time. I need to spend some time re-categorizing my posts, but you can test this new feature out now by clicking the “Development” link underneath the title.

Feature Roadmap #

Along with general maintenance and my constant pursuit of optimization, I also want to get these things done.

Add Syntax Highlighting to Markdown Parser #

Now that First Crack wraps code blocks in <div> instead of <pre> elements, I can add automatic syntax highlighting. Ben Kuhn described an interesting, minimalist approach back in 2018; I plan to do something along these lines.

Release Markdown Parser #

I want to release my Markdown parser as its own project. I fixed a few bugs during the rewrite, but I still have some others to work out. At the least, I want to go public with greater coverage of the spec, and with the ability to handle multi-line strings and entire files at once. My main goal is to design a performant Markdown parser and then write an efficient implementation of it. Several people have already done some interesting work in this space. At present, it implements the subset of the spec I use on a regular basis, and handles files one line at a time.

Publish Implementation of Markdown Spec #

Along with the release of my Markdown parser, I will need to outline the peculiarities of my implementation. Parity with John Gruber’s spec would make sense, or something like GitHub Flavored Markdown which has much more detailed documentation, so I may go this route; if not, I will need to produce my own documentation. This would cover weird edge cases for the most part, but it would also give those who use my engine have some sort of explanation for why their article looks weird. In brief, my argument against going with a standard comes down to the fact that I have little use for most of those features and edge use cases. Once this becomes its own project, though, that others may use, this argument gets shakier. I will have to spend some time thinking about this before I move forward.

Improve Documentation #

A few of the ways I think I can improve the README in particular:

• Re-create usage GIFs. I had a few neat GIFs that showed off First Crack’s simple install process and easy use case, but I will have to re-create those after the rewrite.
• Performance graphs of First Crack’s back-end performance versus other, similar engines. At less than two seconds to build a website of over one thousand pages, I want to highlight this.
• Performance graphs of the web pages First Crack builds versus the pages common content management systems build.
• Screenshots. This site is a live demo of the engine, but I like the idea of having a few pictures in there, too.

As always, I look forward to the work ahead.