DEV Community: Muhammad Usman

Being a Software Engineer Is Harder in 2026 Than It Was Five or Ten Years Ago

Muhammad Usman — Fri, 11 Sep 2026 08:58:22 +0000

Believe it or not, it's harder to be a software engineer in 2026 than it was five or ten years ago. I'm not talking about getting a job as a software engineer. I'm talking about being a software engineer. Let's assume you already got the job and you are a programmer.

It is harder in 2026 than it was five or ten years ago, and the reason is very simple: the expected throughput of a software engineer is ridiculous. It's actually ridiculous. You are expected to spend less than one day on one ticket. And if you take beyond a day, it's like, what's going on? You have all these AI resources, we gave you all this AI budgeting. Why are you not finishing the ticket?

Well, now we're expected to rush through our tickets, merge AI slop, and add more bugs to the codebase. Now we have to have future tickets to address the bugs that we introduced because we were told to rush. It's all mixed up.

As a pre-AI software engineer, you could spend weeks or months on a certain ticket, and if it was a difficult ticket, people would understand. But now the understanding is, we spent all this AI budgeting on you. You have all these resources, what's taking you longer than 24 hours? Like, why are you still not done with a ticket?

And because you have AI on top of the ticket you're currently working on that you're expected to finish in 24 hours, you're also expected to do other things, simply because you have AI, because you are a software engineer equipped with some magical superpower that makes you Superman. It's ridiculous, in my opinion. And I think before AI, there was a more realistic expectation of what a software engineer could do.

And once upon a time just because of this, I got fired.

Why Your AI-Generated Code Keeps Breaking in Production

Muhammad Usman — Mon, 07 Sep 2026 05:39:05 +0000

AI wrote your code, tests passed, you shipped it, and it broke in production.

Here is why that keeps happening and how to actually fix it.

Why It Happens?

AI models are trained on public code, which means they are also trained on bad code, outdated patterns, and deprecated APIs.

When you prompt Copilot or Cursor without context, it doesn't know your architecture, your environment variables, your edge cases. It's guessing confidently.

That's the real problem. It's not that the AI is careless. It's that it sounds certain even when it's working with none of the information that actually matters.

Here Is What You Can Do

Here is what senior engineers do differently.

They don't ask AI to write the solution. They ask it to challenge the solution.

Prompt it like this:

"Here is my implementation. What assumption am I making that could fail in production? What edge cases am I missing?"

Now you are using it as a code reviewer, not a code generator.

Always Include Your Actual Context

Paste your schema, your existing functions, your constraints.

A model with context beats a model without it every single time. Skip this step and you're not getting a solution, you're getting a guess dressed up as one.

Go Further

Extra helpful tip if you want to go further: set up a free commit hook that runs an AI review before anything reaches your repo.

Catch the confident guesses before they ship, not after.

Prompting Will Be Dead in Six Months

Muhammad Usman — Fri, 04 Sep 2026 07:51:53 +0000

That's at least what every tech bro is saying right now on Twitter.

The next wave, apparently, is graph engineering.

Okay, So What the Heck Is Graph Engineering?

If you picture a normal AI agent, it's typically one model looping through an entire task by itself, over and over, until it decides, yeah, this is good enough.

Graph engineering breaks that into smaller pieces called nodes.

A node is just one specific job, a researcher, a writer, or a fact checker. Each has its own model call or its own agent.

Nodes connect through edges, and an edge decides what happens next based on what the last node just did.

So say, for example, the fact checker finds an error. The edge flags it and sends the task back to the writer node with the error attached, so the writer knows exactly what to fix. Only once the fact checker approves it does the edge let the work move forward.

That's the core of graph engineering.

My Take

It's not really a new discipline. It's the same orchestration that myself and other people have been doing with tools like LangGraph for over a year, with a little sprinkle on it.

The term just went viral this month. But before it, it was loop engineering. Before that, harness engineering. Before that, context engineering.

Same idea, just slight changes. And every time, someone keeps declaring the old term dead when really it just got a slight improvement.

So No, Prompting Isn't Dying in Six Months

What's actually dying is the idea that you can duct tape one model to one clever prompt and call it a finished agentic system.

Follow and I'll keep you posted.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
Don’t forget to subscribe to Developer’s Journey to show your support.

Why Your First 10 Projects Should Be Bad on Purpose

Muhammad Usman — Wed, 02 Sep 2026 12:13:45 +0000

Nobody tells you this when you start.

Your first project is going to be bad. So is your second. Probably your fifth too.

Most people treat this as a problem to fix. Something to push through on the way to the "real" work. But bad projects aren't a phase you survive. They're the mechanism. Ten bad projects, done on purpose, will teach you more than one good project you spent six months protecting.

The single-project trap

Here's the pattern. You pick an idea. You decide it's going to be the one. Your portfolio piece. The thing that proves you can actually build.

So you slow down. You research the "correct" architecture before writing a line. You refactor the same feature three times because it doesn't feel clean enough. Six months in, you're still not done, and the thing hasn't taught you nearly as much as it should have, because you spent most of that time protecting it instead of testing it against reality.

One project can only teach you one project's worth of lessons, and it teaches them slowly, because you never let it actually break.

Quantity beats quality, and there's a reason it's not a coincidence

There's an old story from the book Art & Fear, about a ceramics teacher who split his class in two. One half would be graded purely on how many pounds of pots they turned in. The other half needed to hand in just one pot, but it had to be perfect.

When grading day came, the best pots in the room all came from the quantity group. While they were busy making pot after pot and learning from what went wrong each time, the quality group had spent the semester theorizing about the perfect pot and had little to show for it beyond some dead clay.

Web development works the same way. You don't learn to structure an app by reading about structure. You learn it by structuring ten small apps badly and noticing, around project six, that you're making the same mistake again.

What "bad on purpose" actually means

This isn't an excuse to write sloppy code and call it a strategy. Bad on purpose means something specific: you accept, going in, that the project won't be good, and you build it anyway instead of waiting until you know enough to do it right.

That's an important distinction, and it comes from actual research on how people learn, not just from folk wisdom about ceramics.

There's a concept in learning science called productive failure. The idea, studied by Manu Kapur and others, is that people who struggle to solve a problem before they're taught the "correct" way end up learning more than people who get the correct way handed to them first. In one study of pharmacy students, the group that struggled first didn't do any better on the immediate test. But a week later, when asked to apply what they'd learned to a new, related problem, they clearly outperformed the group that had been taught directly from the start.

The struggle isn't a detour on the way to learning. It's what makes the learning stick.

There's a caveat worth taking seriously here. The research is clear that this only works when the struggle is short, bounded, and followed by some kind of reflection or correction. Flailing at a project for six months with no plan and no follow-up isn't productive failure. It's just being stuck. The value comes from the loop: attempt, fail, notice why, move to the next attempt. Not from the failure alone.

Ten reps, not one masterpiece

This is also just how skill works, structurally. There's an old model of skill acquisition from researchers Stuart and Hubert Dreyfus, first built from studying Air Force pilots, that lays out how people move from novice to competent to expert. At the novice stage, you don't have any real context to draw on. You're just following rules with no sense of when they apply and when they don't. That only changes with repeated exposure to real, messy situations, not with more preparation before the first situation.

You can't think your way into that kind of context. You have to rack up the reps.

Ten small, bad projects give you ten separate collisions with reality. Project one teaches you that your local setup lies to you about what will work in production. Project three teaches you that the feature you were proudest of is the one nobody touches. Project seven teaches you that the bug you assumed was in your code was actually in a library you didn't read closely enough. None of that shows up in a tutorial. It only shows up when something you built actually breaks in front of you.

What each bad project is actually for

If you're going to do this on purpose, give each one a job.

Project one just needs to exist. Something small, ugly, deployed. A page, a button, a tool that does one dumb thing. The goal is only to go from nothing to something live, because that path has more friction than people expect the first time.

Project two through four are where you start breaking things on purpose. Rebuild a layout you like without looking at the source. Remove a piece of a working app and see what falls over. Ship something with a bug still in it and watch how it fails.

Project five through seven are where patterns start to repeat. You'll notice you're making the same structural mistake for the third time. That's not a sign you're bad at this. That's the first real signal that you're starting to see your own habits, which is the whole point.

Project eight through ten are where you start adding constraints on purpose. One hour only. No frameworks. No AI. Rebuild something that already exists from scratch. Constraints force you to solve problems instead of copying solutions, and copying solutions is the easiest way to finish a project without learning anything from it.

The part people skip

None of this works if you never look back at what you built.

A bad project you never revisit is just a bad project. A bad project you glance back at in a month, wincing at a decision you made, is the thing that actually teaches you something. That wince is the whole mechanism. It means you now know something you didn't know when you wrote that code, and the only way to know it was to write the bad version first.

So don't aim for one great project. Aim for ten bad ones you're willing to look at again later. The tenth one will still have problems. But it will have different problems than the first one, and that difference is what learning actually looks like.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
Don’t forget to subscribe to Developer’s Journey to show your support.

AI won't replace you, your refusal to learn it will

Muhammad Usman — Mon, 31 Aug 2026 14:46:22 +0000

If you count yourself among those people who don't know about these tools, I have bad news for you. You are far too left behind.

Tool	What it does
Opus	Model built for complex coding and reasoning
Fable	AI model for coding and agent workflows
Kimi	Chat model with long-context reasoning
Qwen	Open-weight chat and coding model
Anti-Gravity	AI-assisted coding environment
Cursor	Code editor with built-in AI
Open Code	Open-source AI coding tool
Codex	Generates and completes code
Grok	Chat model with real-time data access
Perplexity	AI search that cites its sources
Lovable	Turns prompts into working apps
Replit	Cloud coding platform with AI app builder
Higgsfield	Generates short-form AI video
Spark	Builds apps from plain text prompts
Cowork	AI workspace for multi-step tasks
Heygen	Generates talking AI avatar videos
Kling	Generates video from text or images
Omni	Handles text, voice, and visuals together
Hugging Face	Hub for hosting and running AI models
+ more...

Nobody sends you a memo when a new one ships. They just show up, get used by someone on your team, and one day you're the only one who hasn't touched them.

AI won't replace you. Your stubbornness on not learning AI will replace you. A developer who treats a new tool as optional is competing against one who doesn't. Same skill, same experience, different output six months from now.

You don't need all of them. You need one habit: when a name comes up twice, spend twenty minutes with it. Find out what it does. See if it fits something you already do slower than you'd like.

I request you learn and adapt, otherwise, you will be replaced.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
Don’t forget to subscribe to Developer’s Journey to show your support.

The hot AI term of the moment is the harness.

Muhammad Usman — Wed, 26 Aug 2026 16:52:57 +0000

The user interface you log into is the portion of your AI subscription that you interact with the most on a daily basis. The harness is that interface, but also everything underneath it. Things like projects, memory management, connectors, and skills. And that’s where I think we’re going to see a lot of the changes going forward.

A recent example: OpenAI just added a way to interact with iMessage on a Mac. You can ask ChatGPT to search your messages, catch you up on a conversation, draft a reply, even send it, all without opening the Messages app yourself. That’s a change to the harness. The model didn’t get smarter. The scaffolding around it just got another arm.

Now, Claude and ChatGPT kind of look the same. Chat box, projects, and skills have the same basic shape. But a harness that came out last week is taking a different swing at the interface. It’s a shared workspace. You can see who else is logged in, chat with them, and work through a session together where you’re co-authoring a presentation or a document or whatever, with the AI sitting right there in the thread with you instead of off in its own tab.

And I kind of like this shared workspace idea, because if I’m in a session with a coworker, I can watch how they prompt. Maybe they’re better at it than I am. I get to see that play out live, in real time, instead of just seeing their finished output. That’s kind of interesting to me. I think it’s kind of cool. It’s a genuinely different take on the interface, on the harness.

As we go forward and the models themselves, like Astra or Fable 5, get more and more powerful, I think the real differentiator between subscriptions stops being the model and starts being the interface. The harness. So I think companies are going to want to make sure their harness is the best one out there, just to keep you from wandering off to a different subscription.

Anyway, that’s what a harness is. Have a great day.

Hostinger vs Namecheap 2026: 20% Extra Discount Promo Code

Muhammad Usman — Thu, 13 Aug 2026 10:54:55 +0000

In this detailed Hostinger VS Namecheap comparison, we are putting both hosting providers side by side so you can clearly see which one gives you the best value for your money in 2026.

We are going to be testing several things, including pricing, performance, speed, uptime, customer support, and real features. And by the end of this comparison, I will tell you exactly which one I would choose if I had to start a brand new website today.

Get up to 20% extra off Hostinger using this special deal:
Hostinger special deal

Why You Should Trust This Hostinger VS Namecheap Comparison

Over the past couple of years, I have built and managed dozens of websites and online businesses. From small blogs to multi page funnels, SaaS projects, and ecommerce websites, I have handled all of them.

Navigating and jumping from one hosting provider to another has honestly been hell. But thank God I survived.

The fact that I have personally used both Hostinger and Namecheap, not just for testing but for real businesses, is exactly why this review is coming from personal experience, not from reading feature lists or blog posts.

What Is Hostinger Known For?

Hostinger DashboardHostinger is well known for its speed (lightspeed servers), affordability, and beginner friendly tools. One major feature that stands out is the free AI website builder.

This allows you to literally create a professional website in minutes just by describing your business. That alone makes Hostinger very attractive for beginners.

What Namecheap Is Best At

Namecheap started as a domain registrar, and from my experience, that is still where their biggest strength lies.

Most of my domain names are with Namecheap, and I honestly love sticking with a company where their biggest strength is very clear. That is exactly what I will most likely continue using Namecheap for going forward.

But here is the real question.

If you find a better option for hosting, will you still stick with Namecheap?

Hold on. I will get to that as we continue.

Hostinger VS Namecheap Pricing Breakdown in 2026

This is where the difference really starts to show.

At this particular point in time, Hostinger launched special deals on its hosting plans. With long term deals you can get a 24–48 month plan for an introductory price of around $1.99 to $2.99 per month, depending on the exact plan and discount applied. For many of these plans, a free domain name is included with the hosting.

Hostinger pricing plans> Grab Hostinger’s discounted plan here, click the link below:

Hostinger special discount

Now let us compare that with Namecheap.

Namecheap’s shared hosting Stellar plan starts at about $1.98 per month when billed annually.

Namecheap pricing plansHere is the catch.

With Hostinger’s introductory pricing, you also get:

A free domain name
Unlimited bandwidth
Professional email accounts
AI website builder
24/7 live customer support
And many more

With Namecheap you get a lower introductory price, but domain registration and email may still cost extra after the first year depending on the exact offer.

On pricing and value alone, Hostinger still gives more bundled features for what you pay upfront.

Hostinger VS Namecheap Speed and Performance Test

Now let us talk about speed.

In multiple tests, Hostinger consistently loads websites in under one second. This is thanks to their LiteSpeed servers and built in caching.

This is the speed of Hostinger even with a complete custom website.> This level of optimization is part of what Hostinger includes on its shared hosting plans.

👉 Link Hostinger includes on its shared hosting plans

Namecheap, on the other hand, averages around 1.8 to 2.5 seconds on shared hosting plans.

That speed is still decent, but it is not as optimized.

If performance matters to you, especially if you run an ecommerce business or you care about SEO, then Hostinger wins again at this level.

SSL, Uptime, and Security Comparison

Both Hostinger and Namecheap offer free SSL certificates and a 99.9 percent uptime guarantee.

However, Hostinger goes a step further by including automated weekly backups and Cloudflare protection by default.

With Namecheap, most of these things need to be configured manually.

So once again, Hostinger is clearly more beginner friendly.

Hostinger VS Namecheap Customer Support Experience

This is where a lot of budget hosting providers usually struggle.

Hostinger offers 24/7 live chat support that is fast, friendly, and actually helpful.

Hostinger With AI IntegratedNow, Namecheap support is also very decent. Honestly, I would even say they have one of the best customer support teams out there.

There have been many times when I needed things fixed quickly, and I did not want to start racking my brain. I contacted Namecheap support, and most times they helped me resolve the issue directly.

That is a huge plus for them.

But that was before I started using Hostinger.

Hostinger also has very good response times, and I would definitely give them credit for that.

At this level, I would honestly call it a draw. Both companies are really good when it comes to customer support.

Control Panel and Ease of Use

If you are new to building websites, this part matters a lot.

Hostinger uses its own custom control panel called hPanel. It is clean, modern, and built specifically for beginners. They also guide you through setups in real time, which makes the whole process very smooth.

Hostinger HPanelTheir AI website builder allows you to create a professional site in minutes just by explaining what your business does.

Namecheap still uses cPanel, which is fine for technical users, but it is not as simple visually.

If you want something plug and play, Hostinger wins again.

Total Cost Comparison Over Two Years

If you are building a brand website, blog, or ecommerce store, the numbers matter.

With Hostinger’s long-term plan, your total cost for two years, including the domain, comes down to a very competitive price compared to similar hosted packages.

With Namecheap, once you add domain registration, email hosting, and other extras, you will likely spend more over two years even with their own introductory prices.

That means more savings upfront with Hostinger and often faster load times over time.

Final Verdict: Hostinger VS Namecheap

Both Hostinger and Namecheap are legit, secure, and affordable.

But here is my honest take.

I would go with Hostinger if you want speed, simplicity, and long term savings.

You should only choose Namecheap if you already have your domain there and you just need basic hosting for small projects.

For 2026 and beyond, Hostinger takes the win.

Let me know your thoughts and concerns in the comments, and you can also join my community through the link provided.

For those comparing Hostinger VS Namecheap in 2026, Hostinger remains a strong choice for performance, ease of use, and overall value. If you want, you can get an extra 20% discount using my code directly with your plan.
👉 Extra 20% discount using this LINK.

7 Habits of Developers Who Never Have to Optimize Later

Muhammad Usman — Fri, 07 Aug 2026 07:19:47 +0000

Open DevTools right now. Go to the Network tab, find the throttling dropdown, and set it to Slow 3G. Now reload something you built.

Watch the blank white screen sit there for a few seconds. Watch the layout jump around as fonts and images land out of order. Somewhere in the world, someone is looking at that exact screen on that exact connection, right now, and they don't have a throttling dropdown to turn back off.

"Optimize later" is one of the most common plans in web development, and it's also one of the most misleading. It suggests performance is a separate phase, something you schedule after the feature is done, the way you'd schedule a coat of paint after the walls go up. In practice it rarely gets scheduled at all. The feature ships, the next feature starts, and the page just keeps getting a little heavier, a little slower, until a Lighthouse score forces the conversation nobody planned for.

The developers who never have that conversation aren't smarter or more disciplined in some abstract way. They just built a handful of habits into how they write code every day, so performance was never a separate phase to schedule in the first place. None of what follows costs extra time once it's automatic. Most of it saves time, because catching a heavy dependency while you're still deciding whether to add it is faster than ripping it out after six other things depend on it.

Here are the seven that stuck.

1. Check what the page already ships before adding to it

For a long time my instinct was to reach for whatever solved the immediate problem. Need a date picker, install a date picker. Need icons, install an icon library. The Network tab was something I opened when something was already slow, not before I made it slower.

Now it's the other way around. Before adding anything, I check what's already going out over the wire.

DevTools → Network tab → reload → look at the size column at the bottom
Total: 847 KB transferred, 2.1 MB resources

That number is the actual starting condition for anything I'm about to add. A 40 KB date picker library means something different on a page that's already shipping 200 KB than on one shipping 2 MB. Checking first doesn't mean never adding a dependency. It means the decision is made with the real number in front of you, not a vague sense that "it's probably fine."

2. Reach for the platform before reaching for a library

Modals used to be one of the more expensive things I'd casually build: a backdrop div, a focus trap, an escape key handler, scroll locking on the body, all wired together by hand or, more often, pulled in from a library that did all of it plus a hundred features I didn't need.

The <dialog> element has had solid cross-browser support since 2022, and it handles most of that for free.

<!-- What used to require a library -->
<dialog id="confirm-dialog">
  <p>Delete this item?</p>
  <button id="cancel">Cancel</button>
  <button id="confirm">Delete</button>
</dialog>
<button id="open-dialog">Delete item</button>

<script>
  const dialog = document.getElementById('confirm-dialog');
  document.getElementById('open-dialog').addEventListener('click', () => dialog.showModal());
  document.getElementById('cancel').addEventListener('click', () => dialog.close());
</script>

Calling dialog.showModal() gets you the backdrop, focus trapping, top-layer rendering above everything else on the page, and Escape-to-close, all handled by the browser. No z-index war, no focus trap library, no separate accessibility audit finding what the hand-built version missed. The habit isn't "never use a library." It's checking whether the platform already solved this specific problem before adding forty KB to solve it again.

3. Load what's needed, not what might be needed

A <script> tag in the <head> with no attributes blocks the browser from doing anything else until that file downloads and runs. I used to write those by default and only notice the blocking behavior once a page felt sluggish enough to investigate.

<!-- Blocks rendering until this loads and executes -->
<head>
  <script src="analytics.js"></script>
</head>

<!-- Downloads in parallel, runs after the HTML is parsed -->
<head>
  <script src="analytics.js" defer></script>
</head>

defer alone fixes the render-blocking problem for most scripts. For code that isn't needed until later, like a component behind a click or a tab that's not visible on load, a dynamic import defers the actual download too.

// Only fetched when someone actually opens the settings panel
button.addEventListener('click', async () => {
  const { openSettingsPanel } = await import('./settings-panel.js');
  openSettingsPanel();
});

Neither of these is a refactor I do after noticing a slow load. They're the default way I write a script tag or an import now, the same way const became the default over var.

4. Treat images as a budget, not an afterthought

Images are usually the single biggest thing on a page, and for a long time I treated them as a last step: drop the file in, write the src, move on. The size, format, and dimensions all got decided by whatever the design file happened to export.

<!-- What I used to ship -->
<img src="hero-photo.jpg">

<!-- What I check for now, every time an image goes in -->
<img
  src="hero-photo.jpg"
  srcset="hero-photo-480.jpg 480w, hero-photo-960.jpg 960w, hero-photo-1600.jpg 1600w"
  sizes="(max-width: 600px) 480px, (max-width: 1200px) 960px, 1600px"
  width="1600"
  height="900"
  loading="lazy"
  alt="A description of what's actually in the photo">

srcset and sizes mean a phone downloads a 480px image instead of the same 1600px file a desktop gets. width and height reserve the space before the image loads, which is most of what keeps Cumulative Layout Shift under the 0.1 threshold Google treats as good. loading="lazy" skips the download entirely for images below the fold until someone scrolls near them. None of this is exotic. It's four attributes and a srcset, decided at the moment the image goes in rather than discovered later in a performance audit.

5. Measure before you guess

I used to have strong opinions about what was slow on a page, and they were usually wrong. The animation felt janky, so I'd assume it was the animation. The page felt sluggish on load, so I'd assume it was the biggest image. Guessing feels like progress. It's usually just motion in a random direction.

// A real measurement instead of a guess
performance.mark('data-fetch-start');
const data = await fetchDashboardData();
performance.mark('data-fetch-end');

performance.measure('data-fetch', 'data-fetch-start', 'data-fetch-end');
console.log(performance.getEntriesByName('data-fetch')[0].duration);

For the metrics that actually matter to real users, DevTools' Performance panel will show the specific element responsible for Largest Contentful Paint, the metric for how long the biggest visible piece of content takes to render. Good is under 2.5 seconds. If that element turns out to be a font-loading heading instead of the hero image I assumed was the problem, the fifteen minutes I would have spent compressing that image was going to fix nothing. Measuring first means the time spent optimizing actually goes toward the thing that was slow.

6. Let the browser do the layout work it's already good at

For years I animated position the same way I'd set it in a stylesheet: top and left, sometimes margin. All three trigger the same layout recalculation. It worked, but "worked" and "smooth" aren't the same thing, especially on a mid-range phone with a dozen other things competing for the main thread.

/* Forces the browser to recompute layout on every frame */
.card {
  position: relative;
  transition: top 0.3s ease;
}
.card:hover {
  top: -8px;
}

/* Handled entirely by the compositor, no layout recalculation */
.card {
  transition: transform 0.3s ease;
}
.card:hover {
  transform: translateY(-8px);
}

top and left sit in the layout stage of the rendering pipeline: the browser has to recompute where every affected element sits, then repaint, on every single frame. transform and opacity skip both steps and get handled on the compositor, which is why the second version stays smooth even when the main thread is busy with something else. Same visual result, one version asks the browser to do far less work to produce it.

7. Run one performance budget check before every commit

Performance regressions almost never arrive as one dramatic change. They arrive as a 30 KB dependency here, an unoptimized image there, each one individually reasonable, none of them ever really addressed until a bundle analyzer or a Lighthouse run several months later delivers the bad news all at once.

// A budget check that runs as part of the build, not as a separate audit
import { readFileSync } from 'fs';

const bundle = readFileSync('dist/main.js');
const sizeInKB = bundle.length / 1024;
const budget = 150;

if (sizeInKB > budget) {
  console.error(`Bundle is ${sizeInKB.toFixed(1)} KB, budget is ${budget} KB`);
  process.exit(1);
}

A few lines like this, wired into a build script or a CI step, turn "the bundle got big somehow" into "this specific commit added 40 KB, here's why." It doesn't catch everything. It won't tell you if an interaction feels laggy or if your Largest Contentful Paint element is the wrong one. But it catches the slow, compounding kind of regression while it's still one commit, back when the fix is removing a line instead of untangling six months of small additions.

None of these habits are big undertakings on their own. Checking a Network tab before adding a dependency takes ten seconds. Writing defer instead of leaving it off costs nothing. That's really the point: optimizing later feels necessary because performance got treated as a separate concern from the actual writing of the code. Treat it as part of the same decision you're already making, when you add the script tag, when you drop in the image, when you write the transition, and there's no separate phase left to schedule.

Go throttle your connection again sometime, on something you're building right now. Not to feel bad about what you find. Just to see it once, the way someone on a slower connection already does, every day, whether you ever open that dropdown or not.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
Don’t forget to subscribe to Developer’s Journey to show your support.

Cursor: The One Element in Your Web Almost Nobody Designs

Muhammad Usman — Thu, 06 Aug 2026 10:53:36 +0000

Did you know that if you add this little snippet of code to your website, you can replace your mouse cursor with pretty much anything?

button:hover {
  cursor: url("cursor.png"), pointer;
}

Instead of the default arrow, you can turn it into an emoji, an icon, or a tiny custom graphic. That comma before pointer matters. The browser tries to load cursor.png first. If it fails, or the browser doesn't support custom cursors, it falls back to the normal pointer. Never skip that fallback.

Each element below is fully interactive. Hover over any of them and watch the cursor change on the spot.

I wouldn’t recommend replacing the cursor for your entire website. Keep it close to what people already expect. But scoped to one interaction, at one moment, it turns something completely ignored into a small detail people notice. Here’s where it actually earns its place.

" width="799" height="311">

Say what the click does, not just that it's clickable

A pointer only tells someone "this is interactive." A custom cursor can tell them what interacting does.

.zoom-image:hover {
  cursor: url("magnifier.png") 12 12, zoom-in;
}
.crop-tool:hover {
  cursor: url("scissors.png") 4 4, crosshair;
}
.drag-card:hover {
  cursor: grab;
}
.drag-card:active {
  cursor: grabbing;
}

Those two numbers after the URL, 12 12and 4 4, set the cursor's hotspot. That's the exact pixel inside your image that lines up with the actual click point. Skip them and the browser defaults to the top left corner of the image, which looks wrong almost every time, especially on anything shaped like scissors or a pointing hand.

Add a bit of personality to your main call to action

This is the fun one. Swap the cursor for a tiny branded icon right on the button you most want someone to click.

.cta-button:hover {
  cursor: url("rocket.png") 4 4, pointer;
}

You don't even need an image file for this. An SVG data URI does the same job with zero extra requests:

.like-button:hover {
  cursor: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32"><text y="24" font-size="24">❤️</text></svg>') 16 16, pointer;
}

It's one line, nothing to host, and the emoji scales cleanly since it's just text sitting inside SVG markup.

Give portfolios and case studies a signature feel

Designers and agencies get away with a lot more here, because a custom cursor reads as craft instead of gimmick when the whole site is already built around visual work.

.project-thumb:hover {
  cursor: url("view-pill.png") 30 10, pointer;
}

A small pill-shaped cursor that says "View" while hovering a thumbnail does more work than a caption ever could. People move their mouse before they read anything.

Turn it into a small warning

Right before a destructive action, a cursor change adds one extra beat of friction.

.delete-account-btn:hover {
  cursor: url("warning.png") 12 12, not-allowed;
}

The person still has to move their mouse over the button and register that something changed. That half second is sometimes enough to make them pause and reconsider.

Build a world for exploration-based sites

Interactive stories, narrative scrollers, and portfolio sites built around a theme can carry that theme into the cursor itself.

.map-section:hover {
  cursor: url("compass.png") 16 16, pointer;
}

.dark-mode .story-panel:hover {
  cursor: url("torch.png") 8 24, pointer;
}

It's a small thing, but it reinforces that the visitor is inside something built with intention, not just scrolling a normal page.

Keep these rules in mind

Size your cursor images small. Most browsers cap custom cursors around 128x128 pixels, and anything bigger gets ignored or scaled down badly. 32x32 or 48x48 is usually the sweet spot.

Always include a fallback keyword after your URL, whether that's pointer, grab, zoom-in, or not-allowed. Some browsers and some users won't load the custom image at all, and you don't want the button falling back to nothing.

And keep it local. One button, one thumbnail, one section. The moment your entire site runs on a custom cursor, it stops feeling like a surprise and starts feeling like a bug.

Happy designing.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
Don’t forget to subscribe to Developer’s Journey to show your support.

JavaScript ES2026 Just Shipped What Developers Have Been Asking for Years

Muhammad Usman — Fri, 31 Jul 2026 19:16:15 +0000

For 30 years, JavaScript developers have been quietly suffering. Date object had a lot of limitations, and every developer knows it. Time zone issue came, and it had to be a lot of calculation just for the expected date. Every time you built a regular expression from user input, you had to remove special characters yourself first. Every time you weren’t sure if a function was synchronous or asynchronous, you wrote two code paths just to be safe.

All that is over now.

ES2026, the 17th edition of the language, just got finalized, and it brings the Temporal API into the spec alongside a handful of smaller fixes that already landed the year before. JavaScript is finally getting smarter day by day. Not louder, not flashier, but smarter. These are real, spec-confirmed features you can use today, and this article shows exactly why each one is worth your time, with production-level code for every single one.

Don’t just read about it. Try it.
Everything below runs live in your browser, no copying code required.

Let’s go through it, feature by feature.

1. The Temporal API: Dates Finally Stop Being a Nightmare

Let’s start with the big one, because this is the fix people have wanted for three decades.

The Date object was never designed well. It was copied from Java in 1995, during the original 10-day sprint to build JavaScript, and it came with problems baked in from day one. Months start counting from zero but days don't. Date objects are mutable, so passing one into a function can quietly change it without you knowing. And time zone support was basically an afterthought, so anything involving daylight saving time turned into manual math that broke constantly.

Here’s what that pain actually looks like in code:

// Months are zero-indexed. December is 11. Everyone gets this wrong at least once.
const christmas = new Date(2026, 11, 25);
console.log(christmas.getMonth()); // 11

// Date objects are mutable, so this is a silent trap.
const meeting = new Date();
function reschedule(d) {
  d.setFullYear(1900); // this changes the original object, not a copy
}
reschedule(meeting);
console.log(meeting.getFullYear()); // 1900, and you didn't ask for that
// There was never a clean way to ask "what time is it in Tokyo right now"
// without writing your own offset math, and that math breaks the moment DST hits.

Because Date was this limited, the whole ecosystem built an industry around fixing it. Moment.js, date-fns, and Day.js combined pull in tens of millions of downloads every single week, just to patch a hole that should never have existed in the language.

That’s exactly what the Temporal API solves. It reached TC39 Stage 4 and is now officially part of ES2026, the 17th edition of the spec, approved on June 30, 2026. It isn’t a patch on top of Date, it's a completely new global namespace, similar to Math or Intl, with a set of purpose-built, immutable types:

Temporal.PlainDate for a calendar date with no time zone attached
Temporal.PlainTime for a wall-clock time with no date attached
Temporal.ZonedDateTime as the real replacement for Date, time zone aware from the start
Temporal.Duration for representing spans of time properly
Temporal.Instant for an exact point on the UTC timeline

Here’s the same logic from before, rewritten with Temporal:

// Every operation returns a brand new object. Nothing gets mutated behind your back.
const meeting = Temporal.PlainDate.from("2026-03-15");
const rescheduled = meeting.with({ year: 1900 });

console.log(meeting.toString()); // "2026-03-15", untouched
console.log(rescheduled.toString()); // "1900-03-15", the new one
// Time zones are explicit now, not something you calculate by hand.
const tokyoNow = Temporal.Now.zonedDateTimeISO("Asia/Tokyo");
const nycNow = Temporal.Now.zonedDateTimeISO("America/New_York");
console.log(tokyoNow.toString());
console.log(nycNow.toString());
// Duration math without converting everything to milliseconds yourself.
const projectStart = Temporal.PlainDate.from("2026-01-10");
const projectEnd = Temporal.PlainDate.from("2026-07-22");
const timeSpent = projectStart.until(projectEnd, { largestUnit: "month" });
console.log(timeSpent.toString()); // "P6M12D" - 6 months and 12 days
// Daylight saving time is handled correctly instead of silently breaking.
// On March 29, 2026, clocks in London jump forward and 00:30 to 01:30 doesn't exist.
const beforeDST = Temporal.ZonedDateTime.from(
  "2026-03-29T00:30[Europe/London]"
);
const afterOneHour = beforeDST.add({ hours: 1 });
console.log(afterOneHour.toString()); // correctly resolves to 02:30

Firefox and Chromium-based browsers already ship this natively, and Safari has partial support in Technology Preview right now. If you need it in older environments today, the @js-temporal/polyfill package gives you the exact same API, so your code doesn't need to change later.

If your app deals with scheduling, bookings, financial timestamps, or anything international, this single feature alone justifies paying attention to JavaScript again.

2. Promise.try: Now You Can Handle Sync and Async the Same Way

Now here’s a problem almost every JavaScript developer runs into. You’re calling a function, but you don’t know if it’s synchronous or asynchronous. So if it throws synchronously instead of rejecting a promise, your .catch() never even fires, and the error just crashes things instead of being handled properly.

Before this, people wrote their own wrapper to force consistent behavior:

// The old defensive wrapper everyone rewrote in their own codebase
function safelyRun(fn) {
  return new Promise((resolve, reject) => {
    try {
      resolve(fn());
    } catch (err) {
      reject(err);
    }
  });
}

safelyRun(() => riskyOperation())
  .then(result => console.log(result))
  .catch(err => console.error('Handled:', err));

It worked fine, but it’s the kind of thing every project reinvented slightly differently. Promise.try turns this into a native method:

// Whether validateUser is sync or async, this handles both the same way
function validateUser(user) {
  if (!user.email) {
    throw new Error('Missing email'); // synchronous throw
  }
  return fetch(`/api/verify/${user.id}`).then(r => r.json()); // asynchronous path
}

Promise.try(() => validateUser(currentUser))
  .then(result => console.log('Validated:', result))
  .catch(err => console.error('Validation failed:', err));
// A real use case: a plugin system where you don't control how plugins are written
async function runPlugin(plugin, context) {
  return Promise.try(() => plugin.execute(context))
    .catch(err => {
      logPluginError(plugin.name, err);
      return null; // fail gracefully instead of crashing everything
    });
}

Throw synchronously

Reject asynchronouslySo now you can handle synchronous and asynchronous functions both in the same way, without maintaining your own wrapper just to be safe.

3. RegExp.escape: Now You Don’t Have to Remove Special Characters Yourself

Now, if you take input from a user and you have to convert it into a regular expression, you already know this problem. Regex has its own special characters, things like . * + ? ( ) [ ] { } | ^ $, and if user input contains any of them, your regex either throws an error or quietly matches the wrong thing. Normally, you had to remove the special characters yourself before you could convert it into a regular expression.

The old approach usually looked like this, hand-rolled or pulled in from an npm package:

// The old way, written from scratch or installed as a dependency
function escapeRegExp(string) {
  return string.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
}

const userSearch = 'Price: $5.00 (on sale!)';
const pattern = new RegExp(escapeRegExp(userSearch), 'gi');

Now there’s a new method introduced, called escape, and it automatically removes the guesswork for you:

const userSearch = 'Price: $5.00 (on sale!)';

// RegExp.escape neutralizes every special character for you
const safePattern = new RegExp(RegExp.escape(userSearch), 'gi');
console.log(RegExp.escape(userSearch));
// "Price:\x205\.00\x20\(on\x20sale!\)"
// Spaces become \x20 hex escapes, and actual regex syntax characters like
// $ . ( ) get a simple backslash. Plain punctuation like : and ! is left alone,
// since it has no special meaning in a regex pattern to begin with.
// Real use case: highlighting a search term safely
function highlightMatches(text, searchTerm) {
  const pattern = new RegExp(RegExp.escape(searchTerm), 'gi');
  return text.replace(pattern, match => `<mark>${match}</mark>`);
}
console.log(highlightMatches('Get 20% off (limited time)', '20% off (limited time)'));
// safely matches the literal string, special characters included

RegExp.escapeOne thing worth being clear about: RegExp.escape protects you from regex injection specifically. It's not protection against HTML injection or SQL injection. If matched text is going into the DOM, you still need proper HTML escaping on top of this. Different problem, different fix.

4. Now You Can Use Map, Filter, and Take on Iterators Too

This is the one that shows JavaScript getting smarter day by day, and it’s easy to miss at first glance. Before this, if you wanted to use .map() or .filter() on a generator, a Set, or any custom iterable, you had two options. Convert it into an array first, which means loading everything into memory even if you only need the first few results, or write your own manual loop every single time.

// The old way: force it into an array just to use familiar methods
function* readLogLines() {
  yield 'INFO: server started';
  yield 'ERROR: connection refused';
  yield 'INFO: request received';
  yield 'ERROR: timeout on request 442';
  yield 'INFO: request completed';
  // imagine this generator streams millions of lines from a real log file
}

const firstThreeErrors = Array.from(readLogLines())
  .filter(line => line.startsWith('ERROR'))
  .slice(0, 3); // the whole log still gets loaded into memory first

Now you can chain .map(), .filter(), .take(), .drop(), and more, directly on the iterator itself, lazily, so nothing gets computed until you actually need it:

function* readLogLines() {
  yield 'INFO: server started';
  yield 'ERROR: connection refused';
  yield 'INFO: request received';
  yield 'ERROR: timeout on request 442';
  yield 'INFO: request completed';
}

// Lazy pipeline. Stops pulling from the generator the moment it has 3 matches.
const firstThreeErrors = readLogLines()
  .filter(line => line.startsWith('ERROR'))
  .map(line => line.replace('ERROR: ', ''))
  .take(3)
  .toArray();
console.log(firstThreeErrors);
// ["connection refused", "timeout on request 442"]
// Real use case: pulling from a paginated or unbounded data source
function* fetchAllUserIds() {
  let page = 1;
  while (true) {
    const ids = getUserIdsForPage(page); // pretend API call
    if (ids.length === 0) return;
    yield* ids;
    page++;
  }
}
const first50ActiveUsers = fetchAllUserIds()
  .filter(id => isUserActive(id))
  .take(50)
  .toArray();

For anything dealing with large or unbounded data, streaming logs, paginated APIs, infinite sequences, this is the difference between pulling gigabytes into memory and processing only what you actually need.

Where Things Actually Stand Right Now

To be straightforward about it, since accuracy matters more than hype here:

Promise.try, RegExp.escape, and iterator helpers shipped as part of ES2025, the 16th edition, and they’re already available in current versions of Chrome, Firefox, Safari, and Node.

The Temporal API is officially part of ES2026, the 17th edition, approved on June 30, 2026. Firefox and Chromium-based browsers already support it natively, Safari has partial support in Technology Preview, and the official polyfill covers everything else in the meantime.

None of this is speculative or “coming eventually.” Every snippet above works exactly as written in a current browser, or through the Temporal polyfill if you need broader coverage today.

JavaScript isn’t getting louder with every release, it’s getting smarter, day by day. It’s quietly fixing the exact problems that made developers reach for a library before writing five lines of native code. If you’ve been putting off checking what’s new, this is genuinely worth your time. Please try these out in your own code, and let me know in the comments which one saves you the most headaches.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

Copy These 29 Text Animations. The Code Is Already Done.

Muhammad Usman — Mon, 20 Jul 2026 10:37:15 +0000

Most text animation on the web is the same three tricks wearing different clothes: fade something in, slide something up, maybe throw a blur on it. I wanted to know how far past those three tricks you could actually go without reaching for a heavy animation library, so I built twenty-nine of them, side by side, in plain CSS and JavaScript. Some are one property. Some are a canvas loop. All of them run without a single dependency.

Here’s what I learned building all twenty-nine, organized by what they’re actually for: pulling a reader’s eye to new content, holding their attention on something static, responding to their cursor, or clearing the stage for what comes next.

As promised, here are all the examples.

Reveal: getting text to arrive instead of just appearing

The simplest possible text animation is opacity: 0 to opacity: 1. It works. It's also invisible as a design choice, because every site does it. The interesting question is what happens between 0 and 1.

Scramble

This animation replaces letters with noise before resolving them, left to right, like a decoding sequence:

function run() {
  let revealed = 0;
  let frame = 0;
  timer = setInterval(() => {
    frame++;
    let out = "";
    for (let i = 0; i < target.length; i++) {
      if (target[i] === " ") {
        out += " ";
        continue;
      }
      out += i < revealed ? target[i] : CHARS[randInt(0, CHARS.length - 1)];
    }
    el.textContent = out;
    if (frame % 3 === 0) revealed++;
    if (revealed > target.length) clearInterval(timer);
  }, 40);
}

The trick is the frame % 3 check. Without it, a letter locks in on every single tick, and the whole word resolves in a blink. Slowing the reveal rate independently of the redraw rate is what makes it read as decoding rather than flickering.

Stagger Fade and Blur Focus

Both animations split text into individual character spans and animate each one on a delay proportional to its position:

function splitToSpans(el, textOverride, staggerMax) {
  const chars = [...text];
  const len = Math.max(chars.length - 1, 1);
  chars.forEach((ch, i) => {
    const s = document.createElement("span");
    s.className = "ch";
    if (staggerMax) {
      s.style.setProperty("--d", ((i / len) * staggerMax).toFixed(0) + "ms");
    }
    s.textContent = ch === " " ? "\u00A0" : ch;
    frag.appendChild(s);
  });
}

.stage[data-anim="blur"] .ch {
  opacity: 0;
  filter: blur(14px);
  transform: scale(1.06);
  transition: opacity 0.6s ease, filter 0.6s ease, transform 0.6s ease;
  transition-delay: var(--d, 0ms);
}

Notice the delay is computed once, in JavaScript, then handed to CSS as a custom property. The animation itself is pure CSS transition; JavaScript’s only job is figuring out how long each letter should wait its turn. This split matters because it means the animation performance comes from the browser’s transition engine, not from a JavaScript timing loop trying to keep twenty things in sync.

3D Flip-In

This one takes the same staggered-span approach and adds a hinge:

.stage[data-anim="flip"] {
  perspective: 600px;
}
.stage[data-anim="flip"] .ch {
  transform: rotateX(90deg) translateY(6px);
  transform-origin: 50% 100%;
  transition: transform 0.5s cubic-bezier(0.2, 0.9, 0.3, 1.2);
}

perspective on the parent is what gives rotateX something to rotate through. Skip it and the letters just squash flat instead of appearing to fold toward you.

Split-Flap

This is the one that actually earns its comparison to an airport departures board, because each letter cycles through real random characters before landing, at a slightly different speed per letter:

spans.forEach((s, i) => {
  const finalChar = target[i];
  let count = 0;
  const total = randInt(8, 16);
  const t = setInterval(() => {
    count++;
    if (count >= total) {
      s.textContent = finalChar;
      clearInterval(t);
    } else s.textContent = CHARS[randInt(0, CHARS.length - 1)];
  }, 45 + i * 4);
});

45 + i * 4 is doing quiet work here. Each letter's interval runs slightly slower than the one before it, so they don't all land on the same frame. That small stagger is the entire difference between "looks like a glitch" and "looks like a mechanism."

Curtain Wipe and Ink Signature

Both fake a reveal without touching the text’s own opacity at all. The curtain is a solid bar sitting on top of the word that shrinks away:

.curtain-bar {
  transform-origin: left;
  transform: scaleX(1);
  transition: transform 0.9s cubic-bezier(0.6, 0, 0.15, 1);
}
.stage[data-anim="curtain"].in .curtain-bar {
  transform: scaleX(0);
}

The ink signature draws an SVG path underneath the word using the classic dash offset trick:

.ink-underline path {
  stroke-dasharray: 340;
  stroke-dashoffset: 340;
  transition: stroke-dashoffset 1s ease;
}
.stage[data-anim="ink"].in .ink-underline path {
  stroke-dashoffset: 0;
}

Set the dash array and the offset to the same number, and the entire stroke starts invisible. Animate the offset to zero, and the line appears to draw itself. No JavaScript needed for the drawing itself, just the intersection observer that adds the .in class when the element scrolls into view.

Glitch Split

This is the one specimen in this group that runs continuously instead of triggering once, using duplicated text layered in red and cyan with clipped, offset keyframes:

.glitch::before {
  content: attr(data-text);
  color: #ff3b6b;
  transform: translate(-2px, 0);
  mix-blend-mode: screen;
  animation: glitchTop 2.6s infinite linear;
}
@keyframes glitchTop {
  0%,
  89%,
  100% {
    clip-path: inset(0 0 0 0);
    transform: translate(0, 0);
  }
  90% {
    clip-path: inset(10% 0 60% 0);
    transform: translate(-3px, -1px);
  }
}

The 0%, 89%, 100% selector is the key. Ninety percent of the animation cycle is a clean, un-glitched hold. The glitch itself lives in a narrow 10% window. That ratio is what keeps it readable as text with an occasional artifact, rather than an unreadable flicker.

Loop: text that keeps moving because it’s meant to be looked at, not read

Reveal animations run once and stop. Loop animations are for text that needs to hold attention indefinitely, a hero headline, a status indicator, a ticker.

Wave

This staggers a vertical bounce per character using the same --i index every span already carries:

.stage[data-anim="wave"].in .ch {
  animation: waveMove 1.8s ease-in-out infinite;
  animation-delay: calc(var(--i) * 60ms);
}

animation-delay runs off calc() reading straight from the custom property, so there's no per-letter JavaScript at all beyond the initial split. That's worth noticing: three of the loop animations in this set reuse the exact same span-splitting utility that the reveal animations use. The difference between "letters fade in" and "letters bounce forever" is which CSS rule you attach to .ch, not how you built the letters.

Shimmer

This fakes a light sweep using a gradient clipped to text:

.stage[data-anim="shimmer"] .demo {
  background: linear-gradient(
    100deg,
    var(--paper-dim) 30%,
    var(--brass) 45%,
    #fff 50%,
    var(--brass) 55%,
    var(--paper-dim) 70%
  );
  background-size: 250% 100%;
  -webkit-background-clip: text;
  background-clip: text;
  color: transparent;
}
@keyframes shimmerMove {
  0% {
    background-position: 200% 0;
  }
  100% {
    background-position: -100% 0;
  }
}

The gradient is three times wider than the text (250%), which is what lets the bright band slide across and off the edges cleanly instead of popping in and out abruptly.

Breathing Glow

This is the smallest amount of code in the whole set for one of the more effective results, just an oscillating text-shadow:

@keyframes glowPulse {
  0%,
  100% {
    text-shadow: 0 0 4px rgba(227, 169, 74, 0.15);
  }
  50% {
    text-shadow: 0 0 26px rgba(227, 169, 74, 0.8),
      0 0 6px rgba(227, 169, 74, 0.55);
  }
}

Two shadow layers at the peak, one wide and soft, one tight and bright, is what sells the glow. A single shadow value just looks like the text got fuzzy.

Liquid Wobble

This treats each letter like it’s suspended in something viscous, skewing and squashing on a cycle:

@keyframes liquidWob {
  0%,
  100% {
    transform: skewX(0) scaleY(1);
  }
  25% {
    transform: skewX(-6deg) scaleY(1.08);
  }
  50% {
    transform: skewX(0) scaleY(0.94);
  }
  75% {
    transform: skewX(6deg) scaleY(1.05);
  }
}

Eased Marquee

This replaces the classic linear scroll with a cubic-bezier that accelerates, holds, and decelerates:

@keyframes marqueeMove {
  0% {
    transform: translateX(6%);
  }
  45% {
    transform: translateX(-40%);
  }
  50% {
    transform: translateX(-40%);
  }
  95% {
    transform: translateX(6%);
  }
  100% {
    transform: translateX(6%);
  }
}

That flat stretch from 45% to 50% is a deliberate pause at the far end of the scroll, giving a reader’s eye a moment to land before the track reverses. Pure linear marquees never rest, which is exactly why they read as cheap.

Kinetic Rotator

This is the one loop animation that’s mostly JavaScript, because it’s swapping entire words, not animating one fixed string:

function show() {
  el.textContent = words[idx];
  el.style.opacity = 0;
  el.style.transform = "translateY(18px)";
  requestAnimationFrame(() => {
    el.style.opacity = 1;
    el.style.transform = "translateY(0)";
  });
}

The requestAnimationFrame wrapper matters more than it looks like it should. Set the transform and immediately flip opacity in the same tick, and the browser may collapse both style writes into one paint, skipping the transition entirely. Forcing a frame boundary between "set the start state" and "set the end state" is what guarantees the transition actually plays.

Interactive: animations that need a cursor to mean anything

These five don’t animate on their own. They’re built to respond to the reader in real time, which means the JavaScript is doing continuous math on every mousemove event instead of firing once and finishing.

Magnetic Pull

This measures the distance from the cursor to each letter’s center and nudges the letter toward it:

stage.addEventListener("mousemove", (e) => {
  spans.forEach((s) => {
    const dx = mx - cx,
      dy = my - cy;
    const dist = Math.max(30, Math.sqrt(dx * dx + dy * dy));
    const pull = Math.min(1, 90 / dist);
    s.style.transform = `translate(${dx * pull * 0.35}px, ${
      dy * pull * 0.35
    }px)`;
  });
});

Math.max(30, ...) prevents a division that blows up as the cursor gets close to a letter's exact center. Without that floor, 90 / dist approaches infinity and the letter would jump wildly instead of easing toward the cursor.

Weight Morph

This does something you can’t do with a JPEG: it changes the actual weight axis of a variable font in response to proximity.

const dist = Math.abs(mx - cx);
const wght = Math.max(300, 900 - dist * 6);
s.style.fontVariationSettings = `"wght" ${wght}`;

This only works because the font file itself has weight defined as a continuous variable axis rather than a fixed set of files (400, 700, and so on). Static font formats can’t do this at all; there’s no in-between file to interpolate toward.

Cursor Distort

This applies a fisheye skew based on horizontal distance from the pointer, with the skew direction flipping depending on which side the cursor sits:

const dist = mx - cx;
const proximity = Math.max(0, 1 - Math.abs(dist) / 120);
const skew = (dist > 0 ? -1 : 1) * proximity * 18;

Scroll Scrub

This ties a text fill directly to scroll position instead of the cursor, using a gradient clipped to text with a hard stop at a variable percentage:

function update() {
  const r = stage.getBoundingClientRect();
  let progress = 1 - (r.top + r.height / 2) / (vh + r.height / 2);
  stage.style.setProperty("--p", (progress * 100).toFixed(1) + "%");
}

.stage[data-anim="scrub"] .demo {
  background: linear-gradient(
    90deg,
    var(--paper) var(--p, 0%),
    var(--paper-dim) var(--p, 0%)
  );
  -webkit-background-clip: text;
  background-clip: text;
  color: transparent;
}

The gradient has a hard edge, not a soft one, because both color stops sit at the exact same position (var(--p)). That's what turns a gradient into a fill meter instead of a blur.

Hover Scatter

This is the simplest of the five: split the word into spans, then on mouseenter, throw each one to a random offset and rotation, and let a CSS transition pull it back on mouseleave.

stage.addEventListener("mouseenter", () => {
  spans.forEach((s) => {
    s.style.transform = `translate(${rand(-40, 40)}px, ${rand(
      -30,
      30
    )}px) rotate(${rand(-40, 40)}deg)`;
  });
});

The animation is entirely the CSS transition on .ch; JavaScript only ever sets a target, never runs the motion itself.

Exit: clearing the stage, deliberately

Exit animations get less attention than entrances, but they’re what makes a hover interaction feel complete instead of half finished.

Shatter

This pre-computes a random trajectory per letter, storing it as CSS custom properties the moment the page loads, then triggers the actual motion purely through :hover:

spans.forEach((s) => {
  s.style.setProperty("--tx", rand(-120, 120).toFixed(0) + "px");
  s.style.setProperty("--ty", rand(-90, 90).toFixed(0) + "px");
  s.style.setProperty("--tr", rand(-90, 90).toFixed(0) + "deg");
});

.stage[data-anim="shatter"]:hover .ch {
  transform: translate(var(--tx, 0), var(--ty, 0)) rotate(var(--tr, 0deg));
  opacity: 0;
}

Precomputing the random values once and storing them as properties means every hover produces the same shatter pattern instead of a new random one each time. That consistency is what makes it feel designed rather than glitchy.

Dissolve and Fold

Both keep the whole word intact and animate it as one block instead of splitting into letters, which is a deliberate contrast to shatter:

.stage[data-anim="dissolve"]:hover .demo {
  filter: blur(10px);
  opacity: 0;
  transform: scale(1.15);
}
.stage[data-anim="fold"]:hover .demo {
  transform: rotateX(70deg) scaleY(0.15);
  opacity: 0.2;
}

Fold needs perspective on its parent stage for the same reason flip-in does, without it, rotateX just flattens the text vertically instead of appearing to tip away from the viewer.

Terminal Cycle

This loops through typing and deleting several strings, character by character, in an endless cycle that never needs a hover trigger:

function typeWord(word, cb) {
  let i = 0;
  const t = setInterval(() => {
    el.textContent = word.slice(0, i + 1);
    i++;
    if (i > word.length) {
      clearInterval(t);
      cb();
    }
  }, 60);
}
function deleteWord(cb) {
  let text = el.textContent;
  const t = setInterval(() => {
    text = text.slice(0, -1);
    el.textContent = text;
    if (text.length === 0) {
      clearInterval(t);
      cb();
    }
  }, 35);
}

Deleting runs almost twice as fast as typing, 35ms per character against 60ms. That asymmetry is what makes it read as a terminal instead of just the typewriter effect in reverse.

Experimental: the ones that don’t fit a category because they’re doing something structurally different

Variable Weight Breathing

This animates a font’s weight axis on a loop instead of on cursor proximity:

@keyframes wghtBreathe {
  0%,
  100% {
    font-variation-settings: "wght" 300, "opsz" 20;
  }
  50% {
    font-variation-settings: "wght" 900, "opsz" 100;
  }
}

Note the opsz (optical size) axis moving alongside weight. Fonts with a real optical size axis subtly reshape their letterforms at large sizes, not just thicken them, so animating both together looks like the letters are actually being redrawn rather than just gaining a bold filter.

Matrix Formation

This is the one specimen built on canvas instead of DOM spans, because it needs to render a whole field of falling, changing characters behind a target word:

for (let c = 0; c < cols; c++) {
  const target = locked[c];
  if (target && drops[c] >= target.row) {
    ctx.fillStyle = "#C7A03D";
    ctx.fillText(target.char, x, target.row * fontSize);
  } else {
    const ch = CHARS[randInt(0, CHARS.length - 1)];
    ctx.fillText(ch, x, drops[c] * fontSize);
    drops[c]++;
  }
}

Only certain columns get a locked target letter assigned; the rest just rain random characters forever. The word "forms" because those specific columns stop scrambling once their falling counter reaches the target row, while every other column keeps going. It's the only animation in the set where DOM manipulation would have been the wrong tool entirely, drawing and erasing dozens of characters sixty times a second is exactly what canvas is for.

Word Morph

This cross-fades between two full words stacked in the same position:

.morph-wrap .demo.b {
  position: absolute;
  left: 0;
  top: 0;
  opacity: 0;
  filter: blur(6px);
}
.morph-wrap.swap .demo.a {
  opacity: 0;
  filter: blur(6px);
}
.morph-wrap.swap .demo.b {
  opacity: 1;
  filter: blur(0);
}

Both words occupy the same coordinates via position: absolute, so the swap reads as one word transforming into another rather than two separate words taking turns.

Chromatic Scroll

This ties a red/cyan channel split to how far a section sits from the vertical center of the viewport:

const offset = Math.max(-1, Math.min(1, (stageCenter - center) / (vh / 2)));
const mag = Math.abs(offset) * 8;
el.style.textShadow = `${offset * mag}px 0 rgba(255,59,107,.7), ${
  -offset * mag
}px 0 rgba(59,214,255,.7)`;

The two shadow offsets are exact negatives of each other, which is what keeps the split symmetric around the true letterforms instead of just shifting the whole word sideways.

Gravity Drop

This reuses the same staggered-span helper from the reveal group, but with a keyframe animation that overshoots before settling:

@keyframes gravityDrop {
  0% {
    opacity: 0;
    transform: translateY(-160px);
  }
  60% {
    opacity: 1;
    transform: translateY(8px);
  }
  80% {
    transform: translateY(-4px);
  }
  100% {
    opacity: 1;
    transform: translateY(0);
  }
}

The overshoot at 60% and the small bounce back at 80% are what sell the idea of weight. A letter that falls and stops dead at 0 looks like it faded in from above. A letter that falls past zero and settles back looks like it actually landed.

What twenty-nine examples taught me about three or four techniques

Strip away the surface variety, and this whole set really only rests on a handful of underlying mechanisms: splitting text into per-character spans and staggering a CSS transition across them, clipping a gradient to text for anything involving color movement, reading and writing custom properties as the bridge between JavaScript’s math and CSS’s rendering, and canvas for the one case where you’re not really animating text at all but drawing it fresh every frame.

The variety comes from combining those four ideas differently, not from needing thirty different technical approaches. Scramble and split-flap both interval-scramble characters; the only real difference is that split-flap staggers its per-letter timing and scramble doesn’t. Wave and liquid wobble both loop a transform on the same span-index delay; one moves the letter, the other skews it. Once you see the shared mechanism underneath, twenty-nine animations stop looking like twenty-nine things to learn and start looking like four things to combine.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

Stop building marketing sites with React, Next.js, and Angular (you're overengineering them)

Muhammad Usman — Fri, 03 Jul 2026 10:41:35 +0000

A client asks for a website. You open VS Code, run create-next-app, wire up a component library, connect a CMS, and three weeks later ship a beautifully engineered site that loads 400KB of JS to render a hero section and a contact form.

The client's happy for about a month. Then they ask why their bounce rate is 70% and their Lighthouse score sits in the 40s. You didn't do anything wrong technically. You just answered a question nobody asked.

This happens constantly with marketing and business websites, the kind whose only job is to get someone to book a call, sign up, or buy something. Not dashboards. Not products with user accounts, permissions, real-time state. Static pages selling a service.

The default stack isn't always the right stack

React, Next.js, and Angular solve real problems: client-side state management, complex interactivity, reusable components across a large app. A marketing site has none of those problems. It has five to ten pages, a form, maybe a blog, and one job: turn a visitor into a lead.

Reach for a SPA framework by default and you inherit a hydration step, a JS runtime, a build pipeline, a bundle size, all to serve content that's mostly static text and images. Every one of those adds milliseconds to Time to Interactive. Google's own research shows bounce probability climbing sharply once load time passes 3 seconds.

This isn't a knock on the frameworks. It's a mismatch between the tool and the job.

What a marketing site actually needs

Ask what the page has to do before deciding how to build it:

Load fast on a mid-range phone over a mediocre connection
Rank in search, which means clean HTML and fast Core Web Vitals
Let a marketer edit copy without opening a pull request
Push a visitor toward one action per page, not compete with a dozen widgets

For that job, plain HTML/CSS/JS, WordPress, Webflow, or a static-first tool like Astro will usually beat a client-rendered framework on the metrics that matter to the business: load time, SEO, and how easily a non-technical person can update it after launch.

Astro is worth calling out on its own. It ships zero JS by default and only hydrates the components that actually need interactivity. You get component-based development without paying the client-side framework tax.

When React, Next.js, and Angular are the right call

This isn't "never use a framework." It's "match the tool to the job":

The site needs a logged-in dashboard, account area, complex state
There's heavy client-side interactivity: filtering, real-time updates, drag-and-drop
You're building a product, not a marketing page for one
The team already has a design system built around the framework, and switching costs more than it saves

If any of that's true, use the framework. Next.js with static generation still performs well for content-heavy sites too. The point isn't "React bad." It's "pick based on the job, not the resume line."

The part developers usually skip

Here's what actually determines whether the site works: define what it needs to do before touching the stack.

What's the one action you want a visitor to take?
How long should the page be to build trust without losing them?
Where does the CTA go, and how many times does it repeat?
What's the path from "never heard of this business" to "booked a call"?

These aren't marketing fluff questions. They're requirements for the build, the same way "does this need real-time sync" is a requirement for a chat app. Skip them and you'll ship something structurally sound that generates zero leads, because nobody built it against an objective in the first place.

A fast, well-coded site that doesn't route people toward a decision is an expensive digital brochure. The stack only matters once you know what the page is trying to do.

The short version

Before you scaffold anything, ask what the site needs to accomplish, not what you're comfortable building. Most marketing sites need speed, clean markup, easy editing: HTML/CSS/JS, WordPress, Webflow, or Astro. Save React, Next.js, and Angular for sites that need what they're actually good at: complex state, heavy interactivity, logged-in experiences.

Your job isn't proving you can build a SPA. It's shipping something that gets the business what it's paying for.

One more thing: hosting matters too

All of this falls apart on slow hosting. A lean stack on a bad server still ships a bad Time to First Byte, and that's a metric no framework choice fixes after the fact.

For client marketing sites I usually reach for Hostinger (referral link, I get credit if you sign up). It's fast without any server tuning and handles WordPress or a static Astro build the same way. That link also knocks an extra 20% off.