This article focuses more on the technical development rather than the product itself — the story of my sleepless, coffee-driven nights and a testimony that you can, in fact, bite more than you can chew :)

Deep Dive

This project was actually inspired by Julien Barbier’s challenge, and at the time, I had no idea, let alone, experience on building Chrome extensions. But that didn’t stop me from diving headfirst into the rabbit hole. Armed with way too many open tabs, a half-functioning debugger, and a vague understanding of how Chrome APIs worked, I set out to build something that could block ads and replace them with something better.

The first hurdle? Figuring out how to intercept and modify web requests. Chrome’s declarativeNetRequest API seemed like the right choice—until I realized its limitations when trying to inject custom content. That led me to chrome.scripting, which gave me the power to manipulate DOM elements dynamically. Sounds easy, right? Yeah, until you’re debugging scripts injected into a page that reloads every time you test it.

The "Why Is This Not Working?" Phase

If you’ve ever built a Chrome extension, or anything that involves code for that matter, you know that things never go smoothly the first time. Or the second. Or the tenth.

One of my biggest struggles was getting permissions right in manifest.json. I must have gone through a dozen iterations, each time getting slapped with vague errors that felt more like riddles than actual debugging hints. At one point, I had an extension that could block ads… but not replace them. Then, I had one that replaced ads… but only after a manual refresh. And, of course, the version that worked perfectly—except on actual websites people use.

At 3 AM, fueled by coffee and stubbornness, I finally had a breakthrough: instead of replacing ads post-load, I needed to hook into the page lifecycle earlier using a MutationObserver. This allowed AdFriend to detect and swap out ads as soon as they appeared, creating a seamless experience.

Adding the "Meaningful" Part

Blocking ads is one thing, but replacing them with content tailored to the user? That was another challenge altogether. I built a simple preferences system that let users choose what kind of content they wanted—motivational quotes, coding tips, news snippets, or even their own custom messages.

This involved setting up a lightweight storage system using chrome.storage.sync, allowing settings to persist across sessions. From there, a small content-fetching module pulled relevant snippets and dynamically inserted them in place of ads. The first time it worked properly, I stared at the screen for a good minute, trying to process the fact that I had actually made it work.

Lessons Learned (and a Few Regrets)

• APIs are deceptive – Chrome’s documentation makes everything sound straightforward, but the reality is a game of trial and error.

• Debugging extensions is a nightmare – Unlike web apps, where you can log everything to the console, debugging injected scripts comes with its own brand of suffering.

• Don’t over-engineer – At one point, I considered integrating an AI-generated content system. Thankfully, I stopped myself before I went completely off the rails but that’s definitely on my to-do list regardless — nobody can stop reggae.

Final Thoughts

AdFriend started as an experiment, but it turned into something surprisingly useful. It’s not perfect, but it works—and more importantly, I built it from scratch with zero prior experience in Chrome extension development. If you’re thinking of creating your own extension, my advice is simple: start small, expect chaos, and just keep pushing through.

Now, if you’ll excuse me, I need to catch up on all the sleep I sacrificed for this project. Ohh, and please try it out yourself here

Improvements and new releases have ever since been made despite Rossum leaving the team and giving up his title as "Benevolent Dictator for Life" of python on July, 2018 when he announced his retirement. (from the name I guess he still holds the title though)

Without getting to all things python and it's cool features, I'll deep dive into what's called the Zen of Python, a concept unique to python and sparks curiosity vis-a-vis the python language.

The Zen of Python is a set of 19 guidelines introduced by Tim Peters, an American software developer and big contributor to the CPython framework. He came up with these guidelines that define programming best practices especially in the implementation of Python.

To view the zen of python locally:

1. Create a main.py file

2. Copy the following code to you main.py file:

import this

1. Run the file in the terminal as python3 -m main.py

2. Output:

The Zen of Python by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one -- and preferably only one -- obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Below I give insight on every line of the Zen

"Beautiful is better than ugly." - Besides functionality, code should also be easy to read and aesthetically pleasing.

"Explicit is better than implicit." - Code should be obvious from any reader's point of view (another programmer of course) rather than relying on background behaviors.

"Simple is better than complex." - Code implementation should be simple while maintaining optimum functionality.

"Complex is better than complicated." - If code complexity is at all necessary make it straightforward.

"Flat is better than nested." - Code structure should avoid exaggerated nesting of control structures.

"Sparse is better than dense." - This emphasizes on paragraphing code to enhance readability.

"Readability counts." - Quite straightforward; code should be readable.

"Special cases aren't special enough to break the rules." - Python comes with guidelines and conventions of writing code; manipulating code to go around the conventions in an attempt to execute a "special" behaviour is therefore not an option.

"Although practicality beats purity." - Well practically achieving a behaviour under restricting guidelines may be hard, this zen gives room for special case code to simplify the work at hand.

"Errors should never pass silently." - Exceptions and errors must never be ignored even if it doesn't affect output.

"Unless explicitly silenced." - Suppressing exceptions is the next alternative to managing hard to handle exceptions.

"In the face of ambiguity, refuse the temptation to guess." - Coding should be intentionally rather than trial and error to accomplish a behaviour.

"There should be one -- and preferably only one -- obvious way to do it." - Code should be consistent all along a program and establish flow down the lines.

"Although that way may not be obvious at first unless you're Dutch." - This is a more of a humorous pun directed at Rossum, creator of Python, who is Dutch.

"Now is better than never." - Implement a solution as it comes; don't be hard on perfection which may never be achieved.

"Although never is often better than right now." - Trying to be perfect is not necessary but also take time to implement it's best attainable code solution.

"If the implementation is hard to explain, it's a bad idea." - Code should be made easy to explain the execution flow.

"If the implementation is easy to explain, it may be a good idea." - Code that's easy to explain is by high chance well Implemented.

"Namespaces are one honking great idea -- let's do more of those!" - Variables and other namespaces that could be used globally in other parts of the code parts of the code is always better than constantly defining code.

The Zen of Python is not necessarily a contract with consequences if broken but rather a friendly guideline to any developer out there; novice or expert. So take your time on every Zen.

✌️