I looked at some alternatives such as harpjs and hugo, and while both of them are fantastic tools, I wanted something much more basic.
I feel that the moment the content for a website has the need for configuration files, you are no longer building a basic static site but a dynamic site with a print release system. While there is nothing inherently wrong with this approach, it seems overkill for a number of projects I’d like to build.
My goal with this code was not just a basic static site generator, but the ability to compile many files into a single “book”. Ideally the ability to do so using a single template file, and with nothing more complicated than a handful of variables inside it.
The code needed two paths, one for making a single page book, and one for making a multi page site. There also needed to be a split in the path for multi page generation that allowed for relative paths, so it could be used/accessed like locally generated documentation.
I was also creating this as a work-project, and had a deadline to meet. So I dropped some of the objectives from the original design, such as multiple index support, and some of the navigation logic was changed when I looked at how some others were doing it, like Steve Losh.
As I learned more about go, I made many changes, including separating the command from the package, and overall the layout and naming sense.
I also removed some features, like navigation which was too complicated to be useful in a generic sense, and relative paths which were meaningless when markdown itself is readable.
At this point I have no further plans to modify or refactor the code.
One beneficial change might be to add stat logic to get the modified time of a file and compare it to the output file. This would allow me to only replace modified files, which could reduce the overall load of execution when running in web mode.
Another option is exposing the package-global list and allowing replacement or additional file extensions to be supported.
However, I am considering moving to hugo instead for a variety of reasons. That would make any additional effort here quite wasteful.
I’ve been fond of reading about game development lately, and came across gameprogrammingpatterns.com/, which was written using markdown. This is primarily because the best practices we use in our field today so greatly conflict with game developments version of best practices where performance far outweighs the value of things like object-oriented-design.
Another great resource I found was the golang book, which is also written in markdown. I find great beauty in the simplest of aesthetics, and this is a perfect example of that.
updated on 2017-04-13