My journey into development started learning scripting languages like HTML, CSS, and Javascript back at my school. Before any of it made a complete sense of what it is, I was pushed into learning, memorising, and regurgitating syntaxes, maximising understanding of patterns etc.

This created a lack of actual sense of what programming, frontend, backend, in itself mean and are, and how to make sense of the system of web development. Nonetheless, I built a dummy website with vanilla HTML, CSS, Javascript. One thing I did learn was the knack of breaking things down, and learning while creating actual projects.

One such project was to build a dummy / vanilla CRUD app, a fundamental unit of web-development. Think a basic blog, notes app, todo list app.

Essentially the idea is that the four fundamental actions of creation, reading, updating, and deletion of a said entry within the database layer that are communicated through a frontend using APIs.

I tried to rush through things, trusting my half-baked, working knowledge of basic HTML, CSS, and Github.

I used three distinct approaches to do it, each more complex and convoluted than the previous, only to realise that building anything on the web requires grounded, un-rushed, and dedicated effort. It is a branch of said the proverb - One cannot learn swimming by reading a book, they need to do it, metaphorically, literally enter the waters.

The approaches I used:

1. Using different Static Site Generators - Starting with Hugo, and one of its themes, “Hextra.”

2. Integrating an open-source, “Headless” CMS within my portfolio website to integrate a writing pipeline and a blog.

3. Using Eleventy - basic blog starter template with Netlify

Failure 1 // Static Site Generators / Hugo + Hextra, Astro

1. I was blown away with the aesthetic of the Hextra theme, supposedly based on the Nextra.Js library

2. I forked the library, used a starter template, and started setting it up from scratch.

3. Understood and learnt about different concepts when it comes to SSG, and how they function

4. Content (what a page is)

   1. Page, Front matter, Metadata, Content body (Markdown content), Slug, Taxonomy (tags, categories), Section / Content type, Summary / excerpt

5. Presentation (how it’s rendered)

   1. Template / Layout, Base template, Block, Partial / Component, Shortcode, Render hook, Theme

6. How is the structure & navigation (how content is organized), table of contents, Page contents, Scroll to top fields function within Hugo

   1. Permalink / URL path, Menu, Navigation, Table of contents (ToC), Pagination, List page (node), Single page

While the framework enabled me to publish a blog that was better than a generic notion page, it was not ideal, and interesting enough to serve as my personal identity.

Failure 2 // There is beauty in a CMS

I got to know about the concept of something called a Content-Management-System(CMS) as well as a headless CMS. The idea that I will be using a pipeline to both, write, serve, and publish content blew me over, because now I can connect my pipelines properly and ensure that I only need to work and write in markdown, and ensure the content is served in a componentized manner → via a frontend, in a preconfigured and rendered style.

Little did I know that what I was about to do requires quite a lot of Authentication setup + using GitHub tokens, and I know nothing about setting it up.

What is an authentication system within a CMS? Why does it matter?

A CMS(or any real world system with more than 2 users who is not your friend/brother) has a roles based cascading access, which functions somewhat on the idea of least-privilege, ensuring that no untoward access is let-loose / or there is breach of trust, leakage, seepage.

Hence there was an admin panel, which the admin could control to ensure that only specific people are able to access the source code, write and publish within the blog.

To access my own admin panel, for my own blog, I had to create a system of tokenized access (since I don’t really have the ability to build my own Access Control mechanisms) by using a proxy / service. I decided to use GitHub.

The flow is simple,

User → Identity Provider (GitHub) → Authorization Code

The said code is matched with the backend, and this action is performed by GitHub, providing an access token for a set session/interval.

The further token is utilised by the correct user who can read, write, and interact with the system and the code.(In my case, the blog pipeline)

But I could not set it up. I was not able to understand the specific error contexts of why a certain action was failing when it was. Despite generating the authorization code, and the token, I was not able to access the elusive admin panel, for my own blog.

Hence I decided to give up, and write in HTML blocks itself.

Failure 3 // CI/CD Pipelines with Eleventy

One of the clear breakdowns that happened was in going beyond the working knowledge of a “git push to origin —main” and wild forays into what are branches.

1. What does a basic CI/CD pipeline look like? How does that function,and whether it is really necessary for the project that I was working on.

2. But the really cool part was finally being able to build two different branches, a working branch, a staging branch, and a production branch. Being able to use Netlify to see the deployments on the preview / staging branch, creating a PR, and merging it with the main.

1. The content structure within 11ty was not far different from that of Hugo, with similar notions of Frontmatter, Slugs, Metadata, etc.

2. The NPM → Local build step, to actually assemble a simple workflow of at every action, being able to run the deployment, see the preview, approve it, and merge it with prod. While it might sound quite basic, looking at it successfully running was really the best part.

These frameworks, and systems are essentially great scaffolding but put limits through the context.It is an amazing technology, and all these tools are really well developed, sophisticated integrations, but it is not really a job of a single person to implement these systemic solutions, in half an afternoon, and hope things get running on its own.

At the end, I was left wondering whether a plain HTML, CSS + Javascript approach is the best, and that is when I decided to take a pause, and simply use Google docs, and Substack.

Maybe I can’t learn swimming by reading a book, but indeed, after taking the first jump, I can keep trying to stay afloat. Who knows when I actually succeed at building a blog, I’ll look back at this article in jest.