DEV Community: Muhammad Usman

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.

Everything a Junior Developer Needs to Know About Hosting Before Their First Client Project

Muhammad Usman — Mon, 29 Jun 2026 07:24:31 +0000

Your first client project goes well. You build the site, they love it, and then they ask: "So how do we get this thing online?"

And you realize you have no answer ready.

Hosting doesn't come up much when you're learning to code. Tutorials assume you already know what it is, or they skip it entirely and deploy to Vercel with one click. But your client's local bakery isn't going on Vercel. They want an email that says @theirbakery.com and a URL they can put on a business card.

Here's what you actually need to know before that conversation happens.

The three things every client site needs

Get clear on the difference between a domain, hosting, and SSL. Junior devs often mix these up, and clients always will.

A domain is the address: theirbakery.com. You register it through a domain registrar (Namecheap, Porkbun, or through your hosting provider). A .com costs roughly $10–15/year.

Hosting is where the website files live. When someone types the domain into a browser, their computer connects to the hosting server and loads the files. Shared hosting (where the client's site sits on a server alongside hundreds of other sites) costs $2–10/month and handles almost every small business site fine.

SSL is the padlock in the browser bar. It means the connection is encrypted. You need it. Google flags sites without it. Most hosting providers include it free via Let's Encrypt, so this is usually a checkbox during setup, not a separate purchase.

Those three things are the floor. Everything else is optional until the client asks for it.

Who should own the hosting account

This is where junior developers most often make a mistake. The answer is: the client.

If the hosting account is in your name and the relationship ends badly, you're holding their website hostage. If they want to hire someone else later, they're stuck waiting on you. If you get hit by a bus, they lose access to their own site.

Set the account up in the client's name using their email address and their payment method. You can be added as a collaborator or get the login credentials to manage it, but the account is theirs.

Same rule for the domain. Register it in their name. Disputes over domain ownership are slow, expensive, and completely avoidable.

Shared hosting is fine for most small clients

A lot of junior devs assume clients need something powerful: a VPS, a cloud server, something that sounds serious. For a brochure site or a WordPress blog getting a few hundred visitors a day, they don't.

Shared hosting means the client's site runs on a server shared with other sites, splitting the resources. For low-traffic sites this is almost indistinguishable from dedicated resources in practice. It's cheap because the cost is shared, not because it's bad.

For most early client projects, the Hostinger Premium or Business plan covers everything you need. The Premium plan is around $2.99/month and lets you host up to 100 websites, which matters once you have a few clients, because you're not paying for a separate account per project. One plan, multiple sites, free domain in the first year, SSL included.

When does shared hosting stop being enough? When a site gets consistent traffic in the tens of thousands of monthly visitors, runs resource-heavy custom code, or processes a lot of simultaneous transactions. A WooCommerce store doing serious volume needs a VPS or a managed host. A florist's five-page website does not.

What cPanel actually is

Most shared hosting accounts come with cPanel, a browser-based dashboard for managing the hosting. It's where you'll spend most of your time.

From cPanel you can create email accounts, install WordPress in about 90 seconds, manage files through a built-in file manager, create MySQL databases, configure DNS records, set up subdomains, and check error logs.

You don't need to memorize it before you start. The layout is consistent enough across providers that you'll figure it out as you go. The main thing is knowing it exists: it's your primary interface for managing a client site, not the command line, at least not for typical small projects.

Some hosts use a custom dashboard instead of cPanel. Hostinger uses one called hPanel. Same concept, different layout.

Clients always want email

If you don't ask about email before you build the site, your client will ask about it after launch.

They want hello@theirbusiness.com, not hello@gmail.com. Most hosting plans include email hosting. You create the accounts in cPanel and hand over the credentials. The client then connects that address to whatever app they use (Gmail, Outlook, Apple Mail) using IMAP settings the host provides.

Walk them through the setup, or write them a short guide. "How do I check my business email in Gmail" is the most common post-launch question you'll get, almost without exception.

One thing worth knowing: email on shared hosting is basic. It works fine for a small business that needs a contact address and maybe two or three accounts. If a client sends mass newsletters or runs a sales team with real email volume, they need a dedicated service like Google Workspace ($6/user/month) instead. Know which situation you're in before launch.

Backups: have this conversation before something breaks

Most hosting providers run automated backups, but the frequency varies. Hostinger does weekly backups on the basic plans and daily backups on higher-tier ones. If the site gets hacked on a Wednesday and your backup schedule is weekly, you might be restoring a version that's six days old.

Tell the client this. Ask if they want a more aggressive setup. A WordPress plugin like UpdraftPlus can run its own backups to Google Drive regardless of what the host does. It's worth installing on every WordPress project, full stop.

The time not to be explaining backup schedules is while you're trying to recover a broken site at 11pm.

A checklist for your first handoff

Before you hand anything over:

Hosting account in the client's name with their payment info
Domain registered in the client's name
SSL active (confirm the padlock appears in the browser)
Email accounts set up, client can log in
Client has their cPanel or hPanel credentials
Backups are running
You've agreed in writing on whether you're doing ongoing maintenance or they're on their own

That last one matters. If they expect free updates and you expect to be done at launch, someone is going to be annoyed in three months. Make it explicit before the project ends, not after.

Hosting feels complicated before you've dealt with it. By your third client site it's close to routine. The first one takes longer because you're learning where the buttons are. That's normal.

The part that trips people up isn't technical. It's the account ownership conversation and the email conversation. Have both of them early, and most of the rest is just clicking through a setup wizard.

If you're ready to get your first client site online, Hostinger is where I'd start — 20% off with that link, free domain in the first year, and everything covered in this article works out of the box.

The Real Reason Developers Give Up Side Projects (It Is Not Motivation)

Muhammad Usman — Tue, 23 Jun 2026 07:18:49 +0000

Open your GitHub right now. Go to your repositories and count the unfinished ones. Three? Seven? More than you are comfortable admitting?

I will wait.

The first week of a side project feels like nothing else. You are thinking about it in the shower. You are sketching out features at midnight. You are telling yourself that this one is different, that this is the project you are actually going to ship. The commits come fast. The energy is real. Everything feels possible.

Then something shifts. The commits slow down. A week passes, then two. You open the folder one evening, stare at the code for a few minutes, then close it and watch something on YouTube instead. One day you realize the last commit was six weeks ago and you are not even sure you remember what the project was supposed to do.

Everyone says this is a motivation problem. You ran out of steam. Life got busy. You lost interest. The idea stopped exciting you.

But what if motivation was never the real issue at all?

The Story Developers Tell Themselves

When a side project dies, there is a standard list of explanations developers reach for.

Work got hectic. A new framework came out and the old project felt irrelevant. A better idea came along. You just needed a short break and somehow never came back. These explanations feel completely true when you say them. And they are not entirely wrong. But they are surface-level answers. They describe what happened on the outside. They do not explain what was already broken on the inside.

The real problem existed from day one, before work got busy, before the new idea arrived, before motivation became an issue. It was planted the moment you started the project. And because it is invisible at first, most developers never see it until it is too late.

The Actual Reason

Here is the honest answer: developers abandon side projects because they never defined what finishing looks like.

They know what they want to build. They have a clear picture of the features, the design, the feeling the project should give users. But they never write down what the first finished version actually is. There is no definition of done. And a project without a definition of done is not a project. It is an infinite loop.

Think about what this looks like in practice. You build the core feature. It works. Then you notice the UI looks rough, so you spend a weekend redesigning it. The redesign looks better, but now the code underneath feels messy, so you refactor. While refactoring, you think of a feature that would make the whole thing more useful, so you start building that. Each step feels like progress. Each step technically is progress. But none of it gets you closer to finishing, because you never defined where the finish line is.

The project does not die from a lack of motivation. It dies from a lack of closure. Every time you open that folder, the gap between where the project is and where you imagined it would be feels a little larger. That growing gap is what wears you down. Not a lack of caring. The caring is still there. That is actually what makes it hurt.

I have lived this more than once. My personality assessment project sat unfinished for weeks because I kept expanding what "finished" meant. First it was just the quiz logic. Then it needed better UI. Then it needed shareable results. Then it needed a loading animation because the basic one looked lazy. I was always building, but I was never done. The finish line kept moving because I had never drawn it in the first place.

Why Perfectionism Disguises Itself as Productivity

Here is the part that makes this problem so hard to catch in the moment.

Developers are trained to care about quality. Clean code. Proper architecture. Good performance. These are genuine professional values and they are worth having. But inside a side project with no external deadline, those same values quietly become a trap.

Every refactor feels responsible. Every redesign feels like you are raising the bar. Every "let me just clean this up before I move on" feels like diligence. But none of it is actually moving you toward shipping. It is moving you toward a version of the project that feels safe enough to show people.

And that is the uncomfortable part. An unfinished project cannot be judged. It cannot fail publicly. It cannot disappoint anyone, including yourself. As long as it is in progress, it still holds all the potential you imagined on day one. Shipping it means finding out if the real version lives up to the version in your head.

So the refactors keep coming. The redesigns keep happening. The project keeps getting better and closer to perfect. And it never ships.

Perfectionism is almost never how it feels from the inside. From the inside, it feels like standards. Naming it honestly is the first step toward breaking the pattern.

The Comparison That Probably Stings a Little

Think about how you work at your actual job. A feature is due on Friday. The code is not quite how you would write it if you had unlimited time. The UI has a few rough edges. But it is Friday, so you ship it. You write a note about what to improve later and you move on.

That thing ships. It works. Users use it. Nobody knows about the rough edges except you.

Now compare that to your side project. No deadline. No manager waiting. No team depending on you. So every rough edge becomes a blocker. Every imperfection gets fixed before moving forward. The project has all the time in the world, so you give it all the time in the world. And somehow it never gets done.

The difference between work projects and side projects is not code quality. It is the presence of external pressure. At work, that pressure forces you to make the hardest decision in software: deciding that something is good enough to exist in the world right now.

Side projects never force you to make that decision. So most developers never make it.

What to Actually Do About It

This is not a list of productivity hacks. These are three specific changes that address the actual problem.

Define done before you write a single line of code. Sit down and write one paragraph. Not a vision statement. Not a list of features. One paragraph that describes what the first version looks like when a real person can use it. What does it do? What does it not do? Where does it start and where does it stop? That paragraph becomes your filter for every decision after it. If a new feature idea does not fit inside that paragraph, it does not go into version one. It goes on a list for later.

This one step would have saved most of my abandoned projects. Not because the paragraph is magic, but because it forces you to make a decision you usually avoid making.

Build in public from the start, even when the project is half-broken. Post about what you are building. Share the messy version. Write about the problem you are trying to solve before you have solved it. What happens when you do this is that people start responding. They ask questions. They say they have the same problem. They tell you what feature they would actually use. That external pull creates accountability that motivation alone cannot manufacture. The project stops being just yours and starts having people waiting for it.

Writing on dev.to while building is the most effective version of this I have found personally. It creates a rhythm. Readers become an audience and an audience creates a reason to keep going.

Ship before you are ready. Set a date. Not a goal, not a target, a real date. Write it down. When that date arrives, ship whatever exists. A rough project that is live is infinitely more valuable than a perfect project that no one ever sees. The feedback you get from one real user in one day of being live will teach you more than six months of building in private.

The version you ship does not have to be impressive. It has to exist.

The Harder Truth

Some side projects are not meant to be finished. Some of them exist to teach you a new framework, explore an idea you were curious about, or scratch a creative itch that needed scratching. That is completely valid. There is nothing wrong with a project that teaches you something and then gets set aside.

The mistake is calling it a side project when it is actually a learning experiment. If you named it that from the start, you would not feel like a failure when you moved on. You finished it. The goal was to learn, and you learned.

The problem only shows up when you genuinely want to ship something and you are not being honest with yourself about why it is not moving. Blame the motivation. Blame the workload. Blame the new idea that came along. The real answer is usually simpler and less comfortable: you never drew the finish line.

The Only Thing Worth Doing After Reading This

If you have an unfinished project sitting in your repos right now, do not go looking for a new productivity system. Do not rewatch that video about staying consistent. Do not reorganize your Notion board.

Open the project folder. Open a blank document next to it. Write one sentence that answers this question: what does this project do when it is done, in its simplest form?

Build only toward that.

The project does not need to be impressive. It does not need to be polished. It does not need to be ready for a Product Hunt launch. It needs to exist somewhere that is not just your local machine.

How many unfinished projects are sitting in your repos right now? And if you think back honestly, do you know what actually stopped you? Drop your number in the comments. I have a feeling the answers are going to look familiar.

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.

Why You Should Learn Programming Through Books (Not Just Online Tutorials)

Muhammad Usman — Tue, 19 May 2026 11:56:45 +0000

Books don’t just teach you to code — they teach you to think like a programmer.

The man who does not read has no advantage over the man who cannot read.

Learning programming using an online tutorial is like taking a picture.

You click, and that’s that. Learning to program with books, though — that’s like creating a painting. You layer and layer on it, and you keep working for weeks. You might still have the same image in the end, but there’s a depth to it that’s impossible to capture with a snapshot.

I know we live in a world where everyone wants fast results. Watching online tutorials might seem like the easiest way to learn programming. But the quality of outcome you get with books cannot be matched.

You can go much deeper with books than you can using any other method.

And here’s something people don’t talk about enough: when you start working, there won’t be any video tutorials to help you. You’ll have to read documentation and implement things by yourself.

Building a habit of reading and understanding technical material is a must if you want a solid career as a programmer.

That’s why I’m giving you 5 practical books to get started with.

Let’s do this.

1. Python Crash Course — Learn by Building Cool Projects

If you want to learn Python by building cool projects, check out this book called “Python Crash Course.” The first half of the book deals with the basics like variables, conditionals, loops, and functions. But the real magic happens in the second part of the book, where you actually build projects.

You’ll use the pygame package to build an Alien Invasion game. How does that sound as your first ever project? You’ll be able to shoot down the alien fleet and even have a scoreboard to list high scores.

In the second project, you’ll learn how to work with APIs. You’ll download data from the GitHub API and visualize it using Matplotlib. And in the final project, you’ll build a web app using Django, a very popular Python web framework. You’ll also learn how to style your app using bootstrap, a widely-used CSS framework. At the end, you’ll even deploy your website to the cloud, so the entire world can see it.

After completing this book, you’ll feel confident enough to start building your own Python projects.

2. Eloquent JavaScript — For Web Development Enthusiasts

Next, I have a great recommendation for web development enthusiasts. If you want a deep understanding of JavaScript, try out the book “Eloquent JavaScript.”

This book is available online completely for free. And the best part? You can try out all the exercises right on their website.

In the first part of the book, you learn the basics — things like variables, functions, and objects. In the second part, you dive into how JavaScript interacts with the browser and the Document Object Model, or DOM. Finally, in the last part, you’ll learn about Node.js, which allows you to run JavaScript on the server instead of just in the browser.

Every chapter gives you exercises to test your knowledge. You’ll also build some really cool projects. You’ll create a brand-new programming language called Egg. You’ll make a web app for editing pixel art. And in the final project, you’ll build a website that helps people organize meetings to share their skills.

3. The Pragmatic Programmer — Timeless Principles

Next, we have a timeless classic: “The Pragmatic Programmer.”

The principles in this book aren’t tied to specific technologies or programming languages. That makes them applicable even years after the book was first published in 1999.

This book covers topics like debugging, testing, automation, and communication, giving you a well-rounded perspective on what it takes to be an effective software developer. It focuses on fundamental principles and best practices you can apply in any programming context.

One of the best parts about this book is how it uses clever metaphors and analogies to explain complex technical concepts. For example, it introduces the idea of “Code Kata.” In Japanese, the word Kata means “form” and is used to describe deliberate practice and repetition in martial arts. By doing Code Kata exercises, programmers can reinforce their knowledge of algorithms, data structures, and design patterns.

Whether you’re a beginner or an experienced developer, this book has something for everyone. It’s a must-read for anyone serious about honing their craft.

4. Clean Code — Writing Maintainable Software

So, you’ve learned a couple of programming languages and you’ve become a pragmatic programmer. Now, you need to know how to write clean, maintainable code. For that, we have another classic: “Clean Code” by Uncle Bob.

The primary goal of this book is to improve the readability and maintainability of your code.

It teaches you to write code that’s easy for other developers to understand, modify, and extend.

You’ll learn when — and when not — to use comments. The book encourages you to write self-explanatory code instead of relying on tons of comments. It also covers how to properly name your variables, functions, and classes.

The book uses real-world examples to drive the points home. Uncle Bob writes most code snippets in Java, but the concepts easily apply to other languages. It also introduces software design principles like the Single Responsibility Principle (SRP) and Don’t Repeat Yourself (DRY).

The book can get a bit too opinionated at times. So you don’t have to follow everything to a tee.

But it’s still a fantastic starting point to improve the quality of your code.

5. Designing Data-Intensive Applications (DDIA) — Think Like a Systems Architect

If you want to go from a junior developer to a senior developer, you have to start thinking beyond just code. You need to know how to architect your systems in a way that they can reliably handle thousands of simultaneous requests.

For that, you should read “Designing Data-Intensive Applications” (often called DDIA).

This book introduces you to the challenges of building systems that are reliable, scalable, and maintainable. You’ll learn when to use relational databases vs. NoSQL databases. DDIA also helps you understand how databases efficiently store and retrieve data.

It teaches you how to distribute data across multiple machines when your dataset becomes too large for a single server. And while it covers a lot of theory, it also provides practical advice you can use in the real world. You’ll read examples from big tech companies like Google and Amazon.

The book ends with a look at emerging trends in data systems, like new databases and storage technologies.

If you want to learn how to make smart trade-offs while building large-scale applications, DDIA is a must-read.

Final Thoughts

If you want to build a deeper understanding of programming concepts, books are the best way to do it.

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.

The $0 to $50/Month Tech Stack to Launch Your First SaaS

Muhammad Usman — Wed, 13 May 2026 10:20:19 +0000

Most people never ship their SaaS idea.

Not because the idea is bad. Not because they lack skills. Because they spend three weeks researching the "perfect" stack, get overwhelmed by AWS pricing pages, and quietly close the tab.

This article is not that. This is the exact stack I would use today if I were starting from zero, a developer with an idea and an empty wallet, trying to get something in front of real users as fast as possible. Every tool listed here either has a free tier or costs a few dollars a month. The whole thing stays under $50/month even after you start getting traction.

No enterprise nonsense. No over-engineering. Just tools that let you build, ship, and grow.

The philosophy first

Before the tools: the biggest mistake first-time SaaS builders make is paying for infrastructure before they have a single paying customer.

Your job in month one is not to build something scalable. Your job is to find out if anyone will pay for this thing. That means keeping costs at zero for as long as humanly possible, then introducing paid tiers only when free options genuinely become a bottleneck.

Every tool below follows that rule.

The full stack at a glance

Layer	Tool	Cost
Frontend	Next.js	Free
Backend / API	Next.js API routes or FastAPI	Free
Database	Supabase	Free (up to 500MB)
Auth	Supabase Auth	Free
Hosting	Hostinger Node.js Hosting	$3.99/mo
Domain	Hostinger	~$10/yr
Payments	Stripe	Free (2.9% + 30c per transaction)
Email	Resend	Free (up to 3,000 emails/mo)
Analytics	Plausible or Umami (self-hosted)	Free
Error tracking	Sentry	Free (up to 5,000 errors/mo)

Total at launch: $3.99/month + domain.

Layer 1: Frontend + Backend with Next.js

Next.js is the right call for a solo founder or small team building a SaaS in 2026. It handles your frontend, your API routes, and your server-side rendering in one framework. You are not maintaining a separate Express server. You are not juggling two repos. One codebase, one deployment.

Use the App Router. Use Server Components for anything that does not need interactivity. This keeps your JavaScript bundle small and your pages fast, which matters for SEO and for users on slower connections.

If your SaaS is primarily an AI tool or data-heavy backend, swap Next.js API routes for FastAPI. Python's ecosystem for AI, data processing, and async tasks is unmatched, and FastAPI is genuinely fast to build with. You can still use Next.js for your frontend and point it at a FastAPI backend.

What to build first: The signup page, the core feature (one, not five), and a simple dashboard. That is it. Resist building anything else.

Layer 2: Database and Auth with Supabase

Supabase gives you a Postgres database, authentication, real-time subscriptions, and file storage, all on a generous free tier. For a new SaaS, this is an absurd amount of infrastructure for zero dollars.

The free tier covers you up to 500MB of database storage and 50,000 monthly active users on auth. You will not hit those limits before you are making real money.

A few things worth knowing:

Use Row Level Security (RLS) from day one. It keeps your data access logic in the database, not scattered across your API.
Supabase Auth handles OAuth (Google, GitHub) out of the box. No Passport.js setup, no JWT headaches.
The Supabase JavaScript client works seamlessly inside Next.js Server Components.

When you outgrow the free tier, the Pro plan is $25/month and gives you 8GB of storage and daily backups. At that point, you should have paying customers covering it.

Layer 3: Hosting with Hostinger

This is the one paid tool in the stack from day one, and it is worth it.

The reason you do not want to rely on free hosting tiers for your main app: they sleep. Render's free tier spins down your server after 15 minutes of inactivity. Fly.io's free machines get paused. Your demo fails in front of the one person who might have become your first customer.

Hostinger's Node.js hosting runs your Next.js or Node.js app on a live server that stays on, at $3.99/month. You can also grab your domain there and connect it in a few clicks. Deployment is straightforward: connect your GitHub repo, push code, and it deploys automatically.

If you are running a FastAPI backend, Hostinger's VPS plans start at the same price range and give you root access to install anything you need: Python, Gunicorn, Nginx, whatever your stack requires.

I use Hostinger for several projects. It is not trying to be AWS. It is trying to be the easiest, cheapest way to keep a Node.js or PHP app live. For a solo founder launching a first SaaS, that is exactly what you want. Get 20% extra discount here.

Layer 4: Payments with Stripe

Stripe is the standard. Do not use anything else until you have a reason to.

The free tier means you pay nothing until you process a transaction. Then it is 2.9% plus 30 cents per charge. On a $29/month subscription, that is about $1.14 per transaction. Reasonable.

What most people do not realise: Stripe Checkout handles your entire payment UI. You do not need to build a checkout page. You redirect users to a Stripe-hosted page, and Stripe handles card collection, 3D Secure, tax calculation, and PCI compliance. Wire it to a webhook, update the user's subscription status in Supabase, done.

For subscriptions specifically, use Stripe Billing. It handles trial periods, proration on plan changes, dunning (automatic retries on failed payments), and cancellations. Things that would take weeks to build yourself.

Layer 5: Email with Resend

Transactional email (welcome emails, password resets, upgrade receipts) is non-negotiable for a SaaS. Resend gives you 3,000 emails per month for free with a proper API that works beautifully from Next.js.

The developer experience is significantly cleaner than SendGrid or Mailgun. You write your emails as React components using the react-email library, which means type safety, reusable components, and no more wrestling with HTML tables.

import { Html, Button, Text } from '@react-email/components';

export function WelcomeEmail({ name }: { name: string }) {
  return (
    <Html>
      <Text>Hey {name}, welcome aboard.</Text>
      <Button href="https://yourapp.com/dashboard">
        Go to your dashboard
      </Button>
    </Html>
  );
}

When you hit the free limit, Resend's paid tier starts at $20/month for 50,000 emails. By that point, you will have the revenue to cover it.

Layer 6: Analytics and Error Tracking

Analytics: Do not use Google Analytics. It is bloated, it shares your users' data with Google, and it will scare privacy-conscious users in 2026. Use Plausible (lightweight, privacy-first, $9/month) or self-host Umami on your existing Hostinger VPS for free. Umami is a single Node.js app. Add it as a second service alongside your main app.

Error tracking: Sentry's free tier captures 5,000 errors per month and shows you the exact stack trace, user session, and browser when something breaks in production. Integrate it in one line:

// app/layout.tsx
import * as Sentry from "@sentry/nextjs";
Sentry.init({ dsn: process.env.NEXT_PUBLIC_SENTRY_DSN });

You will find bugs you never would have found otherwise.

What the cost curve actually looks like

Month 1 (building, no users): $3.99/month. Domain is a one-time $10/year cost.

Month 2 to 3 (early users, free tier everywhere): Still $3.99/month. Supabase, Stripe, Resend, and Sentry are all free at small scale.

Month 4 to 6 (getting traction, 100+ users): You might upgrade Supabase to Pro ($25/month) and add Plausible ($9/month) for better analytics. Stack is now around $38/month.

Month 6+ (revenue coming in): Your hosting might need an upgrade depending on traffic. Hostinger's plans scale without requiring a migration to a different platform. Total stack stays under $50/month well into the thousands-of-users range.

The point is: the costs scale with your success. You are not paying $200/month in infrastructure before you have a single dollar of revenue.

The one trap to avoid

The trap is adding complexity before you have users.

You do not need a separate Redis instance on day one. You do not need a message queue. You do not need microservices, Kubernetes, or a CDN with edge functions until your traffic makes those things genuinely necessary.

Every layer of infrastructure you add is a layer you have to debug at 11pm when something breaks and your only user is waiting for a response.

Start with this stack. Get to ten paying customers. Then look at what is actually breaking and fix only that.

Quick start checklist

[ ] Create Next.js app with npx create-next-app@latest
[ ] Set up Supabase project, enable RLS on all tables
[ ] Configure Supabase Auth with Google OAuth
[ ] Get a domain and Node.js hosting on Hostinger
[ ] Connect GitHub repo for automatic deploys
[ ] Create Stripe account, set up one Product and one Price
[ ] Add Stripe webhook to update Supabase on subscription events
[ ] Set up Resend, write welcome email with react-email
[ ] Add Sentry to catch production errors
[ ] Self-host Umami on the same VPS for analytics

That is your entire infrastructure. Everything else is product.

Final thought

The SaaS graveyard is full of products that were never shipped, not products that shipped on the wrong stack.

Pick these tools. Build the thing. Ship it to five people this week.

The stack can always be changed later. The feedback you get from real users this week cannot be replicated by anything else.

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.
Get 20% extra discount on Hostinger

Stop Writing Clean Code. Write Honest Code Instead.

Muhammad Usman — Sat, 09 May 2026 09:52:55 +0000

There is a codebase out there with a simple "send an email" operation that goes through seven layers of abstraction.

An EmailService that uses an EmailProvider that wraps an EmailClient that calls an EmailAdapter that uses a MessageSender that invokes a TransportLayer that finally, after all of that, calls the actual email API.

Every layer has a reason. Logging here. Error handling there. Retries somewhere in the middle. It is, by almost every definition the industry has agreed on, clean code.

It is also code that nobody on the team can fully understand anymore.

That is the problem nobody talks about when they are quoting Uncle Bob at you in a code review.

How Clean Code Stopped Being a Tool and Became a Standard

Robert Martin's book came out in 2008. It gave developers a vocabulary and a set of rules. Short functions. Meaningful names. Single responsibility. No comments because the code should speak for itself.

Good ideas. Genuinely. The problem is what happened next.

Developers turned a set of practical guidelines for a specific context into a universal standard for all code everywhere. Clean code stopped being a tool and became an identity. Writing clean code meant you were a serious developer. Writing anything else meant you were cutting corners, being lazy, not caring about your craft.

And once something becomes an identity, it stops being questioned.

So developers started abstracting things that did not need abstracting. Creating interfaces for classes that would never have a second implementation. Splitting functions into sub-functions into sub-sub-functions until the original logic was spread across twelve files and finding out what the code actually does requires a forty minute archaeology expedition.

All of it in the name of cleanliness. None of it in the name of actually solving the problem.

The Performance Conversation Nobody Wanted to Have

In 2023, a programmer named Casey Muratori published a video called "Clean Code, Horrible Performance." He took Uncle Bob's clean code examples and benchmarked them against straightforward implementations.

The clean versions were up to 23 times slower.

The reaction from the clean code community was, predictably, defensive. Performance does not matter for most applications. The bottleneck is usually the database anyway. You are optimizing prematurely.

Some of that is true. Most modern software spends the majority of its time waiting for user input, not executing business logic. For a lot of applications, the performance gap is irrelevant.

But that is not really the point Muratori was making. The point is that the clean code rules were presented as universally correct, context-free laws. And they are not. They are tradeoffs. Every abstraction you add is a layer someone has to understand. Every tiny function is a context switch in a reader's brain. Every interface is an indirection that obscures what is actually happening.

Clean code moves the complexity. It does not eliminate it.

What "Honest Code" Actually Means

Honest code is not messy code. It is not an excuse to write whatever you want and call it a style choice.

Honest code is code that does not pretend.

It does not pretend that the business logic is simpler than it is. A lot of codebases have genuinely complicated rules because the domain is genuinely complicated. Forcing that into short, clean functions sometimes means the complexity goes underground, hiding in the gaps between functions, in the sequence of calls, in the assumptions baked into naming.

It does not pretend that future requirements justify present architecture. One developer built a feature with a flexible configuration system, keyboard shortcuts, and multiple user pathways because he imagined power users doing complex workflows. Ninety percent of actual users just wanted to click one button. All the flexibility was just confusing them. The architecture was built for a future that never arrived.

It does not pretend that all code is equally important. Your authentication logic that handles money needs rock-solid testing and careful review. Your internal admin dashboard that three people use to generate reports can be rough around the edges. Treating every line of code with the same level of ceremony is not discipline. It is a misallocation of attention.

And honest code does not hide behind abstraction when a comment would do the job better and faster.

The Comment Rule Nobody Should Follow Blindly

Clean code says code should be self-documenting. Comments are a failure. If you need a comment to explain the code, the code is not clean enough.

This is one of the most damaging ideas in mainstream software development.

There is a category of code that is necessarily dense, complex, or counterintuitive, not because the developer wrote it badly, but because the problem it solves is genuinely hard. A performance-critical path that uses bitwise operations for speed. A workaround for a third-party library bug that will be removed when the library updates. A business rule that sounds insane but reflects a legal requirement that the developer spent two days understanding.

Clean code says: make the code clearer.

Honest code says: write the comment. Explain the why. Leave the breadcrumb for the next developer who will be just as confused as you were, because the confusion is correct. The thing is actually confusing.

The developer who wrote the confusing thing and left no comment was not being disciplined. They were being unkind.

The Biggest Technical Debt Nobody Tracks

Technical debt gets measured in two ways: things that broke and things that slowed down feature development.

Nobody tracks the hours spent by new developers trying to understand an abstraction layer that was added for cleanliness rather than necessity. Nobody counts the time spent tracing through seven layers of email infrastructure to find the one line that actually sends the email. Nobody measures the cognitive load of a codebase where everything is theoretically clean but nothing is immediately legible.

That cost is real. It accumulates quietly. And it is often worse in codebases that followed the clean code rules most faithfully, because the complexity did not go away. It just got distributed more evenly across more files with better names.

The biggest source of developer frustration, by a wide margin according to Stack Overflow's own data, is technical debt. Not messy code specifically. Debt. The gap between what the code is and what it needs to be.

Clean code pursued as an end in itself creates its own kind of debt. The debt of over-abstraction. The debt of architecture that outpaced the actual requirements. The debt of code that is legible line by line but incomprehensible as a system.

What to Do Instead

Write code that works first. Code that you understand. Code that you can debug at 2am when it breaks in production and you are tired and the pressure is real.

Then ask: who else needs to understand this? What do they need to know that the code cannot tell them? Write that down. In a comment, in a README, in a commit message. Somewhere.

Ask: what parts of this are likely to change? Abstract those. The parts that are stable, that have been stable for years, that nobody has asked to modify since they were written, leave them alone. Do not add an interface to something that will never have a second implementation just because a rule says to.

Ask: what does this code actually do? Not what it is supposed to do. What it actually does. If you cannot answer that in two sentences without referencing the three layers above and below it, that is not clean. That is hidden.

Honest code is code that tells the truth about what it does, where it is fragile, why it makes the choices it makes, and what it is not designed to handle.

Clean code wants to look good. Honest code wants to be understood.

Those are not always the same thing. And in the gap between them is where most debugging happens.

You have probably inherited a codebase at some point that was written by someone who cared deeply about cleanliness. Beautiful structure. Consistent naming. Short functions everywhere.

And you still could not figure out what it did.

That is not a coincidence. That is clean code working exactly as designed, optimizing for appearance at the expense of truth.

Write the comment. Name the tradeoff. Leave the breadcrumb.

The next developer will thank you. That developer is probably you, six months from now, tired, staring at something you wrote and wondering what you were thinking.

Give that person the honest version.

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.

What Developers Actually Feel About Their Jobs

Muhammad Usman — Thu, 07 May 2026 12:09:48 +0000

Three out of four developers are not happy at work right now.

Not burned out. Not quitting. Just not happy. Showing up. Doing the tickets. Closing the laptop. Doing it again tomorrow.

That number comes from Stack Overflow's 2025 Developer Survey, 49,000 developers across 177 countries. Only 24% said they were genuinely happy at work. The rest are somewhere on a scale between fine and actively hating it. One in three reportedly hate their job. Almost half are in what researchers call "survival mode."

Survival mode. In a profession that is supposed to be one of the most in-demand, well-paid, intellectually stimulating careers available.

So what is actually going on?

The Gap Between What We Told Ourselves and What It Actually Is

Most developers got into this because of the craft. The feeling of building something from nothing. The puzzle of it. The moment a thing you imagined actually works.

One developer described it plainly: when you get burned out, you start counting the minutes until 5pm. You go home and look for distractions. You stop caring whether the code is good. You just want it to be done.

That is not a person who hates programming. That is a person who loved it and slowly had it taken from them by something they cannot quite name.

The job sold itself one way. It turned out to be something else. And the gap between those two things is where a lot of developer unhappiness actually lives.

What Developers Say Actually Makes Them Happy

The survey data on this is worth sitting with for a moment because it is not what most companies are optimizing for.

The top driver of developer job satisfaction is not salary. It is not tech stack, perks, or remote work. It is autonomy and trust.

Developers want to be trusted to make decisions. They want to own their work. They want to not have someone looking over their shoulder second-guessing every architectural choice while simultaneously not understanding the codebase.

After that comes competitive pay. Then solving real world problems that actually matter.

Notice what is not on that list. The ping-pong table. The unlimited PTO that nobody actually takes. The AI tool the company rolled out company-wide without asking whether anyone wanted it. The reorg that moved everyone to a new team with a new manager for the third time in two years.

The things that would genuinely help developers are not complicated. They are also, for many organizations, apparently very difficult to provide.

The AI Problem Nobody Wants to Admit

There is a strange thing happening right now in developer culture around AI.

84% of developers are using or planning to use AI tools in their work. Adoption is going up every year. But here is the part that does not make it into the press releases: 46% of developers distrust AI tool outputs, compared to only 33% who trust them. Positive sentiment toward AI tools has dropped from over 70% to 60% in just one year.

Developers are using something they increasingly do not trust, because they feel like they have to.

Two thirds report that AI answers are almost right but not quite. 45% say they lose significant time debugging AI-generated code. The thing that was supposed to make their jobs easier is, for nearly half of them, creating a new category of frustrating work: cleaning up confident mistakes.

And there is a subtler cost underneath that. When you spend your day fixing something a tool generated rather than building something yourself, you lose the thing that makes the work feel meaningful. Problem-solving. Ownership. The satisfaction of understanding why something works.

One survey respondent put it simply: the most satisfying part of the job is solving problems. That has not changed. What has changed is how much of the day is actually spent doing that versus managing the output of tools that solved the wrong problem fast.

The Developer Nobody Is Building Tools For

Here is a segment of the developer population that the industry largely ignores: the one working completely alone.

The solo freelancer. The developer at a small company where they are the only technical person. The person building a side project for two years hoping someone notices. The junior engineer on a team where everyone else is too busy to explain things and asking questions starts to feel like a liability.

These developers are not unhappy because of bad management or the wrong tech stack. They are unhappy because the work is genuinely isolating in a way that has no structural fix. Nobody is going to address it in a quarterly planning session. There is no metric for it.

One developer spent years building an npm module, waiting for someone to find it meaningful, maybe even collaborate on it. The module sat there. The months passed. Even his colleagues could not understand what he had built. That specific kind of invisible effort, work that is technically real and personally significant but completely unwitnessed, is one of the most common and least-discussed experiences in the field.

Survival Mode Is Not a Phase. For Many, It Is the Default.

The phrase "survival mode" sounds temporary. Like a rough patch before things improve.

For a lot of developers, it is just Tuesday.

They are not dramatically unhappy. They are not about to quit. They are doing the standup, the sprint planning, the code review, the deployment. They are technically fine. But the version of themselves that used to get excited about a hard problem, that used to stay late not because of a deadline but because they genuinely wanted to see if it worked, that version quietly left at some point and nobody noticed.

One developer who lost his passion for code described it: without passion, work is just grinding. You go through the motions but do not enjoy the moment.

Going through the motions. That is survival mode. And it is invisible to everyone except the person doing it.

The Number That Should Bother More People

24% of developers are happy at work.

That is the high point. That is after job satisfaction improved from last year.

In any other industry, if three quarters of the workforce reported being unhappy, it would be a crisis. In tech, it is a data point in an annual survey that gets shared on LinkedIn for two days and then forgotten.

The developers who are satisfied are mostly the ones with autonomy, decent pay, and work that feels like it matters. Those things are not rare because they are hard to provide. They are rare because they are not what most organizations are actually measuring or optimizing for.

Retros capture what broke. Sprints capture what shipped. Stand-ups capture what is blocked. Nobody built a ritual for what you solved, or whether the person solving it still cares about their work.

That gap, between what organizations track and what developers actually need, is where most of the unhappiness lives.

You might be reading this and recognizing yourself somewhere in it. The survival mode. The AI frustration. The invisible work nobody witnesses. The counting of minutes.

If you are, you are not an outlier. You are three quarters of the profession.

That is worth knowing. Not because it fixes anything. But because the story you have been telling yourself, that everyone else is fine and something is wrong with you, is not true.

Most people are not fine. They are just quiet about it.

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.