After our discussion in part 1 between content management systems and static websites, we have come to the conclusion that static websites are definitely cost less in terms terms of time, security, and maintenance. Now, we're going to look at what options we have when we want to create our static website.
As I have mentioned before, I do not foresee this website to have many pages. My size requirements , therefore, would be a solution that can handle 10,000 pages relatively well.
I also would want to be able to manage these pages in an effective manner, such that I can edit the pages simply, update them on the go, and even customize parts of the website as I wish without much hassle. In fact, it would be even preferable to be able to customize everything by myself without open up the website's development environment. In other words, whichever solution we choose needs to have a system to manage content easily. Oh wait, did I just ask for a Content Management System? Yes, but specifically, a flat-file content management system.
Definition of flat file : This refers to computer files that do not require any special program to read them. All you need is a simple text editor (like notepad on Windows) to open it, make some changes and save.
I'll list down just the most popular frameworks:
|Node.js||Gatsby, Phenomic, React Static|
Why choosing a framework should not really matter
Things like analytics and component re-use should be considered before making a framework decision. This would relate to how "extensible" the framework is in doing whatever you intend to accomplish. However, there is an overarching factor for consideration. How are you going to load your content into the framework? If you are going to couple your content tightly with your framework, then you're going to have a bad time in any case, whichever framework you use.
Think about it... What if critical support for your framework has dropped, and you need to quickly switch out the underlying method that your website is built. What should you do? If you have coupled your content too closely together with the framework's way of doing things, you will find it very hard to untangle all the parts from your content.
As the Clean Code Blog explained it, any software architecture should always separate your business logic from your frameworks. Meaning, that all your content (your business logic) should be decoupled from your framework and you should be able to even use multiple frameworks together with your content. Whether you decide to use Sphinx, or Hugo, or whatever framework from whatever language, it should not even matter. So long as you can parse the content files into html content and metadata, you're good to go.
I'll explain more in another post about decoupling your content with your framework, but for now, just choose a dang framework already.
In the end, I decided to go with react-static, mostly because I like how simple the configuration is for pulling in data, and because I like writing my UIs in React, with the optional for the occasional dynamic web component. However, I felt that there was not much structure to how I should go about decoupling my content with the framework. This gave birth to Barebones Static, a simple starter template that uses a git markdown repo as a simple CMS and Tailwind CSS for styling. More on this project soon.
If you're still at a loss of what to choose, just think about it: All frameworks has its pros and cons, but don't you think you're wasting even more of your valuable time trying to evaluate them all?