DEV Community: Richard Ochola

The Death of the Front End

Richard Ochola — Wed, 03 Jun 2026 18:15:10 +0000

We spent thirty years building the web for human eyes. We may have gotten it wrong.

I. The Last Time You Clicked a Blue Link.

Think back. When did you last open a search engine and feel genuinely satisfied with what came back? Not tolerant. Not resigned. Actually satisfied the way you feel when someone answers your question instead of handing you a stack of pamphlets and wishing you luck.

For most of us, that moment has already passed. We stopped searching and started asking. We got tired of the blue link lottery the SEO slop, the affiliate farms, the endless scrolling through ten pages of noise to find one sentence of signal. Quietly, without fanfare, we made a different choice.

We didn't abandon search. Search abandoned us first.

That shift wasn't just a change in habit. It was the opening chapter of something much bigger a story about what the internet is actually for, and who it was ever really built to serve.

II. The Citizens Nobody Designed For

Here is the uncomfortable truth that the industry hasn't fully faced yet: we have been building the wrong infrastructure for the wrong user.

Every pixel-perfect component, every A/B tested button colour, every carefully considered onboarding flow we built all of it for a user who is increasingly handing the wheel to an agent. The new first-class citizens of the internet don't need your dropdown menu. They don't have eyes. They have context windows.

I've felt this personally. As AI and Ml engineer, building autonomous file analyzers and local-first data systems, the pattern became impossible to ignore: every time I wired an agent into a real-world system, the UI became an obstacle. Not a feature. An obstacle. The machine had to squint through layers of CSS and DOM noise just to extract the one thing it actually needed.

We are engineering for the human eye while the machine waits patiently outside, pressing its face against the glass.

III. The Tax We Forgot We Were Paying

There is a cost hiding inside every page load that we never put on the balance sheet. Call it the Token Tax.

Every time an agent parses a full DOM tree bloated with decorative spans, layout scaffolding, tracking scripts, and CSS that exists purely to make a gradient look good on a 2019 MacBook it burns compute. It burns context. It burns money. And at the end of all that burning, the agent extracts a price, an endpoint, a date. Something that could have been a single line of JSON.

The absurdity of this only hits you when you sit with it. We are running sophisticated intelligence through a funnel designed for eyeballs. We are asking the most capable reasoning systems ever built to cosplay as web scrapers.

The fix isn't complicated. It requires a mindset shift. We need an API-First Mandate not as a backend afterthought, but as the primary design contract. JSON. GraphQL. Semantic, typed, machine legible interfaces that tell an agent exactly what it needs to know, with zero visual clutter in the way.

IV. The World After the Refactor

None of this means the end of beauty. It means the beginning of a different kind of beauty one that works at two levels simultaneously. A layer humans can see, and a layer machines can read. Not competing. Parallel.

Picture the phone of the near future. There are no apps to open. No home screen to swipe through. Just a conversation. "Send this." "Find me a flight." "What's left on my list?" Fluid, instant, invisible. The interface collapses into intent.

The best interface is no interface just your thought, translated into action.

The developer who thrives in this world won't be a UI engineer or a backend specialist. They'll be something new: an Architect of Semantic Interfaces. Someone who designs systems legible to both species human and machine with equal craft and care.

This is the refactor the web has always needed. Not a teardown. A transformation. We stop building for display and start building for understanding. We stop optimising for the scroll and start optimising for the query.

The front end isn't dying because we failed. It's dying because we succeeded and the thing we built is now ready to be outgrown.

The next era belongs to those who build for the intelligence that comes next. The architects who see both the human and the machine, and design for both without apology, without compromise.

Start building for them. The future is already asking.

Mistakes every Go beginner makes. Part 1 : Time Complexity Issues

Richard Ochola — Tue, 03 Feb 2026 11:43:15 +0000

When you start learning Go, the syntax feels clean and the speed feels amazing. But there is a trap many beginners fall into: writing code that works perfectly for small tasks but crawls to a halt when the data gets bigger.

Recently, I was working on an ASCII Art Generator. The logic was simple: take a string, find the corresponding ASCII characters in a template file, and print them out. However, I noticed that as my input text got longer, the program started lagging.

The culprit? How I was collecting my results. Let's look at the two "silent" performance killers I found in my own code.

1. The String Concatenation Trap

In my project, I had a function to build the final output string. I was using the += operator to join every line together.

The "Before" Code (Slow):

func OutputCharacters(input []string, charmap map[rune][]string) string {
    res := ""
    for _, line := range BuildASCII(input, charmap) {
        res += line + "\n" // The Hidden Performance Killer
    }
    return res
}

The Technical "Why"

In Go, strings are immutable. This means once a string is created in memory, it can never be changed.

When you run res += line, Go doesn't just "tack" the new text onto the end. Instead, it performs a costly cycle:

It allocates a brand new memory block large enough for the old string + the new line.
It copies every single byte from the old string into the new one.
It copies the new line into the new memory.
It throws away the old string for the Garbage Collector to clean up.

As your loop grows, you are copying the same data over and over again. This creates a *Time Complexity of *. If you have 1,000 lines, you aren't just doing 1,000 operations; you're performing millions of byte copies!

The Fix: `strings.Builder`

Go provides strings.Builder, which uses a mutable byte slice internally. It grows smarter (usually doubling in size) so it doesn't have to copy everything every time.

func OutputCharacters(input []string, charmap map[rune][]string) string {
    var builder strings.Builder
    lines := BuildASCII(input, charmap)

    for _, line := range lines {
        builder.WriteString(line)
        builder.WriteByte('\n')
    }
    return builder.String() // Final string is created only ONCE
}

2. The Unallocated Slice Issue

Inside my BuildASCII function, I was creating a slice of strings to hold the art, but I was initializing it as an empty slice.

The Problem:

var res []string // Length: 0, Capacity: 0

A slice in Go is backed by an underlying array. When you append to a slice that is full, Go has to "move house":

It finds a new, larger spot in memory.
It copies all current elements to the new spot.
It updates the slice pointer.

In my ASCII project, I knew that every word in the input would result in exactly 8 lines of ASCII art. By not telling Go this, I was forcing the program to stop and "move house" (reallocate) multiple times as the list grew.

The Fix: Pre-allocation with `make`

If you can calculate or even estimate the size, you should pre-allocate the capacity. This "reserves" the memory upfront.

func BuildASCII(input []string, charmap map[rune][]string) []string {
    // We know the exact size: 8 lines per input word
    totalExpected := len(input) * 8
    res := make([]string, 0, totalExpected) // Length 0, but Capacity is set!

    for _, word := range input {
        // ... build lines ...
        res = append(res, line) // Zero reallocations happen now!
    }
    return res
}

Conclusion

When you're a beginner, "making it work" is the priority. But as you grow, "making it efficient" becomes the goal. By understanding how Go handles memory, you can prevent your programs from slowing down as they scale.

Have you run into these "slow loops" before? What other beginner traps should I cover in Part 2? Let me know below!