I was using Claude, ChatGPT, Cursor, and others… All of them at once. Each of them has its pros and cons, each of them is best at something, and they all have some gaps that another one fills beautifully. However, the bills just started piling up. And it’s not like I could just cancel one of them because I kept hitting the limits of the max plans on all of them. At some point, it became clear that paying “rent” for AI was unsustainable long-term. So an investment was made to become somewhat independent.

When I was thinking of starting this journey, I had a great discussion (as always) with Joost de Valk, and as a result of that discussion, the initial (substantial) funding for this journey was from my employer, emilia.capital. I then continued by expanding the build with more compute over the course of months - and I fear it’s not done yet 😅

The Hardware

• CPU: AMD Ryzen 9950X
• RAM: 64GB (2x32GB)
• Motherboard: Asrock X870e-Taichi
• GPUs: 4x Radeon AI PRO R9700 (32GB each) + 1x RTX3090 (24GB) for a total of 152GB VRAM
• NVMe: 4TB for storage and models + 1TB for the system.

I started with 2x R9700 GPUs. Over the course of the following months I managed to get 2 more R9700 GPUs (one every couple of months) and a used NVIDIA RTX3090.

Of course they can’t all connect to a motherboard with just 2 PCIe ports, so the 4 AMD GPUs are now connected to a bifurcation card (R34A), and the RTX3090 is connected to an M.2 slot via an M.2-to-OcuLink-to-PCIe adapter.

Future expansion: I can still connect 2 more GPUs: One on the remaining M.2 slot, and another one via USB4. I already have the adapters for these, just not the GPUs yet - looking on Vinted daily for opportunities.

The reason I went with AMD and not NVIDIA is twofold:

1. Price. The obvious one! An NVIDIA RTX 5090 cost ~€5-6k for 32GB of VRAM. An AMD R9700 cost somewhere between a 3rd and a 4th of that, for the same amount of VRAM. The RTX3090 I got was used from Vinted and I got it for €800.
2. Power consumption. The AMD GPUs are simply not as power-hungry as NVIDIAs.

Would it be better to go for NVIDIA GPUs instead of AMD? Well… I would definitely have a faster system, but I would pay for it many times over in the electric bill, and performance is not the only metric that matters. There are lots of ethical concerns in the middle too.

Pros: Lots of VRAM.

Cons: vLLM is basically pointless on this setup. PCIe speed has dropped significantly due to the bifurcation and all the adapters, which means that tensor-splitting a model is painful. My router (explained below) can run vLLM/safetensors backends but due to the way my hardware evolved I don’t bother (not to mention that ROCm made running vLLM a PITA). Instead, I’m using llama.cpp with Vulkan (not Cuda for the NVIDIA + ROCm for the AMDs, that was painfully slow).

The Software

This is where things get a little more interesting. Had to build a couple of projects in order to accommodate my personal workflow.

ergon.studio

(Link to GitHub repo)

This is a plugin for OpenCode which does the following:

Agents

The plugin adds multiple agents and sub-agents. Some of them are public-facing, others are internal only.

The way I usually work is this:

• I use the scout agent for discussion, brainstorming and planning. Tried to make it think a bit like I do when planning, so it’s a multi-step process. Kinda crude, but it works.
• Once a plan is finalized, I switch to the orchestrator agent which handles the actual implementation and coding. The orchestrator calls multiple sub-agents as needed, and also implements a best-of-N flow when needed.

These are the main agents, the others are mostly internal:

a team of specialists (architect, coder, reviewer, tester, critic, researcher, design-reviewer, quality-controller) that the orchestrator delegates to. The one I’d single out is the quality-controller. After any coding task, the orchestrator has to run it - it bundles the reviewer, the design-reviewer and a completion checklist and returns either APPROVED or REJECTED. The orchestrator can’t skip it, and after 3 rejections it stops and asks me what to do.

Memory Steward

Memory usually fails in coding harnesses because the agent needs to judge when to call memories, when to save a memory etc. It’s a fragile thing.

The memory-steward does something slightly different: It has a small model running at all times (currently it’s a qwen3.5-4b model but that’s easy to change from the markdown file of the steward). The key idea is that the main coding model never has to decide anything about memory - the steward handles both sides, retrieving and saving.

What basically happens is this: When I send a message to OpenCode, it doesn’t go directly to OpenCode… It goes to the memory-steward service first. The steward rewrites my message into a tight search query, looks up relevant memories (via a memory MCP - currently OpenMemory, but it’s easy to switch that), and injects whatever it finds into that turn’s context before the main model ever sees the message. This happens on every single turn.

The rewrite step is more important than it sounds. Memory lookup is an embedding search, and embedding search is surprisingly sensitive to phrasing - two messages with the exact same intent but worded differently will land in different places. If I search with my raw, rambling message, I get worse hits than if I search with a clean 3-8 word query. So the steward’s first job is to strip my message down to what I’m actually looking for, then search.

Then, after the exchange is done, the steward looks at it again and makes a separate judgement call on whether anything in it is worth saving. If so, it writes it back to the memory MCP. So retrieval runs constantly in the background, and saving is a deliberate, judged decision - and neither one depends on the main model remembering to ask.

Scratchpad

Local models that can run on my hardware don’t have 1M context, so I need to account for that - as well as preferences persistence on a per-project basis.

The scratchpad is a simple skill that does exactly what you’d expect: It’s a scratchpad, allowing the LLM to write to a file things we’ve discussed so that they stay pinned. It’s also used for internal notes of the LLM itself. Scratchpad notes are appended to the system prompt so the model can always see them.

When OpenCode trims the conversation to stay under the context limit, the scratchpad gets re-injected, so the things I pinned survive the compaction even though the rest of the conversation got summarized away. That’s the whole point - it’s the bit of context that doesn’t get thrown out.

Handoff

This is just a handoff document that allows me to switch between agents and persist long sessions.

Think of it like the plan documents that Claude creates. Same concept, different implementation.

This is just another skill file. When I make a plan with the scout agent, it writes the handoff document. When I then switch to the orchestrator agent, it reads that file and starts the implementation.

Inference-router

(Link to GitHub repo)

Too many models, too many configurations, it’s hard to keep track of everything. I needed to be able to easily load multiple models in VRAM, switch between them easily, be able to edit the configs from a web-UI and so on. This project does something similar to what llama-router does, but more tailored to my own flows. It is a fully transparent proxy, and basically instead of pointing my OpenCode config to llama.cpp directly, I point it to this project instead.

• Web UI to manage the models
• Allow setting aliases for models. This way I can have a “coder” or “brainstormer” alias, and just assign it to a model that is already in my config. Small but important convenience because it allows me to just define 4-5 “models” in the OpenCode config, and then manage how they are assigned from the web-UI. The alternative would be to have 20-30 models in the OpenCode config and navigate those. Tried it for a few months - not convenient. This allows me to be more flexible without breaking anything.
• Infinite loops recovery. This one is important and saved me lots of frustration. Some models are amazing (qwen3.6-27b for example), but occasionally they fall into infinite thinking loops or infinitely looping tool calls. The inference-router handles both, with two separate guards. Thinking loops are caught by a streaming detector that watches the output for repeating text (a tandem-repeat detector running on the token stream); when it trips, it replays the partial output and injects a corrective prompt, then retries. Looping tool calls are caught by a separate cross-turn guard that watches for a repeating tool_call → result → tool_call pattern across messages. The injected nudge isn’t subtle, and it escalates if the model keeps looping - the first interrupt asks it to step back and identify the real next action, and by the third it’s down to “emit only the next required action, no thinking, no commentary”.
• Speculative decoding. The router supports both MTP draft-heads and external draft models (plus context checkpoints for the hybrid-recurrent Qwen3.5 models), to improve performance for the models I use most.
• Automatic VRAM management. It’s not just “load a model” - it reads the GGUF metadata, estimates how much VRAM the model needs, and evicts idle models under pressure (scored by how long they’ve been idle and how big they are). It also auto-generates the --tensor-split to greedily fill across the GPUs, so I don’t have to hand-tune placement every time.
• Per-model replicas for concurrency. One instance of a model is fine for a single stream, but throughput suffers when several agents hit it at once. So when a request comes in and every running instance of that model is already busy, the router spins up another full instance (its own process, its own port) and sends the request there - idle instance first, otherwise the least-busy one. It keeps scaling out until it hits either a per-model cap I set or the VRAM ceiling, then new requests just ride the least-busy instance. Lets me run several agents against the same model without them choking a single process. Useful since ergon.studio & OpenCode make heavy use of sub-agents.
• Mixed-vendor GPUs. My rig is 4x AMD + 1x NVIDIA, and the router enumerates all of them - AMD via Vulkan, NVIDIA via nvidia-smi, and even Intel Arc if I had one plugged in (I have one but it’s on a different dedicated assistant device - so I know it works). The same physical card can be addressed as either a CUDA device, a ROCm device, a Battlemage device, or a Vulkan device depending on what I want a model to use. Some models run better on ROCm in AMD GPUs, others (most) run better on Vulkan, CUDA makes the GPU fans go nuts while Vulkan is more quiet and so on… So I can define the backend on a per-model basis.
• Binary presets. I rebuild llama.cpp constantly (new commits, new flags, experimental branches). Instead of editing the binary path on every single model whenever I rebuild, I define the binary once as a “preset” and point models at it. Rebuild, update the preset, and every model picks up the new build automatically.

orchestrator - the one that started it all

(Link to GitHub repo)

Before any of the above existed, there was this. It’s worth mentioning because it’s where the whole journey started, and because the idea behind it is still useful on its own if you’re not ready to go fully local yet.

Back when I was still paying for Claude, ChatGPT and the rest, the thing that seemed insane was paying frontier-model prices for grunt work. Generating boilerplate, applying a review’s feedback, writing tests, reshaping a JSON config, or simple repetitive tasks… none of that needs a frontier model. Nobody needs a frontier model for simple stuff.

So the idea was simple: keep the expensive model as the senior engineer who thinks, decides and verifies - and delegate the mechanical work to local models, at zero marginal cost.

In practice it’s an MCP server. You register it with Claude Code (or any MCP-compatible agent) and it exposes the local models as a set of tools: generate_code, edit_code, improve_code, simplify_code, generate_tests, review_code, plan_task, transform_json. Claude stops writing code itself and instead orchestrates: it plans the task, hands the actual typing to a local coder model, sends the result to a local reviewer model, feeds the review back for a fix, and only then verifies the result itself. The frontier model goes from writing every line to making decisions about lines other models wrote - which is a lot fewer tokens, and a much smaller bill.

It worked well enough that the obvious next question was: if the local models are doing all the real work anyway, do I even need the frontier model in the loop? That question is what led to ergon.studio and the fully-local setup. So orchestrator was a stepping stone - but a genuinely useful one, and if you’ve got some local compute lying idle and a Claude bill you’d like to shrink, it’s a low-effort way to do exactly that.

IMPORTANT NOTES:

1. I haven’t used that project in quite some time. Some things are hardcoded (like for example the models slugs etc), so you’ll probably need to edit a couple of things to make it suit your needs.
2. Claude, ChatGPT etc have to make a “conscious” decision to actually use this MCP. Most times they don’t. So if you use this project (or a concept similar to this project), you should also add a couple of lines in the CLAUDE.md/AGENTS.md etc files to force them to delegate tasks.

Can local, open-source models really do what frontier models can?

Well… Yes and no.

Frontier models are genuinely amazing. An open-source model with a few billion parameters cannot compare to a frontier model that is (probably) trillions of params!! However, the harness is sometimes more important than the model itself. Think of it this way: You have a brilliant person on one hand, and an average one on the other hand. You can tell to the brilliant person “build this”, and they will. They will make lots of assumptions along the way, lots of things that you probably won’t like and won’t catch. The end result is usually great and they work FAST! And then you have the average person. The one that needs hand-holding. That’s what the harness does… it’s the handholding part. That’s what the scout agent for example does in ergon.studio when I want to make a plan! It breaks the process down into steps:

1. Imagine the optimal solution without being tied to the current codebase
2. Strip it down, remove all the inherent over-engineering fluff that LLMs usually add
3. Compare to the current codebase, find how we can achieve the “ideal” we imagined, what needs to happen to the codebase
4. Start making a high-level plan. Start from the goal and work backwards. No specifics, just the overarching architectural decisions etc.
5. Iterative zoom-in. Start from the abstract plan and zoom-in, one step at a time, making it more specific
6. Find the friction points, risks, uncertainties, etc. Define them, find solutions to issues BEFORE they become a problem.
7. Make the plan
8. Assume you’re wrong. Review the plan, look at things more holistically, and iterate.

These are steps that I specifically defined, in order to make the average person produce code that is on par with a frontier model.

Does it work? Yes, it does. However, you need to adjust your workflow significantly. With a frontier model you can build projects with one-shot prompts. You give them a goal and they start working towards that goal. With local models you can’t do that efficiently. I mean sure you can, but not if you want genuinely good results. So my current workflow is not “one-shot” builds. I am the senior engineer, the LLM is the junior. I know what I want to accomplish, I have the architecture in my head, the LLM helps write the code one step at a time. I don’t make a grand plan, I make smaller plans, one at a time. The grand plan lives in my head, the LLM gets parts of it. So I have for example 3 terminals open:

1. An OpenCode session where I have a high-level discussion with the LLM about the overall architecture and what I want to achieve. This is using the scout agent from ergon.studio. No touching code, just a freeform discussion.
2. An OpenCode session where I’m working on the current task (running the orchestrator agent from ergon.studio) - this one does the actual coding on the current task. The orchestrator reads the HANDOFF.md file that is already on-disk, and works on it.
3. An OpenCode session where I’m planning the next step in the grand plan. This is again using the scout agent from ergon.studio. Discussing, finding the best solution to what we want to achieve, then once session #2 finishes we write the plan to the HANDOFF.md file, session #2 starts working on it, I reset session #3 and start discussing the next step in the grand plan.

So yes, local models can actually accomplish what a frontier model does - just not using the same mental model or process.

Keep in mind that local models get released quite often… this is what makes this really exciting for the future!

The limitations I faced and all the things I needed to do to get around them are because of the current state of OSS LLMs. It was different 6 months ago, and it will be different 6 months from now. Friction keeps reducing, and you can think of OSS LLMs as the frontier models from 6-12 months ago. We were doing lots of things last year with Claude, right? Since then Claude has moved on… But we can get similar intelligence to last year’s Claude with Qwen3.6-27b and others today - or whatever you can run locally. Want to use Claude Opus 4.8? Sorry, can’t do unless you have the budget for half a TB VRAM. Then you could probably run HUGE local LLMs that are really frontier and on par with Opus.

That’s all for this post, hope it helps someone. When I started this journey most of this stuff did not exist, nowadays you can probably find multiple similar alternatives to what I did - but regardless, it was worth documenting these.

This post was written by a human.

I hereby pledge to share and release everything I build openly.

All my products will cost you $0.
when you download something I’ve built, it has already been paid for. The cost will be covered initially by me with the time I’ve spent to built them, and if you want to donate something and pay it forward for the next person who downloads that product, feel free to do so. That way you spread some goodness and help me sustain these products, evolve them, and build greater things that will benefit more people.
To that end, I have created a GitHub Sponsors page and a link to that page will be added to all my future products.
Hopefully, at some point, the time I spend to build the things I build, do the things I do for the community, and help the people I help, will be offset by your contributions.
Any premium products I already have will be open on GitHub for everyone to get and use.
The only exception to that are a couple of projects where I use ACF-Pro. Obviously I can’t give that because it’s not mine to give, but that’s just a temporary exception to the rule due to technical difficulties. A solution will be provided to that in time for those that already have a license to one of these products.

What Gutenberg Generates

The default HTML generated by the WordPress editor looks something like this:

<div class="wp-block-columns">
    <div class="wp-block-column" style="flex-basis:33.33%">
        <p>Column 1</p>
    </div>

    <div class="wp-block-column" style="flex-basis:66.66%">
        <p>Column 2</p>
    </div>
</div>

The accompanying styles relevant to what we want to do here:

.wp-block-columns {
    display: flex;
}

What it does is pretty clever and elegant(ish), but depending on what you’re working on it may not always be the best solution. If the theme you’re working on has a relatively simple layout then getting things to work properly is a piece of cake. However if you have a more complex layout then flex may not be the best choice, and the reason is padding. If columns don’t have a padding, then there will not be any space between columns. I’ve seen themes use padding, margins, for a while I even user this:

.wp-block-column {
    border-left: 0.5em solid transparent;
    border-right: 0.5em solid transparent;
}

The above code will add an extra 0.5em border on the left and right of your columns, therefore separating them and creating a “gap” between them. The problem however with solutions like that is that they add additional space on the left and right of all columns, therefore making the contents of your columns narrower and they don’t line up vertically with the rest of your content. If you can add a left margin on the .wp-block-columns element and just make it larger by 1em then you’re OK. But what if you can’t?
See, flex is OK, but in some cases using grid makes more sense. For columns the benefit of grid is the css-gap property.

Unfortunately I haven’t found a filter or anything like that that would allow me to change the egenerated markup. We’re a bit “trapped” by a limited system.
The only available alternative is to use JS to change things.

Here’s some code you can use:

function griddConvertColumnsToGridLayout() {

    // Get all column-wrappers.
	var griddColumns = document.querySelectorAll( '.wp-block-columns' );

    // Loop column-wrappers.
	griddColumns.forEach( function( columnsWrapper ) {
		var columns = columnsWrapper.childNodes,
			gridTemplateCols = [];

        // Loop columns.
		columns.forEach( function( column ) {
			if ( column.style.flexBasis ) {
				gridTemplateCols.push( 'minmax(300px, calc(' + column.style.flexBasis + ' - 0.5em))'  );
			} else {
				gridTemplateCols.push( 'minmax(300px, 1fr)' );
			}
		});

		columnsWrapper.style.display = 'grid';
		columnsWrapper.style.gridTemplateColumns = gridTemplateCols.join( ' ' );
		columnsWrapper.style.gridGap = 'calc(1em';
	});
}
griddConvertColumnsToGridLayout();

The above snippet (taken from the currently alpha version of the Gridd 2.0.0 theme) is vanilla JS and will convert your columns to use a grid layout.

Of course if you use that you’ll also have to take into account mobile visitors and make sure that columns collapse by adding some CSS:

@media screen and (min-width:600px) {
    .wp-block-columns {
        display: flex; /* block also works fine. */
    }
}

With all the good things it brought, there were (and still are) some difficulties, mostly regarding the way we can style things - both in the editor and the frontend. This post is about one of the many solutions that you can implement, depending on your layouts.
If your theme doesn’t have a sidebar and instead the content is the whole viewport-width, then things are pretty simple. In the Gridd theme however there is no standard layout. Users build their own grid. A site may be just a logo on the top and then the content, or it can have 4 widget-areas on the sides. And therein lies the problem:
How can we account for ALL cases?

What Gutenberg generates

I created a dummy post with all the cases I could think of at the time, so this is what we’ll try to accomplish:

First of all we have the Gutenberg-generated HTML:

<div class="my-container">
  <div class="entry-content container">
      <p class="has-background has-very-light-gray-background-color">Normal content.</p>
      <div class="wp-block-group alignwide has-very-dark-gray-background-color has-background">
          <div class="wp-block-group__inner-container">
              <p class="has-text-color has-very-light-gray-color">Wide content.</p>
          </div>
      </div>
      <div class="wp-block-group alignfull has-vivid-red-background-color has-background">
          <div class="wp-block-group__inner-container">
              <p class="has-text-color has-very-light-gray-color">Full-width content.</p>
          </div>
      </div>
      <div class="wp-block-button alignleft">
          <a class="wp-block-button__link">button floating left</a>
      </div>
      <p>Text next to the button.</p>
      <p>Some more content here.</p>
      <div class="wp-block-button alignright">
          <a class="wp-block-button__link">button floating right</a>
      </div>
      <p>Some more text</p>
      <p>and yet some more to show the button float.</p>
  </div>
</div>

The wrapping my-container element there is just our theme’s wrapper for the content.

Styling

In the code above we can see a lot of classes, most of them color-related. I added them when editing the post to make it clear in the screenshot what each element is and what its dimensions are. But here are the important ones and what they should do:

• .alignwide makes an element wider than the normal content.
• .alignfull makes an element span the full width of its parent container.
• .alignleft floats an element to the left - while still keeping it inside the constraints of the “regular” content’s width
• .alignright - similar to .alignleft, but obviously floating on the right side.

What we need to accomplish:

• We want our normal content to have a maximum width of 50em.
• Elements that have the .alignwide class should be 25% wider than normal content.
• Elements with the alignfull class should be 100% of their container.
• We also want a padding on 1em on the left & right of our elements, otherwise on mobile they’re going to stick to the edges of the window.

Let’s start by defining some variables, and add the padding to our container:

.my-container {
    --padding: 1em;
    --content-width: 50em;
    --wide-diff: 25%;
    --wide-width: calc(var(--content-width) * 1.25);

    padding: 0 var(--padding) 0 var(--padding);
}

Normal elements

Next up, we can start adding styles for elements that should have a normal width:

.entry-content > :not(.alignfull):not(.alignwide):not(.alignleft):not(.alignright) {
  max-width: var(--content-width);
  margin-left: auto;
  margin-right: auto;
}

The above is fairly simply: For all elements that are direct children of our main container, if they are not alignfull/alignwide/alignleft/alignright we’re adding our content-width css-variable as the element’s maximum width. Once we do that, we notice that the element is on the left of the screen, so we’re adding the margin-left and margin-right lines and set them to auto. This way our element gets properly centered.

.alignwide elements

Moving on to the “wide” elements:

.entry-content .alignwide {
  width: calc(var(--content-width) + var(--wide-diff) + 2 * var(--padding));
  max-width: 100%;
  margin-left: auto;
  margin-right: auto;
}

This here is a bit more complicated: To calculate the width of our element we’re adding the --wide-diff var to our content-width, and then we also add the padding (doubled since it exists both on the left and right of our container).

.alignfull elements

The “full” elements are not without their difficulties too:

.entry-content .alignfull {
  transform: translateX(calc(0px - var(--padding)));
  width: calc(100% + 2 * var(--padding));
  max-width: calc(100% + 2 * var(--padding));
  margin-left: auto;
  margin-right: auto;
}

For these ones we have to move the element to the left by the amount of our defined padding, and then set its width to be equal to 100% of our available space, plus the padding doubled so there’s no space on the left and right.

.alignleft & .alignright elements

Now that we’re done with the basics let’s move on to the hard part: Getting the floats right.

By default these are not restricted by the 50em we want for our content since they use float. As a result they will literally float to the edges of the screen. Well, not quite the edge, 1em from the edge ‘cause that’s the padding we have defined. So how do we get them to be within the limits of our invisible and theoretical “normal content” box?

The best solution I could come up with so far is this:

.entry-content .alignleft {
  float: left;
  margin-left: calc(50% - var(--content-width) / 2);
}

.entry-content .alignright {
  float: right;
  margin-right: calc(50% - var(--content-width) / 2)
}

The above snippet will add a left margin to elements that are floated to the left and a right margin to elements floated to the right, therefore displacing them visually and moving them to the place we need the to be. It’s counter-intuitive and I absolutely hate it. It’s an ugly hack that makes absolutely no sense. But it works (most of the time).

Got a better idea?

How do you handle this? Do you have a better idea? If you do, please let me know. I’ve been banging my head against the wall for a long time trying to find an elegant solution.

I’ve been thinking a lot lately about my future. What my goals are, my purpose, what my legacy will be. I’m 39 and not getting any younger.

I love my job and I work extremely long hours. I work my normal job, and then when that is done I work on my personal open-source projects, I learn new things, improve my skills and so on. On minimum I am in front of my laptop a minimum of 16 hours/day writing code or studying and learning. So my daily routine looks something like this:

• Wake up time varies, usually between 7am and 9am
• Take the dog for a 30-40 minute walk
• Take my octuple espresso (yep, that’s right… 8 espressos - preferably Guatemalan - in a tall glass with ice, no sugar)
• Get back home with my coffee and work my normal (paying) job
• Finish work & grab something to eat, usually while watching a tutorial or a tech talk.
• Start work on open-source & other projects until 1-2am
• Put on something stupid to watch on Netflix
• Fall asleep around 4am
• Repeat

On weekends I just skip the normal (paying) job and instead work 16 hours on my other projects.

I see my normal job and my open-source projects as different sides of the same coin. I can’t efficiently do one without the other… I learn things in my day job working with others that I bring to my side-projects, and all the work I put in my side-projects regarding web-accessibility and sustainability heavily affect the way I work on my day job, helping me make more responsible decisions there and improving the way I code.

The amount of work doesn’t really bother me, in fact I think I’d just go crazy if I stopped working. Even when not working in front of a computer, I’m still working on the back of my head. Plus - believe it or not - the extra work prevents the burnout effect because there’s a feeling of satisfaction and accomplishment from the side-projects that a normal job simply can’t offer. That shit is mine, I built it, it works and it helps hundreds of people, runs on tens of thousands of websites and other developers use the things that I’ve built to make a living. It’s arrogant and makes me feel good about myself.

I do get mini-burnouts though… I can’t work more than 6-8 hours on the same thing, my brain just gets stuck and I get frustrated. So every few hours I’m rotating my focus. I’ll work on issue A for a couple of hours, then switch to issue B, then back to A, then B or even C. After a certain point though, I’m done. I don’t know if the term exists but I’ll just call it focus-overload for lack of a better word. It’s a mini-burnout. After a while I end up staring at a screen and all I see is random letters and symbols without any meaning. While working on a project, you inadvertently build puzzles in your mind, and as a coder my job is to solve these puzzles. But they do pile up… each puzzle you solve is a smaller piece in a larger puzzle. Switching from one piece of the puzzle to another works ‘cause you’re shifting focus, but after working on a few pieces, you’re left with shattered unrecognizable fragments of a larger image you can no longer see. It’s the curse of big projects. When that “mini-burnout” happens (on a daily basis), that’s when it’s time to switch to another completely different project, with a completely different focus. It’s a fresh start. It’s a mental soft-reboot. All the puzzles I was trying to solve and had accumulated in my head get thrown away and I’m starting to work not on a different piece of the same puzzle, but a different puzzle altogether. A smaller puzzle. And then another. And another (and that’s one of the reasons I also decided to split the Kirki framework to smaller, self-contained packages, I can work on them more efficiently).

Here’s a question: What am I working for? Why am I torturing and slowly destroying myself? Is it so that when I’m old I can move to a house by the beach and live happily ever after until I die alone and someone finds me a week later half-eaten by the cats I’ll have in the garden? Why the fuck do I live in Athens instead of the countryside with a sea view?

I have come to terms with the idea that I will never have a family and that’s OK. I used to feel the need to have children, but I no longer feel that urge. If it happens it will be a bliss, but I am whole as I am, there’s no void I need to fill. So there’s nothing keeping me tied to a place, why am I not just moving someplace nice, by the sea, in a house with a garden where the dogs can run and the cats can come and go as they please, and I can plant my trees and do my gardening? Other people have their religion or their children to rely on. “When I die I’ll go to heaven”, or “my children are my contribution to this world”. What the fuck is my contribution? Is it my work? Is it the people I’ve talked to and interacted with all these years? And is my work all that will be left of me? Do I really want that? If so, it better be some fine piece of work.

I’m almost 40 which means that I’ve already lived more than half of what what I am expected to live, and I have maybe 10, maximum 20 years of work left in me (I haven’t seen any 60-year old developers, have you?) Plus the situation in my country is a bit weird. By “weird” I mean that I’m not going to be able to live with dignity after I stop working. The pensions are laughable and I don’t think I’ll even qualify for a pension when the time comes. See the problem is that for a great number of years I’ve been working for companies abroad, and that is not recognized as “working” years by my country. Employers in Greece are required by law to pay for the employee’s insurance, social security and so on. By working for companies outside of Greece, I automatically lose all these benefits and am left to fend for myself. At 65 I’ll get a pension of $300 if I’m lucky. So yeah… that’s probably one of the reasons that make me work this hard. I feel that I need to build something that will be able to sustain me so that I don’t starve to death in 20 years. Of course that’s assuming I make it to 60 and I don’t die from lung cancer ‘till then ‘cause I’m not only addicted to caffeine but also nicotine (but hey… at least I don’t drink alcohol, never liked it).

The only thing that’s really keeping me in Athens is my love for my brother and my baby niece. We live in the same building and yet I don’t see them very often, so basically I’m just staying here hoping that I see them more often. But is it really worth it? I’m not happy here and I know it. I feel I’m wasting my years closed between 4 walls. And of course that’s not really going to change if I move somewhere in the country, there will still be 4 walls and a laptop. But at least I feel I’ll have more freedom. Freedom to make better friends, go out more, be at the beach in 5 minutes if I so desire. And if I feel the need to be in a big city it’s only going to be 1h by train or car.

So… that’s something I’ll need to sleep on. When I finally manage to fall asleep that is, it’s already 3.30am.

Cheers.

Some background on why.

While working on an implementation for accessible colors in the twentytwenty theme for WordPress 5.3 I needed a way to get various color properties like for example hue, saturation, lightness, relative luminance, contrast with other colors etc. All that so we could calculate colors that are readable and comply with WCAG rules for colors.

Initially I started pulling functions from a wcagColors.js library I wrote a while ago for the Kirki WCAG Link Colorpicker and Kirki WCAG Text Colorpicker controls. But these controls were a lot more complex than what we were trying to accomplish in the twentytwenty theme, so those were a bit of an overkill. A simpler solution was required. Enter WordPress’s own Color functions.

Where are they?

The reason you may have never heard of them is because they don’t exist as a separate script. They should, but instead they’re just tucked away inside the iris colorpicker. They are available as a separate script on github.com/Automattic/Color.js but it’s been completely neglected, hasn’t been updated since 2015.

So how can you enqueue them?

Since they don’t exist as a separate script, to use them you’ll first have to make sure that the wp-color-picker script is enqueued. So you can simply add that as a dependency to your own scripts.

Usage

Unfortunately the code is very poorly documented, so to get an idea of what you can do and how you can use it, you’d have to read the source. Or you can just keep reading. :)

Getting properties of a color

First we need to instantiate the color:

let myColor = Color( '#cd2653' );

Then we can get the properties we need:

// Get red.
let red = myColor.r();
// Get green.
let green = myColor.g();
// Get blue.
let blue = myColor.b();
// Get alpha.
let alpha = myColor.a();
// Get hue.
let alpha = myColor.h();
// Get saturation.
let saturation = myColor.s();
// Get lightness.
let lightness = myColor.l();

The above are the basics, but there’s more! You can also get the relative luminance of the color:

let luminance = myColor.toLuminosity();

You can also get the WCAG contrast between 2 colors:

// Create background-color object.
let backgroundColor = Color( '#fff' );
// Create text-color object.
let textColor = Color( '#000' );

// Get the contrast between the 2 colors.
let contrast = textColor.getDistanceLuminosityFrom( backgroundColor );

If you want to get the color you should be using for your text depending on the background-color, there’s a neat getMaxContrastColor function that will return a Color object of either white (#fff) or black (#000):

// Get black/white Color object depending on background.
let textColor = Color( '#f2f2f2' ).getMaxContrastColor();

You can also automatically get a readable text-color:

// Create background-color object.
let backgroundColor = Color( '#fff' );
// Create text-color object.
let myColor = Color( '#cd2653' );

// Get a readable color, with a minimum contrast of 7:1
let readable = myColor.getReadableContrastingColor( backgroundColor, 7 );

The above is not what was used in the twentytwenty theme because we needed something a bit more customized than that, but the above method also works perfectly fine.

Manipulating colors.

Retrieving color values is not the only thing you can do, you can also use this library to manipulate your colors.

The following functions are available:

• darken
• lighten
• saturate
• desaturate
• toGrayscale
• getComplement
• getSplitComplement
• getAnalog
• getTetrad
• getTriad

You can also use the r, g, b, a, h, s, l methods I mentioned above in the example for retrieving a value simply by defining a value inside them:

// Darken color by 30%:
let myColor = Color( '#cd2653' ).darken( 30 );

// Change the red value.
let myColor = Color( '#cd2653' ).r( 50 );

Cloning an object

If you don’t want your calculations to be applied in-place but instead want to apply them to a clone of the object so that you can still have access to the unmodified object, you can use the clone method:

let background = Color( '#fff' );
let otherBackground = background.clone();

Getting the CSS value from a color object

Easy, just use the toCSS method:

let background = Color( '#fff' );
background.darken( 30 );
let newValue = background.toCSS();

Chaining

You can chain multiple functions to get what you need faster. In the example below we’re getting the complementary color or our original value, then darkening it by 30%, desaturating it by 10% and returning the CSS value:

let newColor = Color( '#cd2653' )
    .getComplement()
    .darken( 30 )
    .desaturate( 10 )
    .toCSS();

Read the source

The above are nothing but scratching the surface, there’s a lot more you can do. I suggest you read the source of this neat little gem. It may not be properly documented, but the functions and parameters have very descriptive names so it’s easy to understand.

A big thank you to Matt Wiebe for building this. It’s been a long time since you did this, but it’s still amazing.

Using CSS-Variables (aka Custom Properties) is not necessary, you can achieve the same result fine without them and I’ll also be showing an example of that.

First of all, the code we’ll be talking about:

:root {
  --base-font-size: 12px;
  --fluid-typography-ratio: 0.9;

  --rem: calc(var(--base-font-size) + var(--fluid-typography-ratio) * 1vw);

  font-size: var(--rem);
}

The above is a simple technique that allows the font-size of your site to be readable no matter the device used. In fact that is the exact code used on this site.
Now to explain what that code does:

First we’re defining 2 values: --base-font-size, and --fluid-typography-ratio. Feel free to tweak these values to achieve the result you want, these 2 are responsible for the rest of the site and calculations.

Next we’re defining the --rem variable.
This is a value that gets calculated from the font-size and typography-ratio we defined.

If you’re reading this post on a device that has a screen-width of 500px then the font-size will be calculated like this:

12px + ( 500px / 100 ) * 0.9 = 17px

The ( 500px / 100 ) is because we used 1vw which according to this article on MDN is defined as

Equal to 1% of the width of the viewport’s initial containing block.

So on a 500px-wide screen, 1vw is equal to 500px/100.

If on the other hand you’re reading this post on a 3000px-wide screen, then the font-size will be

12px + ( 3000px / 100 ) * 0.9 = 42px

Without CSS Variables

To do the same without CSS Variables you can replace the whole block of code from the beginning of this post with this:

:root {
  font-size: calc(12px + 0.9vw);
}

Depending on your use-case that might be preferable since it’s a lot shorter. In my case I’m using the base-font-size and typography-ratio variables for a bunch of other calculations too so it makes sense to use them.

If you’re building WordPress Themes

In case you’re a WordPress Theme Developer the above method can be particularly useful and can be achieved with 2 simple controls in the WordPress Customizer:

• A slider control for the base font-size
• A slider control for the typography-ratio.

If users set the typography-ratio to 0 then their sites will use a static font-size, otherwise the values they define in these 2 controls will change the sizes of everything on their site. Take a lookat the Gridd for an example of how this can be done.

Working with the above approach on a site

Though the above method is awesome and allows you to build more responsive layouts, you should be aware that you’ll need to consistently use relative units on your site instead of absolute for most things. So for sizing elements that contain text you can use em, rem, ch, vw, % etc. But not px. The reason is simple: If you define your site-width as 960px for example, then on a screen with a horizontal resolution of more than 3000px only a few characters will fit. If on the other hand you define your site-width as 65rem, then the whole layout of the site resize to fit along with your text. And yes, you can use rem & em for your media-queries too.

This is one of the things I’d like to see more of on the web: Please move away from absolute values and start using more relative values. We no longer live in a world where all screens are between 15 and 19 inches, those days are long gone. Our designs should fit the medium they are consumed in.

Links should not blend in with their surrounding text. They need to be seen, they need to be different. If they’re not, it will be difficult to find them. Design should make our lives easier. So here are some rules you should follow:

• Don’t remove the underline from links. If you remove it, replace it with something equally visible (like for example border-bottom).
• If there is no underline, border-bottom or box-shadow in your links, make sure that there is sufficient contrast between the colors you have selected. And by “sufficient contrast” I mean you should follow the WCAG guidelines: 7:1 contrast with the background, and 3:1 contrast with surrounding text. Lea Verou has built an amazing tool you can use to check these on contrast-ratio.com. Use it. These numbers were not just picked at random, there are real valid reasons why you should follow these guidelines. And it’s not just for “accessibility”, it’s to make things easy for everyone.
• :hover should have different styling. It doesn’t need to be extremely different, but enough to indicate the user is hovering the link.
• :focus and active should be properly indicated. By default browsers use an outline for these statuses, if you remove it then make sure you replace it with something else.

Personally I don’t like using many colors, so I use something similar to this:

a {
  font-weight: 600;
  text-decoration: none;
  border-bottom: .1em solid;
}

a:hover,
a:focus,
a:active {
  box-shadow: 0 .1em;
}

a:focus,
a:active {
  outline: .1em solid;
}

Breaking down the above code:

Since I don’t use a separate color for links, I’m adding some default styles to them that makes them look different and stand out.

In CSS we can’t control the thickness of the default undersline, so I chose to remove that and instead use border-bottom with a value of .1em solid. That makes the underline scale depending on the font-size, so headers have a thicker border than the main text. Additionally you can change the color of borders, so that provides more design options.

On :hover, :focus and :active I’m adding a box-shadow with a value 0 .1em. The box-shadow will sit right below the bottom border making it look a bit thicker. The reason I’m using box-shadow instead of just changing the value of border-bottom is because now I have the freedom to use a slightly different shade of the color I used for the border., which looks extremely well if you choose the right colors.

Finally on :focus and :active I’m adding an outline of .1em solid. This way keyboard navigation is easier because it’s always clear where users using a keyboard instead of a mouse are.

There are many ways you can handle styling links. As long as they are styled differently, are visible, and theis states are sufficiently different you’ll be OK. But do not, under any circumstances make them the same as your normal text. Doing so is just annoying and breaks the way we expect things to work. Not to mention it’s just an inconsiderate dick move for accessibility. You’re breaking the web.

Scale creates consistency in sizing across elements. A visual type scale turns a typographic balancing act into a set ratio. Use a type scale based on your users and their content.

Type scales help users quickly skim and scan

By using a type scale, you fulfill users’ expectations by giving order to how things should be communicated and how they should appear. A modular scale is a design tool, but not a guarantee. Good type application still relies on designers to apply aesthetic sensibility to their overall layout in a way that addresses user needs.

So how can you do that on your site? Well, you can use the method below:

First I like defining some variables that I can use throughout the site:

:root {
  --scale: 1.333;
  /* Don't change the lines below, you only need to change the --scale above. */
  --size-l-1: calc(1rem * var(--scale));
  --size-l-2: calc(var(--size-l-1) * var(--scale));
  --size-l-3: calc(var(--size-l-2) * var(--scale));
  --size-l-4: calc(var(--size-l-3) * var(--scale));
  --size-l-5: calc(var(--size-l-4) * var(--scale));
  --size-l-6: calc(var(--size-l-5) * var(--scale));
  --size-l-7: calc(var(--size-l-6) * var(--scale));
  --size-s-1: calc(1rem / var(--scale));
  --size-s-2: calc(var(--size-s-1) / var(--scale));
  --size-s-3: calc(var(--size-s-2) / var(--scale));
}

The variables names vary depending on the project, but in the above example I named the variables using a pattern

--size-{large/small}-{multiplier}

So --size-l-1 is 1rem multiplied by our defined scale (the --scale var). --size-l-2 is the --size-l-1 var multiplied by --scale. Or if you prefer, 1em multiplied 2 times by our --scale and so on. The --size-s-1 is our base font-size (1rem) divided by our scale 1 time, --size-s-2 is divided twice and so on.

Now that we have the sizes properly defined and calculated we can just use them in our styles:

h1 {
  font-size: var(--size-l-5);
}
h2 {
  font-size: var(--size-l-4);
}
h3 {
  font-size: var(--size-l-3);
}
h4 {
  font-size: var(--size-l-2);
}
h5 {
  font-size: var(--size-l-1);
}
h6 {
  font-size: 1rem;
}
.large {
  font-size: var(--size-l-1)
}
.larger {
  font-size: var(--size-l-2)
}
.largest {
  font-size: var(--size-l-3)
}
small, .small {
  font-size: var(--size-s-1)
}
.smaller {
  font-size: var(--size-s-2)
}
.smallest {
  font-size: var(--size-s-3)
}

You can also combine this with a Fluid Typography implementation for better results on all screen-sizes.

Alternative solutions

If you don’t want to use css-variables, then you can hardcode these values. To get the values without doing all the math you can use a tool like Visual Typography Scales, and then define your values using rem units.

If you’re building WordPress Themes

The method described above is excellent for use in WordPress themes. Themes don’t need to include a separate control for H1, H2, H3 etc sizes. All you need is a slider control to let users define the scale. Take a lookat the Gridd for an example.

Those who know me personally, know that I am concerned with online privacy and web-sustainability. I don’t even have analytics on my sites simply because I consider the policies of tech giants like Google abhorrent, and the fact that almost all sites load all these extra JS assets is insanely costly for the environment.

Disqus in particular was loading assets and trackers from Google, Facebook, Twitter and its own things. So I could no longer stand the thought of using Disqus, a custom solution had to be implemented. Today I finally managed to do that and implement my new comments system.

Since this site is hosted on github pages there is already a repository. And since most of what I write is tech-related, it’s safe to assume that people reading these posts have an account on GitHub. So leveraging the GitHub Issues API, whenever I want to enable comments on a post I just create a new issue on the repository, and then in the headers of my post just add this:

comments_id: 5

Of course 5 in the above example is just the ID of the issue in the repository and each tickets has its own.
When someone wants to add a comment on a post, they click the link and they get taken to the corresponding issue on the repository where they can leave their comment. As soon as a comment is posted it appears on the page.

The Code

I created a new comments.html file in my _includes folder, and wrote this in there:

<script>
const GH_API_URL = 'https://api.github.com/repos/aristath/aristath.github.com/issues/5/comments?per_page=100';

let request = new XMLHttpRequest();
request.open( 'GET', GH_API_URL, true );
request.onload = function() {
	if ( this.status >= 200 && this.status < 400 ) {
		let response = JSON.parse( this.response );

		for ( var i = 0; i < response.length; i++ ) {
			document.getElementById( 'gh-comments-list' ).appendChild( createCommentEl( response[ i ] ) );
		}

		if ( 0 === response.length ) {
			document.getElementById( 'no-comments-found' ).style.display = 'block';
		}
	} else {
		console.error( this );
	}
};

function createCommentEl( response ) {
	let user = document.createElement( 'a' );
	user.setAttribute( 'href', response.user.url.replace( 'api.github.com/users', 'github.com' ) );
	user.classList.add( 'user' );

	let userAvatar = document.createElement( 'img' );
	userAvatar.classList.add( 'avatar' );
	userAvatar.setAttribute( 'src', response.user.avatar_url );

	user.appendChild( userAvatar );

	let commentLink = document.createElement( 'a' );
	commentLink.setAttribute( 'href', response.html_url );
	commentLink.classList.add( 'comment-url' );
	commentLink.innerHTML = '#' + response.id + ' - ' + response.created_at;

	let commentContents = document.createElement( 'div' );
	commentContents.classList.add( 'comment-content' );
	commentContents.innerHTML = response.body;

	let comment = document.createElement( 'li' );
	comment.setAttribute( 'data-created', response.created_at );
	comment.setAttribute( 'data-author-avatar', response.user.avatar_url );
	comment.setAttribute( 'data-user-url', response.user.url );

	comment.appendChild( user );
	comment.appendChild( commentContents );
	comment.appendChild( commentLink );

	return comment;
}
request.send();
</script>

<hr>

<div class="github-comments">
	<h2>Comments</h2>
	<ul id="gh-comments-list"></ul>
	<p id="no-comments-found">No comments found for this article. Comments posted before 2019-09-15 are no longer available due to a system migration since I no longer use Disqus for comments.</p>
	<p id="leave-a-comment">Join the discussion for this article on <a href="https://github.com/aristath/aristath.github.com/issues/5">this ticket</a>. Comments appear on this page instantly.</p>
</div>

Depending on the number of requests you have on your site you may want to add thes at the end of the URL in the GH_API_URL constant in the above script:

?client_id=MY_CLIENT_ID&client_secret=MY_CLIENT_SECRET

To get the client-ID and client-secret you’ll have to create a new application from your GitHub Profile > Developer Settings > OAuth Apps. Don’t worry, it only requires an application name and a URL. You can use the same URL for the callback, so it only takes 10-20 seconds to create your app and get the keys.

You can see how that file is then loaded on the template for posts here.

The logic is simple: We make a request to the GitHub API, we get the comments from the issue and render them. The code may seem a bit long but that’s only because I’m using Vanilla JS instead of libraries like jQuery, so elements have to be created individually and then added to the DOM. The above code will get the user avatar, create a link to the user’s profile, add the comment, add a link to the comment, the date and everything a comment usually has.

It’s fast, there’s no privacy concerns, no cookies, no nothing. And as an additional bonus you can just style it the way you want it.

I hope that helps someone out there, it took me quite a while to figure this one out.