iNKOBAN.net

I wanted to make my own special website. Most developer portfolio sites look identical, featuring nearly the same template, the same cards, the same dark-mode hero. They communicate technical competence but nothing about the person behind the site. While neat-looking, I felt as if I couldn't express myself or convey my personality through that standard way of building a site.

There's a certain class of knowledge you can only acquire by doing the work yourself. I started this website with just three hours of HTML/CSS experience, and within two hours (and the magic of Flexbox), I'd built the first ever version. CSS layout, event delegation, browser rendering, serverless functions - these concepts click into place when you're the one fighting with them at 2am. Building iNKOBAN.net from scratch was a deliberate act of self-education.

I grew up on the early web - simple as! At some point, modern designs become repetitive and homogenized - vibecoded websites, even moreso - so I began looking to the past to sate my desires for authenticity. These old interfaces - phpBB forums, Flash portals, ancient directory pages - were functional, dense, and full of personality. Recreating them with modern browser capabilities became my own personal vehicle for mastering HTML, CSS, and JavaScript.

Zero dependencies for this project. I'd started with 3 hours of experience in HTML/CSS and only one (1) in JavaScript. Having gained more experience in these languages, I wanted to understand what React abstracts away before reaching for it. Every DOM manipulation in newshoes.js uses native APIs: querySelector, addEventListener, cloneNode, classList. The per-page theming works through CSS cascade ordering - where style.css loads globally, then navbar.css, then each page's own stylesheet last. Because page-specific rules load last and are scoped via a .page-* body class, they naturally win specificity battles without !important or resets. Each page defines its own set of CSS custom properties - the blog has 25+ tokens for its phpBB steel-blue palette, projects defines 30+ with --proj-accent: #ff6d00, portfolio has its warm tan and indigo scheme. Zero color leakage between pages - hopefully!

The 11ty migration was a constraint-preservation exercise. I had a working site with carefully crafted layouts, and I needed to wrap a build system around it without changing a single rendered pixel. Nunjucks templates replaced the copy-pasted navbars and footers, but the actual page markup stayed mine. The blog collection uses a two-tier sort I'm particularly pleased with, where the sticky posts bubble to the top via a frontmatter flag, then within each group, posts sort newest-first. Draft filtering checks ELEVENTY_RUN_MODE === "serve" rather than NODE_ENV, which I'd learned after discovering that 11ty never sets NODE_ENV itself. The musings collection is fundamentally different: it sorts by a manual order field, not date, because that content is curated by hand. A custom forumDate filter produces phpBB-style timestamps like "Sat Feb 01, 2026 4:20 pm" - and it accepts an optional time string to handle posts that don't have a meaningful time.

All five endpoints share a single KV namespace (env.POLL_VOTES) with key prefixes doing the organizational work: poll:*, views:blog:*, counter:*:total, gb:entry:*, online:*:*. I considered separate namespaces but the prefix convention keeps things simple and the free tier limits one namespace anyway. The guestbook endpoint uses constant-time admin key comparison - XOR byte accumulation rather than early-return string equality - to resist timing attacks. Rate limiting hashes the cf-connecting-ip header with SHA-256 and stores it as a KV key with an 86,400-second TTL. When the TTL expires, the key auto-deletes, so I don't need to have a cron job to delete the expired rate limit keys. The online presence system works similarly: each visitor session gets a UUID stored as a KV key with a 600-second TTL. Counting online users is just counting keys under the online: prefix, so all the dead sessions evict themselves. View counter increments use a read-increment-write pattern with no transactional guarantees, which is fine for vanity metrics and explicitly not fine for anything financial.

The deployment story is deliberately boring. A git push to main triggers an 11ty build on Cloudflare's infrastructure, outputs static HTML to _site/, and deploys it alongside the Pages Functions in a single atomic pipeline. Branch previews mean I can test a new blog post layout on a real URL before merging. The entire hosting cost is zero dollars (besides paying Cloudflare for the domain). I don't need to maintain nginx configs, manage a server, or run any other infrastructure for this site. Babysitting servers would be a huge time sink and a source of potential outages and maintenance headaches for a personal site...

Starting this website with just three hours of experience in HTML/CSS was a disaster in terms of tech debt! My design philosophy and structure decisions early on created a lot of work to fix and refactor later as the site grew. You can see the remnants of such in the "Classic" theme! The visuals, too, were not consistent on the same page. I had to burn the midnight oil to go through each page and fix inconsistencies in spacing, typography, and other visual details to get things looking right. Tech debt! The JavaScript is also a bit of a mess from those early days, with some patterns and approaches that I would not use today but that I had to live with and refactor as the site evolved. 1500 lines of code is NOT what you want to see in one file.

I came in thinking CSS was the easy part! I left knowing it deserves the same architectural discipline as any other system - with all the design tokens, cascade strategy, and specificity management. All of those things matter the moment you have more than two pages. The Win98 shadow system and per-page scoped variables are direct results of getting this wrong first.

The site launched as flat HTML files because I wanted to understand every byte. That was the right call early on... but by page four, updating the navbar meant touching six files. Migrating to 11ty proved to be an even greater hassle than trying to fix the byzantine code I'd made! Having to rewire the templates, partials, and data structure to get the site to build correctly with 11ty ended up being a huge undertaking. However, I deliberately wrote the blog code in a way that would make it easy to migrate into 11ty, so that part of the site would continue to work with minimal changes after the migration.

KV is eventually consistent, which matters for view counters under concurrent load. Functions run at the edge, not in a traditional Node.js environment so certain APIs don't exist! However, the edge environment gives you other capabilities and constraints that you have to work with, and learning to reason about those constraints and the distributed nature of the system is part of the learning curve of serverless.

Nothing I read about web performance prepared me for the moment I checked my own page weight. Nothing I read about accessibility prepared me for screen-reader testing on my own markup. Shipping the site and seeing the results in the real world taught me lessons that reading alone never could. Just do things!