Have you ever wondered about the sheer amount of problems you encounter daily? Some of them disappear over time. Some of them may be ignored. Some of them might be delegated to someone else, if you can afford it. If none of these options are available, your time and your attention is required. Usually, these are kind of problems that you need to solve personally to move further in what you are doing.
If you are for instance mowing a lawn with your new shiny weed-eater and you run out of fuel, in order to finish it, you must refill the tank. If you are painting a bench and someone sits on in during your break, well, you have to find a way to remove the freshly created artwork from the paint. Hopefully the one who was responsible for the two rounded shapes you are left with is not siting there still, otherwise you have multiple problems to solve. In my recent quest to own a blog filled with glorious posts, I have also received my fair share of interested problems to solve.
Sapper
About half a year ago, I have discovered Svelte and immediately felt in love with it. If you haven't heard about it yet, it yet another javascript framework. This one falls into the category of disappearing frameworks. Disappearing framework disappears before deployment, because there is no virtual DOM. You are left with a lean bundle of code that modifies the DOM with just enogh lines to work. It's main competitors in the field are of course React, Angular and Vue, but it has it's own set of advantages and disadvantages over them.
These three giants also have their extended cousins that enable more useful features like SSR. For React it is Next, for Vue it is Nuxt to name the most relevant. Similarly, Svelte offers a solution that is called Sapper. Sapper is heavily inspired by the former two, so if you have ever used them before, you will be familiar.
As you already suspect by the hints, this blog is also powered by Sapper. Interestingly, it is pre built in a way that complies with another trend in the industry I have been able to identify, that is called JAMstack. This name stands for Javascript-APIs-Markdown-stack. With sapper, you can also deploy JAMstack apps without much effort, although I am not sure if there is any mention about it in the docs. Hopefully, you will see the connection too, once you are familiar with both.
Well, this is not a JAMstack in a complete sense yet, because at a time of
writing I still do not use any API here, but bear with me. The javascript +
markdown combo is present. Specifically, the posts itself are all stored as
a file with the .md extension. My motivation for choosing this approach
is twofold. Firstly, it requires almost no overhead to set up. There is no
database yet. And secondly, you simply open your editor of choice and
write. In my case it is vim which I use for almost every kind of text.
When you save the file, it is done. No <textarea> or copy-and-paste
reqired, as would be the case with other web based solutions.
But this setup, as efficient as it is for me, also has some significant drawbacks. Since Sapper is not specifically targeted at blog creators, it has no built-in functionality for this task. Every feature you need, you have to bake in yourself. There are no fancy plugins, like for instance WordPress would offer. Even though I have used PHP in the past extensively, I have for some reason did not end up deploying WordPress too heavily. It was maybe two or three times at max, for some side projects, that are not longear alive anyway. I have decided for a small incremental changes to mold the final product to become what I envision in the future.
Sorting the posts by date
Over the time I have come to the conclusion that deployed solutions generally falls to the two categories: monolithic and modular. Monolithic solutions tend to promote rich set of features at the cost of harder customizability. Modular solutions promote monimalism and interoperability at the cost of overhead needed to set them up.
As I have already mentioned, with Sapper being my blog driver, I believe I have chosen the latter. One of the first problems that I needed to address to move further is sorting the posts by the date when they were first published. Currently, since they are just a files, they are sorted by their name, which is definitely not optimal for a blog. At first I did not notice, because the posts did by a pure chance sorted itself mostly right, but as they started to pile up, it became obvious to me that I need to fix it.
Sorting the posts that are queried from the database tend to be easy. However, the whole blog is stored in a git repository. This means, that all the dates of creation and modification is stored in it as well.
The proof of concept with sources and more technical details can be found in the repository.
Conclusion
Learning by doing technique sometimes nudges you towards the situations that you do not expect beforehand. And I mean, this happens more often than not for me. I have demonstrated that you can reliably provide your blog posts with created (published) date along with updated (modified) date utilizing the git commit history.
Stay tuned to find out, If I am able to go databaseless with this blog. If you have any comments or thoughts, please let me know.
Relevant sources are available in the repository