DEV Community: Behnam Azimi

How the Electric Border Effect Actually Works

Behnam Azimi — Tue, 06 Jan 2026 14:23:32 +0000

There's this SVG filter trick that's been floating around, and honestly, it's one of those things that looks way more complicated than it actually is. Once you break it down, it's pretty clever.

Thanks to @BalintFerenczy for this beautiful effect. Check out the original tweet and the CodePen.

The Core Idea

The whole effect relies on something called a displacement map. Here's the gist: you take an image (or in our case, a border), and you use another image to push its pixels around. Wherever the "pusher" image is bright, pixels move one way. Where it's dark, they move the other way.

But we don't want static distortion. We want it to look alive. Electric. So we animate the thing doing the pushing.

Turbulence: Your New Best Friend

feTurbulence is an SVG filter primitive that generates procedural noise. It's the same kind of math used to create realistic clouds, fire, and water in video games. Perlin noise, if you want to get technical.

<feTurbulence type="turbulence" baseFrequency="0.02" numOctaves="10" result="noise1" seed="1" />

The baseFrequency controls how "zoomed in" the noise is. Lower values = bigger, smoother blobs. Higher values = tighter, more chaotic patterns. numOctaves adds detail layers. More octaves = more complexity, but also more computation.

The Animation Trick

Here's where it gets interesting. We generate four separate noise patterns and animate their positions using feOffset:

<feOffset in="noise1" dx="0" dy="0" result="offsetNoise1">
  <animate attributeName="dy" values="700; 0" dur="6s" repeatCount="indefinite" />
</feOffset>

Two patterns scroll vertically (one up, one down). Two scroll horizontally. When you blend them together, you get this churning, roiling motion. It's not random flicker—it's structured chaos.

The feComposite and feBlend operations combine these moving noise layers. Using color-dodge as the blend mode makes the bright areas really pop, which intensifies the electric feel.

Applying the Distortion

Finally, feDisplacementMap takes our original border and warps it according to the combined noise:

<feDisplacementMap in="SourceGraphic" in2="combinedNoise" scale="30" xChannelSelector="R" yChannelSelector="B" />

The scale value determines how aggressive the distortion is. 30 gives us a nice visible wobble without going overboard. The channel selectors (R for X displacement, B for Y) just pick which color channels from the noise control which direction of movement.

The Glow Stack

The electric border alone would look flat. The glow layers sell the effect.

We've got the main distorted border, then two additional borders on top with increasing blur:

.glow-layer-1 {
  filter: blur(1px);
}

.glow-layer-2 {
  filter: blur(4px);
}

These aren't distorted—they're static. But layered over the animated border, they create a soft halo that makes the whole thing feel luminous.

The Overlays

Two gradient overlays with mix-blend-mode: overlay add highlights. They're scaled up slightly and heavily blurred, so they spill outside the card boundaries. This creates that "light is escaping" vibe.

The background glow (filter: blur(32px)) sits behind everything at low opacity, casting a subtle colored shadow onto the dark background. It grounds the effect.

Why It Works

The human eye is drawn to movement and contrast. This effect has both. The border never sits still, and the glow creates strong contrast against the dark background.

And because the distortion is based on continuous noise rather than random jitter, it feels organic. Natural, almost. Like actual electricity arcing along a wire, not a GIF on loop.

Performance Note

This effect is GPU-accelerated in modern browsers, but it's not free. Four turbulence generators running simultaneously, blended together, feeding a displacement map—that's real work. On older devices or if you're running many of these, you might notice some heat.

For a single hero card? Totally fine. For a hundred items in a list? Maybe reconsider.

Original effect by @BalintFerenczy

Oh, Nice Repo!

Behnam Azimi — Mon, 08 Dec 2025 08:25:08 +0000

Finding new and exciting libraries on GitHub can be noisy. The standard "Trending" tab is great, but it often shows old repositories that just happened to get a random spike in activity today.

I wanted more control. I wanted to see projects that were created recently (like in the last week) but are already gaining traction.

So, I built OhNiceRepo.

What it does

This is a simple web app that connects to the GitHub API to help you discover rising stars. Instead of a generic list, it lets you filter specifically by language creation date and star count.

For example, you can search for "TypeScript repositories created in the last 7 days with at least 100 stars." This filters out the ancient libraries and leaves you with the fresh, trending gems that are actually new.

Try it out

The project is fully open source. If you want to find some new libraries to play with, or if you just want to see how the code handles the GitHub API, check it out.

Live Demo: https://ohnicerepo.pages.dev/
Source Code: https://github.com/behnamazimi/ohnicerepo

Please show your support and drop a star on the GitHub repo! Your star counts a ton, and hey, maybe it'll help OhNiceRepo itself get featured in someone else's list of nice repos! ⭐

Happy discovering! 👩‍💻

There is a Better Way to Discover Trending GitHub Repos 🚀

Behnam Azimi — Sat, 06 Dec 2025 07:58:53 +0000

Finding new and exciting libraries on GitHub can be noisy. The standard "Trending" tab is great, but it often shows old repositories that just happened to get a random spike in activity today.

I wanted more control. I wanted to see projects that were created recently (like in the last week) but are already gaining traction.

So, I built OhNiceRepo.

What it does

Try it out

The project is fully open source. If you want to find some new libraries to play with, or if you just want to see how the code handles the GitHub API, check it out.

Live Demo: https://ohnicerepo.pages.dev/
Source Code: https://github.com/behnamazimi/ohnicerepo

Please show your support and drop a star on the GitHub repo! Your star counts a ton, and hey, maybe it'll help OhNiceRepo itself get featured in someone else's list of nice repos! ⭐

Happy discovering! 👩‍💻

There is a Better Way to Discover Trending GitHub Repos 🚀

Behnam Azimi — Fri, 05 Dec 2025 17:58:30 +0000

Finding new and exciting libraries on GitHub can be noisy. The standard "Trending" tab is great, but it often shows old repositories that just happened to get a random spike in activity today.

I wanted more control. I wanted to see projects that were created recently (like in the last week) but are already gaining traction.

So, I built OhNiceRepo.

What it does

Try it out

The project is fully open source. If you want to find some new libraries to play with, or if you just want to see how the code handles the GitHub API, check it out.

Live Demo: https://ohnicerepo.pages.dev/
Source Code: https://github.com/behnamazimi/ohnicerepo

Please show your support and drop a star on the GitHub repo! Your star counts a ton, and hey, maybe it'll help OhNiceRepo itself get featured in someone else's list of nice repos! ⭐

Happy discovering! 👩‍💻

Stop Saying "This Pull Request is Too Big"

Behnam Azimi — Mon, 09 Jun 2025 07:56:47 +0000

"Could you make this PR (MR) smaller?", that’s either me leaving the comment (again) or just thinking it silently because I’m too drained to say it for the hundredth time!

Sometimes I have to keep repeating this same feedback like a broken record. Not because I love being that person (trust me, I don’t!) but because everybody knows those large pull/merge requests are a real pain in the ass. They’re more likely to break things, hard to review, and they’re just not fun to deal with.

The truth is, just telling people "keep it small" is not working. I mean, what’s “small” anyway? 🤔

Along this process I realized:

What’s small for a docs update might be huge for an auth system change
It can vary per person, what I think is a medium PR might be a small one for someone else
Different codebases need different size definitions
Without actual and automated agreements, we’re just throwing words around
Nobody wants to be the "size police"

Why Does Size Matter Though?

Because big PRs create problems. They slow teams down, make bugs harder to find, and increase risk.

Think about reviewing code like proofreading a document. Would you rather:

Review 10 pages, one chapter at a time
Or get handed a 100-page document with "just a few changes"?

Yeah, I thought so.

When PRs are smaller:

Your teammates actually review them (and faster too!) instead of rubber-stamping approvals
The feedback is way better because reviewers aren’t exhausted
It’s easier to spot potential issues
If something goes wrong, it’s quicker to fix

So I Built Something to Help 🛠️

After dealing with this over and over, I decided to build a tool to help teams actually define and measure what "too big" means for their pull/merge requests.

I built pr-sizewise, a CLI tool that measures and reports pull request sizes for GitHub and GitLab, helping teams maintain manageable code changes. I know there are a few existing tools for this already, but this one has its own uniqueness. (And it was an interesting idea to keep yourself busy on a rainy weekend! ⛈️)

With SizeWise:

You define what "big" means, by setting your own limits for:
- Number of lines changed
- Number of files modified
- Directories affected
Supports both GitHub and GitLab
Smooth setup and configuration

To get the full value out of it, not just installing it as an automation tool that gets forgotten in a few months, I recommend these steps:

Get your team together and define thresholds that feels right
Start with bigger limits (you can always tighten them later)
Share some wins when people make nice, small PRs
Figure out what to do when someone really needs to make a big change (it happens!)

Sometimes you need bigger PRs, like when you're updating all your dependencies or doing a major refactor. That’s okay! Just give your team a heads-up, break it down into reviewable chunks if you can, and add extra context to help reviewers. It's way safer to ship a large PR like this.

Give SizeWise a Try

I’d love to hear how this works for your team:

What size limits make sense for you?
How do you handle different types of changes?
What would make this even more useful?

And if you see it as a useful tool, a quick star on GitHub would mean a lot!

⭐️ https://github.com/behnamazimi/pr-sizewise

Remember, it’s not about being strict. It’s about making life easier for everyone.

Because at the end of the day, we all just want to ship good code without the drama. 🚀