Forem: Ridwan Ajibola

Humans still win: why frontend basics matter — even with Gemini, GPT, and Claude

Ridwan Ajibola — Mon, 13 Oct 2025 22:21:41 +0000

Have you ever felt that nagging thought that AI assistants like GPT-4 and Gemini might make our development skills obsolete? I certainly have. Then I spent over a day wrestling with a "simple" bug that put that idea to the test.

This is the story of a bug-hunting marathon that took me through every modern debugging tool I knew, only to be solved by the most basic of frontend fundamentals.

The Bug: The Silent Click Thief 🐛

It started with what seemed like a trivial issue. I was using a Radix UI Dialog component in my application. The problem? After opening and closing the dialog, every single click event on the page would stop working. The UI was frozen, but not in the usual way. I could still highlight text, and the buttons weren't in a disabled state. They just... ignored me.

My first thought was “this must be CSS!” Maybe a transparent overlay or a rogue element with an outrageous z-index was hijacking all my clicks. I opened DevTools, ready to track it down. But—nothing. The page was spotless.

This wasn't a simple CSS problem. This was something deeper.

The Human-Powered Debugging Marathon 💨

In an effort to troubleshoot effectively, decided to run through my entire debugging playbook.

Performance Profiling: I recorded a session of opening and closing the dialog, looking for any unexpected, massive re-renders that might be locking up the main thread. Again, nothing. The performance graph was clean.

Divide and Conquer: I started commenting out chunks of the dialog's content, hoping to isolate the faulty part. I halved it, then quartered it, then broke it down into its smallest units. The bug persisted, mocking my efforts. The issue wasn't inside the dialog content.

Reproducing with E2E Tests: I needed a reliable way to reproduce the bug without manual clicking. I spun up a quick Playwright test:

Create three buttons: one to increment a counter, one to open a "simple" dialog, and one to open the "edit" dialog that seemed to be the main culprit.
The test would click the counter, open and close a dialog, and then try to click the counter again.
The result? The test failed every time. After the dialog closed, Playwright couldn't click the counter button. I finally had a consistent reproduction case, but I was no closer to a solution.

Enter the AI Assistants 🤖

Frustrated but armed with a reproducible test case, I turned to my AI co-pilots. I fed the code, the context, and the Playwright test results to Claude 3, GPT-4, and Gemini.

Their responses were a masterclass in confident hallucination.

They suggested changing props that didn't exist, refactoring the code in ways that broke other things, and adding modal flags that weren't part of the library. One AI "fixed" the issue by making the dialog close instantly upon opening, technically, the clicks worked afterward, but the core functionality was gone!

They were pattern-matching without understanding. They were code parrots, not problem solvers. After hours of this, I was back at square one, feeling more convinced than ever that the human element was missing.

The "Aha!" Moment: Back to Basics 💡

Stepping away from the AI and the complex tools, I decided to do something simple. I just opened and closed the dialog, over and over, with my DevTools inspector glued to the element.

And then I saw it.

Each time the dialog closed, a single CSS property was being injected onto the body: pointer-events: none;

This tiny line of code was the silent click thief. It was telling the entire page to ignore all mouse interactions. The bug wasn't an overlay; it was a global CSS change that the dialog was failing to clean up after itself.

A quick search on the library's GitHub repo revealed this was a known, long-standing bug. The solution? Simply updating the package to the latest version.

In the end, I asked Claude Code to update all Radix UI packages, and the issue vanished. Twenty-eight hours of debugging taught me that sometimes the most complex bugs have the simplest fixes.

My Takeaways for the Modern Developer 🚀

This experience wasn't a waste of time; it was a powerful lesson.

Fundamentals Are Your Superpower. Advanced tools and AI are fantastic, but they are layers of abstraction. The bug wasn't in my React code; it was in the fundamental interaction between CSS and the DOM. A deep understanding of the basics (like what pointer-events does) is what ultimately allows you to solve the unsolvable.
AI is a Co-pilot, Not the Pilot. LLMs are incredible for boilerplate, refactoring, and generating ideas. But for complex, context-specific debugging, they can lead you down rabbit holes. They don't have true "experience." You, the developer, are still the pilot. Use AI to navigate, not to cede control of the cockpit.
Master Your Core Tools. The hero of this story wasn't Playwright or a fancy profiler. It was the humble Browser Inspector. Knowing your browser's dev tools inside and out is the single most valuable debugging skill you can possess.
Consult the Collective Brain: The GitHub Repo. Before you declare war on a bug in a third-party library, check the GitHub Issues tab. The open-source community is a massive, collective brain. My final breakthrough came from searching the repo. A quick search can save you days of frustration, revealing that you're not the first to face the problem and that a solution may already exist.

So, are LLMs a threat? No. They're a tool. And like any tool, their effectiveness is limited by the skill of the person using them. The need for developers who understand the fundamentals has never been greater.

What's your story of a tough bug that AI couldn't crack? Share it in the comments below!

Human Regex Gets TypeScript's Magic Typing 🚀

Ridwan Ajibola — Sun, 16 Feb 2025 23:42:30 +0000

Two weeks ago, I released the first public version of Human Regex, and I’m thrilled to share that it now leverages TypeScript’s magic typing to take regex building to the next level! This update not only brings a host of bug fixes but also introduces a smarter, safer API for crafting regular expressions. Thanks to two new contributors—one of whom contributed the powerful magic typing—Human Regex has already gained 900+ downloads.

Why is Human Regex better than traditional regex in JS/TS?

English-like Syntax: Build regex patterns in a readable, chainable syntax that feels like natural language.
Magic Typing: Enforces valid regex construction at compile time, catching mistakes early and making your code safer.

Want to Learn More?

🔎 Missed the gist, check out my previous blog post.
📘 Explore the latest tutorial: Dive deeper into using Human Regex in your JS/TS projects by completing this blog post.

Getting Started

Installation:
Start by installing Human Regex in your project:

npm install human-regex

Then import the library in your TypeScript code:

import { createRegex } from "human-regex";

Simple Examples:

Basic Literal Match:
Match the exact word "hello" without worrying about special character escaping.

const helloRegex = createRegex()
.literal("hello")
.toRegExp();

console.log(helloRegex.test("hello")); // true
console.log(helloRegex.test("world")); // false

Digit Matching:
Create a regex that matches only digits.

const digitRegex = createRegex()
  .digit()
  .toRegExp();

console.log(digitRegex.test("5")); // true
console.log(digitRegex.test("a")); // false

Using the OR Operator:
Match one of multiple options using the .or() method.

const animalRegex = createRegex()
  .literal("cat")
  .or()
  .literal("dog")
  .toRegExp();

console.log(animalRegex.test("cat")); // true
console.log(animalRegex.test("dog")); // true
console.log(animalRegex.test("bat")); // false

Whitespace Matching:
Check if a string contains a whitespace character.

const whitespaceRegex = createRegex()
  .whitespace()
  .toRegExp();

console.log(whitespaceRegex.test(" ")); // true
console.log(whitespaceRegex.test("a")); // false

Escaping Special Characters:
The .literal() method automatically escapes special characters for you.

const specialCharsRegex = createRegex()
  .literal(".*+?^${}()|[]\\")
  .toRegExp();

console.log(specialCharsRegex.test(".*+?^${}()|[]\\")); // true

Protocol Validation:
Build a regex to check for a valid HTTP/HTTPS protocol.

const protocolRegex = createRegex()
  .protocol()
  .toRegExp();

console.log(protocolRegex.test("http://"));  // true
console.log(protocolRegex.test("https://")); // true
console.log(protocolRegex.test("ftp://"));   // false

Named Capture Group:
Extract a substring using a named capture group.

const namedGroupRegex = createRegex()
  .startNamedGroup("digits")
    .digit()
    .oneOrMore()
  .endGroup()
  .literal("-end")
  .toRegExp();

const match = "12345-end".match(namedGroupRegex);
if (match?.groups) {
  console.log(match.groups.digits); // "12345"
}

Matching Exactly Three Digits:
Ensure a string contains exactly three digits.

const threeDigitsRegex = createRegex()
  .startAnchor()
  .digit()
  .exactly(3)
  .endAnchor()
  .toRegExp();

console.log(threeDigitsRegex.test("123")); // true
console.log(threeDigitsRegex.test("12"));  // false
console.log(threeDigitsRegex.test("1234")); // false

Error Handling Examples:

Human Regex includes smart typing and runtime checks to help you catch mistakes early. Here are two examples that intentionally trigger errors:

Error Example 1: Using .lazy() on an Empty Pattern

try {
  // No quantifier exists, so calling .lazy() throws an error.
  createRegex().lazy();
} catch (e) {
  console.error(e.message); // Expected output: "No quantifier to make lazy"
}

Error Example 2: Invalid Unicode Letter Variant

try {
  // "x" is not a valid Unicode letter variant.
  createRegex().unicodeChar("x" as any);
} catch (e) {
  console.error(e.message); // Expected output: "Invalid Unicode letter variant: x"
}

Conclusion

Human Regex transforms the complexity of traditional regex into a series of intuitive method calls. Whether you’re matching a simple literal, testing digits, or combining multiple methods for complex patterns, the library offers a clear and maintainable approach. Its robust type system and runtime checks help prevent common mistakes, making your code safer and easier to debug.

Have you explored Human Regex in your projects? I’d love to hear your experiences or see your examples in the comments below!

You can also contribute by:

⭐ Starring the GitHub repo to help others discover it
🐞 Reporting bugs or requesting features
💡 Contributing code or documentation

Happy coding!

DIY Component Library Trap: Opinionated Design Systems

Ridwan Ajibola — Fri, 14 Feb 2025 14:45:45 +0000

In my experience developing component libraries for various startups, I've noticed a recurring pattern. Time and again, teams try to break free from opinionated libraries like MUI, AntDesign, or ShadCN by building custom design systems—only to find their custom systems becoming just as rigid and limited in scope. Even when using utility-first frameworks like Tailwind CSS, if overused or misapplied, excessive prop passing forces your custom library into inflexible, project-specific patterns that can’t be easily reused elsewhere.

The core issue is that when you try to escape established opinions without a modular strategy, you end up recreating them in a form tailored to a specific project rather than being reusable across multiple projects. My experience and community feedback suggest the best solution for React is a hybrid, localized styling approach. This approach works with any CSS strategy—CSS Modules, SCSS, CSS-in-JS (like twin.macro), or even Tailwind—while keeping components reusable across projects.

The Problem: Complex & Opinionated Libraries

Popular component libraries like MUI, AntDesign, and ShadCN guide you toward a specific design language, which can sometimes limit your ability to create a truly unique look and reuse components across projects. Meanwhile, if not managed properly, even a utility-first approach (like Tailwind CSS) can lead to excessive prop passing, resulting in a custom component library that is as opinionated as the established ones and often limited to just one or two projects.

In practice, teams that try to “escape” these opinions often end up with:

Rigid Patterns: Pre-defined design tokens and utilities enforce uniformity that may not suit your product’s unique identity—and these patterns are so tailored to one project that they hinder reuse in others.
Excessive Prop Passing: Relying solely on utility-first approaches can result in lengthy lists of props and class overrides. For example, a button with left and right icons might require individual style props just to tweak margins, paddings, colors, and hover effects—locking the component into a project-specific setup.
Reinventing the Wheel: In an effort to break free from established libraries, teams build custom component libraries that, without a modular strategy, inherit rigid, project-specific patterns. This not only makes them difficult to maintain but also limits their reusability across different projects.

The CSS Custom Properties Strategy for Flexible Component Libraries

The solution to building flexible, reusable components lies in leveraging CSS custom properties to create clear customization points while keeping styling choices open. This approach ensures your components remain adaptable across different projects, regardless of your team's preferred styling solution.

Let's explore this strategy through a practical example: a Button component that needs to support icons, variants, and project-specific styling requirements.

Core Component Architecture

The foundation starts with a base Button component that uses CSS custom properties for key styling points:

const Button = ({
  variant = "default",
  icon,
  children,
  className,
  ...rest
}) => (
  <button
    className={`button ${variant} ${className}`}
    {...rest}
  >
    {icon && <IconContainer>{icon}</IconContainer>}
    <span>{children}</span>
  </button>
);

const IconContainer = styled.div`
  height: var(--icon-container-size, 16px);
  width: var(--icon-container-size, 16px);
  padding: var(--icon-container-padding, 0);
  margin: var(--icon-container-margin, 0 4px 0 0);

  svg {
    padding: var(--icon-padding, 2px);
    color: var(--icon-color, currentColor);
  }
`;

The base Button component should also adhere to accessibility best practices, such as appropriate ARIA attributes for screen readers.

This structure provides several key advantages:

Clear Customization Points: CSS custom properties define exactly what can be customized.
Default Styling: Base styles with sensible defaults.
Flexibility: The className prop allows for easy style overrides using any styling approach.

Implementation Options

The beauty of this approach is its flexibility in implementation. Teams can choose their preferred styling solution while maintaining component consistency:

Using CSS Modules:

// TextButton.module.scss

.textButton {
  --icon-container-size: 20px;
  --icon-padding: 4px;

  background: transparent;
  color: var(--color-text-primary);

  &:hover {
    background: var(--color-background-hover);
  }
}

import styles from './TextButton.module.scss';

const TextButton = (props) => (
  <Button className={styles.textButton} {...props} />
);

Using Styled Components:

const TextButton = styled(Button)`
  --icon-container-size: 20px;
  --icon-padding: 4px;

  background: transparent;
  color: ${props => props.theme.colors.primary};

  &:hover {
    background: ${props => props.theme.colors.backgroundHover};
  }
`;

// Usage
<TextButton
  variant="outline"
  icon={<Icon name="Info" />}
>
  Learn More
</TextButton>

Using SCSS

.text-button {
  --icon-container-size: 20px;
  --icon-padding: 4px;

  @include button-base;

  background: transparent;

  &:hover {
    background: $color-background-hover;
  }
}

Optional: Tailwind Integration For teams using Tailwind, the component can easily integrate with utility classes:

<Button
  className="bg-transparent hover:bg-gray-50"
  style={{
    '--icon-container-size': '20px',
    '--icon-padding': '4px'
  }}
  icon={<Icon name="Info" />}
>
  Learn More
</Button>

Real-World Effectiveness

This strategy has proven highly effective in real-world applications for several reasons:

True Component Reusability: Instead of creating rigid, project-specific components, this approach allows teams to:

Maintain consistent component structure.
Customize styling for specific project needs.
Avoid rebuilding components for each new project.

Reduced Prop Complexity: Rather than passing numerous style props, we can:

Use CSS custom properties for style customization.
Keep component APIs clean and focused.
Allow styling overrides through standard CSS mechanisms.

Flexible Implementation: Teams can:

Choose their preferred styling approach.
Mix and match styling solutions as needed.
Maintain consistent component behavior across different styling implementations.

Example: Building a Product Suite

Here's how this approach works in practice. Imagine building a suite of products that share common components but need distinct visual identities:

// Product A - Marketing Site
const MarketingButton = styled(Button)`
  --icon-container-size: 24px;
  --icon-container-margin: 0 8px 0 0;
  background: linear-gradient(to right, var(--color-primary), var(--color-secondary));
  color: white;
`;

// Product B - Admin Dashboard
const AdminButton = styled(Button)`
  --icon-container-size: 18px;
  --icon-padding: 2px;
  background: var(--color-background-subtle);
  color: var(--color-text-primary);
`;

Conclusion

CSS custom properties provide a powerful solution to the component library challenge. Instead of fighting against established libraries or creating rigid custom solutions, this approach:

Maintains component flexibility while providing consistent structure.
Supports multiple styling approaches to suit team preferences.
Enables true component reusability across different projects.
Reduces the complexity of style customization.

This strategy has helped numerous teams break free from the cycle of rebuilding components for each project while maintaining the flexibility needed for unique design requirements. Whether you're building a single product or a suite of applications, this approach provides a sustainable path forward for component library development.

What challenges have you faced with component libraries in your projects? How do you balance consistency with flexibility in your design systems? Share your experiences in the comments below.

Don't forget to like, share and also connect with me on LinkedIn.

🚀 Human-Regex: Write Readable Regular Expressions Like English

Ridwan Ajibola — Mon, 03 Feb 2025 11:17:51 +0000

Created by Ridwan Ajibola

Sick of trying to understand those confusing regex patterns? Let's change that.

// Before: Cryptic regex for password validation  
const passwordRegex = /^(?=.*\d)(?=.*[!@#$%^&*])(?=.*[a-zA-Z]).{8,}$/;

// After: Human-readable with human-regex  
const humanPasswordRegex = createRegex()
  .startAnchor()
  .hasDigit()          // (?=.*\d)
  .hasSpecialChar()    // (?=.*[!@#$%^&*])
  .hasLetter()         // (?=.*[a-zA-Z])
  .anyCharacter()      // .
  .atLeast(8)          // {8,}
  .endAnchor()
  .toRegExp();

🔗 GitHub | 📦 npm

Why I Built This

Regex is powerful, but let’s be honest: patterns like /^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$/ look like someone fell asleep on their keyboard. When I first learned JavaScript, regex was my #1 frustration – and every developer I asked shared this pain.

So I asked: What if we could write regex in plain English?

Human-Regex was born, created by Ridwan Ajibola, a utility library that turns regex patterns into chainable, self-documenting code.

How It Works

Traditional Regex → Human-Regex

Traditional Regex	Human-Regex Equivalent
`/\d/`	.digit()
`/[a-zA-Z]/`	.letter()
`/(?=.*\d)/`	.hasDigit()
`^ / $`	.startAnchor() / .endAnchor()

const emailRegex = createRegex()
  .startAnchor()
  .word().oneOrMore()        // [a-zA-Z0-9_]+
  .literal('@')              // @
  .word().oneOrMore()        // [a-zA-Z0-9_]+
  .literal('.')              // .
  .letter().atLeast(2)       // [a-zA-Z]{2,}
  .endAnchor()
  .toRegExp();

No more guessing what [a-zA-Z0-9_] or {2,} means. The code explains itself.

Key Features

✅ Readable Syntax
Methods like .hasDigit() and .startAnchor() make patterns self-documenting.

✅ Chainable Design
Build complex patterns step-by-step, just like writing a sentence.

✅ Lightweight
Just 1.0 kB gzipped. (1.4kB new version)

✅ Open Source
MIT licensed. Contributions welcome!

Get Started in 60 Seconds

Install the library:

   npm install human-regex

Build your first regex:

const urlRegex = createRegex()
  .startAnchor()
  .protocol()     // https?://
  .www().optional() // (www\.)?
  .word().oneOrMore()
  .literal('.')
  .tld()          // com|org|net
  .toRegExp();

Why This Matters

Onboarding: New developers understand regex logic at a glance.

Maintenance: No more regex archaeology to update old code.

Collaboration: Teams spend less time decoding patterns.

Join the Movement

Regex doesn’t have to be scary. Try Human Regex and:
⭐ Star the GitHub repo — it really helps! 🚀
🐞 Report bugs or request features
💡 Contribute code or documentation

Let’s make regex accessible to everyone!

Don't forget to connect with me on LinkedIn.