DEV Community: Asmaa Almadhoun

Astro: The Lightweight Challenger to Next.js for Landing Pages

Asmaa Almadhoun — Thu, 29 Oct 2026 13:03:00 +0000

🤔 Imagine you're building a website with:

Same Header ✅
Same Navigation ✅
Same Footer ✅
Different page content ✅

Instead of copying the Header and Footer into every page, Astro lets you create a Layout.

Think of a Layout as a reusable page frame.

+------------------+
| Header / Navbar  |
+------------------+
|                  |
|  Page Content    |
|     (<slot />)   |
|                  |
+------------------+
| Footer           |
+------------------+

⚙️ How It Works

Step 1: Create a Layout

---
import Navbar from '../components/Navbar.astro';
import Footer from '../components/Footer.astro';

const { title } = Astro.props;
---

<html>
  <head>
    <Navbar title={title} />
  </head>

  <body>
    <h1>{title}</h1>

    <article>
      <slot />
    </article>

    <Footer />
  </body>
</html>

The magic is:

<slot />

Everything placed between the layout tags will be injected into that slot.

Step 2: Use the Layout

---
import BaseLayout from '../layouts/BaseLayout.astro';
---

<BaseLayout title="Home Page">
  <p>Hello from Home Page!</p>
</BaseLayout>

Astro automatically inserts the content inside the Layout's:

<slot />

🎯 Why Use Layouts?

Without Layouts

Page 1
 ├─ Header
 ├─ Footer

Page 2
 ├─ Header
 ├─ Footer

Page 3
 ├─ Header
 ├─ Footer

Lots of duplicated code 😫

With Layouts

BaseLayout
 ├─ Header
 ├─ Slot
 └─ Footer

Page 1 → Content A
Page 2 → Content B
Page 3 → Content C

Cleaner, reusable, and easier to maintain ✅

📝 Layouts with Markdown

Astro can also apply Layouts to:

.md
.mdx

Example:

---
layout: ../layouts/BaseLayout.astro
title: "My Article"
author: "Asmaa"
---

Your Markdown content is automatically injected into:

<slot />

This makes blogs and documentation sites very easy to build.

📖 Accessing Frontmatter

Markdown metadata (frontmatter) can be read inside the layout.

Markdown File

---
layout: ../layouts/BaseLayout.astro
title: "My First Astro Article"
author: "Asmaa"
date: "29 Oct 2026"
---

Layout File

---
const { frontmatter } = Astro.props;
---

<h1>{frontmatter.title}</h1>

<slot />

<p>Written by {frontmatter.author}</p>
<p>Date: {frontmatter.date}</p>

🧩 MDX Layouts

For MDX files, you can manually import a Layout and pass custom props.

---
import BaseLayout from '../../layouts/BaseLayout.astro';

function fancyJsHelper() {
  return "Welcome to Astro!";
}
---

<BaseLayout
  title={frontmatter.title}
  fancyJsHelper={fancyJsHelper}
>
  My MDX Content
</BaseLayout>

Inside the Layout:

---
const { title, fancyJsHelper } = Astro.props;
---

<h1>{title}</h1>

<slot />

<p>{fancyJsHelper()}</p>

This allows MDX pages to use JavaScript and custom logic.

⭐ Key Takeaway

Astro Layouts = Reusable Page Templates

They help you:

Reuse Header/Footer
Keep a consistent design
Reduce duplicated code
Build blogs and documentation easily
Inject page content using <slot />
Share common UI across the entire site

Simple Analogy

Think of a Layout as a house blueprint 🏠

Walls, doors, and roof = Layout
Furniture inside each room = Page Content

You build the structure once and reuse it everywhere.

Tiny CSS Detail Stopped Countdown Button from Shaking

Asmaa Almadhoun — Tue, 13 Oct 2026 13:01:00 +0000

While working on a session countdown, I noticed a small but annoying UI issue: the button slightly changed its width every time the counter updated.

With a senior developer’s eye, even the smallest movement becomes noticeable.

Why Does It Happen?

In most fonts, digits do not have the same width. For example, 1 is usually narrower than 8.

When the countdown changes:

Yes 4:50
Yes 4:49
Yes 4:48

the text width changes too. If the button does not have a fixed width, it grows and shrinks by a few pixels, creating a distracting shaking effect.

The Simple Fix: `tabular-nums`

The CSS property font-variant-numeric: tabular-nums gives every digit the same horizontal width.

With Tailwind CSS, we can enable it using one class:

<button className="tabular-nums">
  Yes {formattedTime}
</button>

Now, 1, 4, 8, and every other digit occupy the same amount of space. The countdown can change without affecting the button’s width.

Why Not Use a Fixed Width?

A fixed width may hide the issue, but it is not always flexible. It can break when the text changes, the interface is translated, or a different font size is used.

tabular-nums solves the actual problem while keeping the component responsive.

Where Is It Useful?

Use tabular-nums for any frequently changing numeric value:

Countdown timers
Digital clocks
Prices and financial values
Dashboard statistics
Live scores
Data tables
Progress indicators

It is a small CSS detail, but it makes the interface feel more stable and polished.

Notice the details. Read more. Code smart.

The Day I Stopped Writing Hover Colors Manually

Asmaa Almadhoun — Tue, 06 Oct 2026 13:10:00 +0000

Every frontend project starts the same way.

:root {
  --primary: #f59e0b;
  --primary-hover: #d97706;
}

At first, it looks harmless.

Then the requirements grow.

:root {
  --primary: #f59e0b;
  --primary-hover: #d97706;
  --primary-active: #b45309;
  --primary-border: #ea9a00;
  --primary-shadow: rgba(245, 158, 11, 0.2);
}

Somehow, one color became five.

And every time the design team changes the brand color, we repeat the same process:

Open the color picker
Make it darker for hover
Make it even darker for active
Adjust the shadow color
Hope everything still looks consistent

I never questioned this workflow.

Until I discovered OKLCH.

The Problem We Pretend Doesn't Exist

Imagine our primary color is:

--primary: #ffa000;

Now we need a hover color.

What do we do?

Usually something like:

--primary-hover: #f29000;

But how did we get that value?

Most of the time:

Trial and error
Design tool adjustments
Visual guessing

There is no real system.

We're manually creating color variations instead of describing how a color should change.

Then I Found This Weird Syntax

One day I came across this:

background: oklch(
  from var(--primary)
  calc(l - 0.05)
  c
  h
);

My first reaction:

Wait...

I can generate the hover color from the original color?

No extra color variable?

What OKLCH Changed for Me

Instead of storing multiple versions of the same color:

--primary
--primary-hover
--primary-active

I only keep the source color:

--primary: oklch(0.75 0.18 70);

Then create variations on demand.

Hover:

background: oklch(
  from var(--primary)
  calc(l - 0.05)
  c
  h
);

Active:

background: oklch(
  from var(--primary)
  calc(l - 0.1)
  c
  h
);

Focus:

background: oklch(
  from var(--primary)
  calc(l + 0.05)
  c
  h
);

The color stays the same.

Only its lightness changes.

The Moment It Clicked

Traditional CSS asks:

What should the hover color be?

OKLCH asks:

How should the base color change?

That small shift in thinking makes a huge difference.

Before:

:root {
  --success: #22c55e;
  --success-hover: #16a34a;

  --warning: #f59e0b;
  --warning-hover: #d97706;

  --error: #ef4444;
  --error-hover: #dc2626;
}

After:

:root {
  --success: oklch(...);
  --warning: oklch(...);
  --error: oklch(...);
}

And every hover color is generated automatically:

button:hover {
  background: oklch(
    from var(--button-color)
    calc(l - 0.05)
    c
    h
  );
}

No duplicate color tokens & No maintenance burden.

Tailwind Is Already Doing This

Many developers still think in HEX and RGB.

The industry isn't moving toward OKLCH because the syntax is cool.

It's moving toward OKLCH because generating color variations mathematically is more reliable than manually picking dozens of related colors.

The Hidden Benefit During Rebranding

Imagine the design team changes the primary color.

Before:
All need review.

After:
Change one value.

Everything derived from it updates automatically.

Hover, Active, Focus, Shadows, Borders, and Glows.

All stay consistent.

The Secret Behind Smarter AI Outputs: CLAUDE.md

Asmaa Almadhoun — Wed, 30 Sep 2026 13:05:00 +0000

AI performs less like a genius and more like a new teammate. The quality of its work depends on the clarity of its instructions.

A practical guide to building maintainable AI instructions that improve code quality, reduce token usage, and scale across projects.

Why CLAUDE.md Matters

CLAUDE.md is the first source of project context Claude reads when working in a repository.

A well-written file helps Claude:

Understand the project quickly
Follow established architecture patterns
Avoid repeating mistakes
Produce more consistent outputs
Use fewer tokens

A poorly written file becomes a giant instruction dump that grows over time, increases token consumption, and makes it harder for Claude to identify what actually matters.

Rule of thumb: Keep always-on instructions small. Load detailed guidance only when needed.

My Recommended Structure

After trying multiple approaches, I found the “Separate permanent project knowledge from topic-specific guidance” guide in Claude and organized it as it should be.

.claude/
├── CLAUDE.md
├── rules/
│   ├── FileArchitecture.md
│   ├── UI-Standards.md
│   ├── Forms.md
│   ├── Testing.md
│   ├── Api-Patterns.md
│   └── Shared-Components.md
└── skills/
    ├── create-feature/
    │   └── SKILL.md
    └── add-pagination/
        └── SKILL.md

What Belongs in CLAUDE.md

The root file should answer only three questions:

1. What is this repository?

Provide a short summary:

This repository contains a React application built using TypeScript and Vite.

2. What must never be forgotten?

Include only critical project invariants.

Examples:

- React and shared dependencies must remain version-aligned.
- Never bypass authorization checks.
- Always use shared components before creating new ones.

3. Where are the detailed rules?

Provide a lightweight rule index.

## Rules

| Rule File | Read When |
|------------|------------|
| rules/ui-standards.md | Editing UI components |
| rules/forms.md | Working on forms |
| rules/testing.md | Writing tests |
| rules/api-patterns.md | Editing services or API integrations |
| rules/architecture.md | Creating new features |

Always-On vs On-Demand Context

The biggest optimization is moving detailed guidance into rule files.

Root CLAUDE.md

Contains:

Project overview
Critical rules
Rule index

Rule Files

Contain:

Topic-specific guidance
Code examples

Summery

Finally, the best CLAUDE.md files don’t try to teach AI everything. They teach AI where to look.

If you liked my effort, support this content by pressing Like. It motivates me to share more!

Do You Have Server-Side Data to Load in Your Select List and Not Local Data?

Asmaa Almadhoun — Tue, 18 Aug 2026 13:06:00 +0000

When building forms in React applications, selecting the right dropdown component can have a significant impact on performance, user experience, and maintainability.

One common question developers face is:

Should I use a regular Select component or an AsyncSelect component?

The answer depends on where your data comes from.

Use Select for Local Data

A standard Select component is the best choice when your options are already available in the application.

For example:

Statuses
Roles
Priorities
Categories
Fixed configuration values

<Select
  options={[
    { value: "pending", label: "Pending" },
    { value: "approved", label: "Approved" },
    { value: "rejected", label: "Rejected" },
  ]}
/>

In this scenario:

The data is loaded with the page.
Searching happens on the client side.
No additional API requests are required.
Implementation remains simple and straightforward.

Since the list is small and static, loading all options at once is usually the most efficient approach.

Use AsyncSelect for Server-Side Data

When your options must be retrieved from an API, AsyncSelect becomes the better solution.

Consider examples such as:

Users
Customers
Organizations
Products
Samples
Large reference tables

Instead of loading thousands of records when the page opens, AsyncSelect fetches only the data that the user needs.

import AsyncSelect from "react-select/async";

const loadOptions = async (inputValue) => {
  const response = await fetch(
    `/api/users?search=${inputValue}`
  );

  const users = await response.json();

  return users.map(user => ({
    value: user.id,
    label: user.name,
  }));
};

<AsyncSelect loadOptions={loadOptions} />;

When a user types:

demo

The component sends a request such as:

GET /users?search=demo

and displays only matching results.

Why AsyncSelect Is Better for Large Datasets

Imagine a system containing 50,000 users.

Loading all users into a regular Select component would:

Increase page load time
Consume unnecessary memory
Slow down searching
Create a poor user experience

With AsyncSelect:

Data is loaded only when needed.
Network requests are smaller.
The page loads faster.
Search is handled efficiently by the server.
Scalability improves significantly.

This approach is particularly important in enterprise applications where datasets continuously grow.

Real-World Example
❌ Using Select
<Select options={allUsers} />

If allUsers contains thousands of records, the browser must download and render everything upfront.

✅ Using AsyncSelect

<AsyncSelect
loadOptions={loadUsers}
defaultOptions
/>

The component requests data only when the user searches, reducing both server and browser workload.

Final Recommendation

A simple rule of thumb is:

If your dropdown data is local and already available, use Select. If your dropdown data lives on the server and needs to be fetched dynamically, use AsyncSelect.

Choosing the correct component not only improves performance but also creates a faster and more scalable user experience, especially in large business applications such as LIMS, ERP, CRM, and other enterprise systems.

Designing with Context Modern CSS Trends

Asmaa Almadhoun — Tue, 21 Jul 2026 13:05:00 +0000

CSS has evolved dramatically in recent years. What used to require heavy JavaScript libraries or preprocessors is now achievable natively with modern CSS. In 2026, developers are embracing container queries, parent selectors, scroll-driven animations, and view transitions as the foundation of responsive and interactive design.

📐 Container Queries

Traditionally, responsiveness relied on media queries tied to the viewport. But components often need to adapt to their parent container instead.

.card {
  container-type: inline-size;
}

@container (max-width: 400px) {
  .card {
    flex-direction: column;
    font-size: 0.9rem;
  }
}

🧩 Parent Selector :has()

The long-awaited :has() selector finally gives CSS the ability to style parents based on their children

.form-group:has(input:invalid) {
  border: 2px solid red;
  background: #ffe5e5;
}

👉 No more JavaScript hacks to highlight invalid forms — CSS handles it natively.

🎞️ Scroll-Driven Animations

Animations tied to scroll position are now hardware-accelerated and declarative.

@keyframes fadeIn {
  from { opacity: 0; transform: translateY(50px); }
  to   { opacity: 1; transform: translateY(0); }
}

.section {
  animation: fadeIn 1s linear;
  animation-timeline: scroll();
  animation-range: entry 0% cover 50%;
}

👉 Smooth parallax and reveal effects without JavaScript event listeners.

🔄 View Transitions

Page-to-page transitions are now possible even in multi-page apps.

html {
  view-transition-name: page;
}

::view-transition-old(page) {
  opacity: 0;
}

::view-transition-new(page) {
  opacity: 1;
  transition: opacity 0.5s ease;
}

👉 Native fade effects when navigating between pages — previously only achievable in SPAs.

🎨 Relative Color Syntax

CSS now supports dynamic color mixing and perceptual color spaces like oklch.

.button {
  background: color-mix(in oklch, blue 70%, white);
}

.button:hover {
  background: color-mix(in oklch, blue 50%, white);
}

👉 Accessible, consistent color palettes without design tools.

🧱 Masonry Layout

Pinterest-style grids are now native:

.gallery {
  display: masonry;
  gap: 1rem;
}

👉 Eliminates the need for complex JS libraries.

📊 Old vs. New CSS Approaches

Feature	Old Way	2026 Native CSS
Responsive components	Media queries	Container queries
Parent-child styling	JS class toggling	`:has()` selector
Parallax/reveal effects	JS scroll listeners	Scroll-driven animations
Page transitions	SPA frameworks	View transitions
Reusable styles	Sass/Less mixins	Native CSS mixins
Masonry grids	JS libraries	`display:`masonry``

📌 Conclusion

CSS in 2026 is lighter, faster, and more declarative than ever. By mastering container queries, :has(), scroll-driven animations, and view transitions, developers can build responsive, interactive, and accessible designs without relying on heavy JavaScript frameworks.

Lines vs Blocks(CSS): Divide & Grid Explained

Asmaa Almadhoun — Tue, 26 May 2026 13:00:00 +0000

Divider lines are one of the most underrated tools in modern UI design. At first glance, they may seem like nothing more than thin strokes on a screen. Yet, when used thoughtfully, they transform cluttered layouts into clean, organized interfaces. A simple line can elevate a feature list from ordinary to premium, guiding the user’s eye and making information easier to scan.

For designers, dividers are a subtle way to add structure. For developers, however, implementing them in responsive grids often feels like a headache double borders, overlapping lines, and messy CSS hacks are common pitfalls.

That’s where utility-first frameworks like Tailwind CSS step in, offering elegant solutions to a deceptively tricky problem.

The Problem With Borders in Grids

For developers, divider lines sound simple until responsive layouts enter the picture.

A grid with borders can quickly become messy:

Double-thick lines
Overlapping borders
Uneven spacing
Broken corners
Complex CSS selectors

What looks clean in a static mockup often becomes difficult in production.

The Secret Life of Tailwind's divide

To master the grid divider, you first have to understand how Tailwind’s divide-x and divide-y utilities actually work. They don't just blindly slap a border on every element. Instead, they leverage the CSS adjacent sibling selector (* + *).

This layout uses grid-cols-1 and divide-y. Notice how the dark blue horizontal lines appear only between the grey rows, not at the very top or bottom of the container.

This image displays three elements in a row using grid-cols-3 and divide-x. Thin, grey vertical lines divide the cards. Notice how the vertical dividers are perfectly flush with the blue background above and below the cards, separating the text elements while maintaining a sleek, unified container.

This image demonstrates how to handle a 2x2 grid (grid-cols-2). Standard divide utilities fail here. Instead, we use the "Background Gap Trick." The light grey container (the parent background) provides the divider colour. The four white cards are placed with a gap-px 1 pixel. creating perfect cross-hair intersection lines without any complex math. The icons are simple geometric shapes: a cube, a sphere, a pyramid, and a cylinder.

The Best Interfaces Use Both
The strongest UI systems combine lines and blocks intentionally.

For example:

A dashboard may use cards as blocks
But use divider lines inside each card
A pricing section may use separate columns
While subtle separators organize feature rows

This layered structure creates interfaces that feel:

Organized, Premium, Easy to scan, Easy to maintain

The trick is balance.

Too many lines create clutter.
Too many blocks create heaviness.

Great UI design sits between the two.

A Simple Rule to Remember

If users should feel:

“These items belong together” → use lines
“These items are separate sections” → use blocks

That single distinction solves most layout decisions.

Don't Make Me Think, Role of Colour in UX

Asmaa Almadhoun — Tue, 05 May 2026 13:00:37 +0000

In Don't Make Me Think, Steve Krug introduces the concept of self-explanatory design. The idea is simple: when users land on a page, they should immediately understand what it is and how to use it; without effort or confusion. There should be no need for what Krug calls “cognitive ditch-digging.”

When applying this principle to visual design, especially color, the goal shifts away from decoration and toward clarity. Color is not used just to make a page look appealing; it is used to remove ambiguity and guide users naturally.

The Reservoir of Goodwill

One of Krug’s key ideas is the “reservoir of goodwill.” This represents the patience users have when interacting with a product. Every time they encounter something confusing—such as a button that doesn’t look clickable or a color that carries no clear meaning—that reservoir begins to drain.

To preserve this goodwill, visual design must support usability:

Visual hierarchy: Color should clearly indicate what is important. If everything is bright or competing for attention, nothing stands out.
Consistency: Actions should always look the same. For example, if a “Submit” button is blue on one page, it should remain blue across the entire application. Changing colors for the same action forces users to stop and think.

The 60–30–10 Rule in UX Design

Although Krug does not specify an exact number of colors to use, modern UX practices—aligned with his philosophy—recommend keeping the color palette limited to maintain clarity.

A common approach is the 60–30–10 rule, which organizes colors as follows:

60%: Primary or background color (usually neutral)
30%: Secondary color for structure and layout
10%: Accent color for key actions and highlights

This structure helps create a balanced interface where users can easily identify priorities and actions without confusion.

Conclusion

Krug’s philosophy emphasizes that good design should feel obvious. In terms of color, this means using it deliberately to communicate meaning, reinforce consistency, and guide user attention. A restrained and purposeful color system reduces cognitive load and helps users interact with interfaces effortlessly.

Next.js Explained Using TikTok: SSR, SSG, ISR, and CSR Made Simple

Asmaa Almadhoun — Tue, 21 Apr 2026 13:00:00 +0000

TikTok looks simple on the surface: open the app, watch videos, scroll endlessly.
But behind that smooth experience is a complex system of rendering strategies, performance optimizations, and real-time interactions; exactly the kinds of problems that Next.js was designed to solve.

If TikTok were built using Next.js, it wouldn’t rely on a single rendering method. Instead, it would combine SSR, SSG, ISR, CSR, Streaming, Edge rendering, and partial rendering; each used deliberately to give users a fast, personalized experience at massive scale.
Let’s tell TikTok’s story, one Next.js concept at a time.

Chapter 1: Entering TikTok, Static First Impressions (SSG)

When someone visits TikTok for the first time, before logging in; they often see:

Marketing pages
Help center articles
About TikTok content
Community guidelines

These pages rarely change and are the same for everyone.
In Next.js terms, this is Static Site Generation (SSG).

Why SSG fits here

Content is predictable
SEO matters
Speed is critical
Millions of users access these pages

SSG allows TikTok to pre-build these pages once and serve them instantly from a CDN.

In the TikTok story, SSG represents the front door, reliable, and welcoming to everyone.

Chapter 2: The “For You” Feed, Personalization at Scale (SSR)

Once you log in, TikTok completely changes its behaviour.

Now you see:

A unique feed
Tailored recommendations
Content based on your interests, location, time, and device

No two users see the same thing.
This is Server-Side Rendering (SSR).

Why SSR is necessary

Content must be personalized
Data must be fresh
SEO may still matter (for web versions)
Security and authentication are required

With SSR, every request can generate a fully customized page before it reaches the browser.

In the story of TikTok, SSR is the brain, thinking in real time about you.

Chapter 3: Trending Hashtags, Fast but Frequently Changing (ISR)

TikTok’s Trending section is neither fully static nor fully dynamic.

Trending hashtags and sounds:

Change every few minutes
Are viewed by millions
Don’t require second‑by‑second precision

This is where Incremental Static Regeneration (ISR) shines.
Why ISR fits perfectly

Static performance
Automatic background updates
No rebuild of the entire app

Pages can update every 30–60 seconds without losing speed.

ISR is TikTok’s pulse, constantly updating, but never slowing down.

Chapter 4: Interactions; Likes, Comments, Follows (CSR)

When you:

Like a video
Post a comment
Follow a creator
Save a video

You expect instant feedback, not a page reload.
This behavior is powered by Client-Side Rendering** (CSR)**.
Why CSR is essential

High interactivity
Real-time UI updates
Minimal delay
No SEO concern for these actions

CSR handles all the living, breathing parts of TikTok that respond instantly to your touch.

CSR is TikTok’s reflex system, immediate and interactive.

Chapter 5: Videos First, Everything Else Later (Streaming SSR)

On TikTok, video content loads first.
Comments, captions, and recommendations follow.
This is intentional.
With Streaming SSR and React Suspense, TikTok can:

Render critical content immediately
Stream less important UI parts later
Improve perceived performance dramatically

The user doesn’t wait for everything, only what matters most.

Streaming is TikTok’s storytelling technique: hook the viewer first, fill in details later.

Chapter 6: Profile Pages, Static Meets Dynamic (Partial Rendering)

A creator’s profile has:
Static data: username, bio, profile photo
Dynamic data: follower count, latest videos, follow status

Using one rendering method for all of it would be inefficient.
Next.js solves this with partial rendering:

Static parts cached
Dynamic parts rendered on demand

This approach balances scalability, freshness, and cost.

Partial rendering is TikTok’s balance: efficiency without sacrificing accuracy.

The Big Picture: Why This Matters

TikTok’s success isn’t just about videos or algorithms.
It’s about choosing the right rendering strategy for the right moment.
Next.js makes this possible by allowing all these techniques to coexist in a single application:

Static where possible
Dynamic where necessary
Streaming where smart
Client-side where interactive

AI Writes What You Ask. Architecture Survives What You Didn’t Expect

Asmaa Almadhoun — Sat, 11 Apr 2026 08:35:33 +0000

Why Human Judgment Still Matters in the Age of AI‑Assisted Development

AI‑assisted coding tools have transformed modern software development. They can generate boilerplate, suggest patterns, and accelerate delivery.

Yet, as powerful as these tools are, they often fail in one critical dimension: design judgment. Being “smarter than AI” as a developer does not mean writing more complex code, it means designing systems that are resilient to ambiguity, change, and imperfect inputs.

One of the most common and painful examples of this gap appears in how systems handle unexpected variations, such as null, undefined, empty values, or missing parameters.

The Illusion of Correctness in AI‑Generated Code

AI tools typically optimize for expected behavior. They assume ideal inputs, clear contracts, and happy paths. This makes their output appear correct; until reality intervenes.

Consider your example:

If I do not send exactly null, the system crashes.

From a machine’s perspective, this may be “technically correct” code. From a human architect’s perspective, it is a design failure.

A well‑designed system should not collapse because:

null was replaced with undefined
a field was omitted
an empty string was passed
a client behaved slightly differently than expected

AI‑assisted implementations often miss these nuances because they replicate patterns rather than challenge assumptions.

Clean Architecture: Designing for Reality, Not Perfection

Robert C. Martin’s Clean Architecture: A Craftsman’s Guide to Software Structure and Design emphasizes an essential truth:

Software must be designed to survive change.

Clean Architecture teaches that systems should be:

Independent of frameworks
Independent of UI
Independent of databases
Independent of external agencies

Most importantly for your case, they should be independent of volatile input behaviour.

Why This Matters for Input Validation

In Clean Architecture, use cases define the rules of the application. That means they are responsible for deciding what is valid, acceptable, or recoverable, not controllers, not frameworks, and certainly not AI‑generated glue code.

If your system crashes because a parameter is missing or slightly different, that logic is living in the wrong place, or not living anywhere at all.

The Core Problem: Treating Inputs as Objects, Not Concepts

AI tends to treat input values literally:

null ≠ undefined ≠ empty ≠ missing

Humans, however, think conceptually:

“This value means ‘no data provided.’”

Clean Architecture encourages us to elevate that intent into the core of the system. Instead of spreading defensive checks everywhere, we define semantic boundaries:

What does “absence” mean?
Is this field required, optional, or conditional?
What is the default behavior if it’s missing?

If those questions are not answered explicitly, AI has no chance of answering them correctly.

Being Smarter Than AI: Design Principles That Matter

1. Normalize at the Boundaries

AI often mirrors whatever structure it sees. A human architect knows better.
At system boundaries (APIs, controllers, adapters), normalize inputs into a single internal representation. By the time data reaches your business rules, there should be one concept of “no value,” not five.

This aligns directly with Clean Architecture’s rule of keeping frameworks and details at the edges.

2. Move Validation into Use Cases

AI‑generated code frequently validates inputs close to the framework layer. This is convenient and wrong.
Clean Architecture insists that:

Business rules own validation
Use cases decide what is acceptable
Frameworks merely pass data along

When validation lives in use cases, handling null, missing, or empty values becomes a business decision, not a technical accident.

3. Define Explicit Contracts, Not Implicit Expectations

AI excels at following patterns, but struggles with unstated intent.
Clean Architecture favors:

Explicit input models
Clear invariants
Defined failure modes

If your system crashes when a value is not exactly null, it means the contract was never truly defined, only assumed.
Humans write contracts. AI follows them.

4. Design for Change, Not Compliance

AI optimizes for compliance with existing code. Humans optimize for change.
Your API may work today because clients send perfect inputs. Tomorrow:

a mobile app changes
a third‑party integration behaves differently
a serialization library updates its defaults

Clean Architecture prepares systems for that variability by isolating change and enforcing rules at the core.

Conclusion: Intelligence Is in the Architecture, being smarter than AI is not about rejecting AI tools, it’s about using them responsibly.
Let AI:

write repetitive code
scaffold structures
speed up implementation

Let humans:

efine boundaries
clarify intent
design for ambiguity
enforce architectural discipline

Clean Architecture provides the mental model that AI lacks: a focus on meaning, responsibility, and change. When your system gracefully handles null, undefined, empty, and missing values, not because of defensive hacks, but because of intentional design you are operating at a level AI has not yet reached.
And that is what real software craftsmanship looks like.

Reference

Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017.

Why fetch() Can Be Safer Than Axios After the 2026 Axios Hack

Asmaa Almadhoun — Wed, 01 Apr 2026 09:16:10 +0000

The question isn’t whether Axios is a “bad” library; it’s about risk surface. The Axios NPM compromise in March 2026 exposed a structural weakness in depending on third‑party libraries for something browsers already provide natively.

1. Axios was compromised; fetch() cannot be published with malware

On March 31, 2026, attackers hijacked the npm account of Axios’s maintainer and published malicious versions (1.14.1 and 0.30.4) containing an obfuscated malware dropper. The malware executed automatically during installation.

In contrast:

fetch() is built into browsers and Node.js.
It cannot be replaced or hijacked via a package manager.
There is no installation step, so no opportunity to insert post‑install malware.

Thus, fetch() has zero supply‑chain risk compared to a package like Axios.

2. Axios’ supply-chain attack vector came from its dependency distribution model
The Axios compromise happened because:

Attackers accessed the maintainer’s npm account,
Published malicious releases with a hidden dependency (plain-crypto-js),
Inserted a postinstall script that deployed a cross‑platform RAT.

fetch() has:

No dependencies
No maintainer accounts to hijack
No GitHub or npm supply chain to poison

Therefore, using fetch() eliminates an entire attack surface.

3. Axios introduced malware even though the code looked unchanged
Security investigators confirmed the attacker did not modify the Axios code directly, but only added a malicious dependency that executed during installation.

This means:

Even if you audited the Axios GitHub repo, you would not see the malicious code.
This type of attack is impossible with fetch() because it isn’t installed from npm.

4. Native fetch() is now fully supported and feature‑rich, reducing the need for Axios
Historically, Axios offered conveniences like:

automatic JSON transformation
request cancellation
simpler syntax
better error handling

But today:

Modern browsers and Node.js now support fetch() with AbortController, streaming, improved error handling, and Response.json().
The gap between Axios and native APIs has narrowed significantly.

Given this parity, adding Axios creates unnecessary dependency risk.

✔️ Summary

Fetch is “better” than Axios from a security standpoint because it is native, dependency‑free, cannot be hijacked through npm, and avoids the entire supply‑chain attack vector that enabled hackers to insert a remote‑access trojan into Axios’ malicious releases in March 2026

Code Meets Creativity: Using Google Stitch as a Frontend Developer

Asmaa Almadhoun — Tue, 24 Mar 2026 07:11:19 +0000

As frontend developers, we’re constantly exploring tools that help us move faster, from ideation to prototypes to production‑ready UI. Google Stitch has recently had a major revamp, positioning itself as an AI‑native design assistant that promises to help us explore layouts, generate UI structures, and test ideas without jumping into code immediately.
While Stitch isn’t a full replacement for real design tools or real designers, it can play a meaningful role in a modern frontend workflow. Here’s how you can practically use it as a developer.

Example: Creating a Landing Page With Google Stitch

Move from idea → layout → code in minutes. Below is a simple, practical workflow showing how you can generate a landing page using Stitch, refine it, and turn it into usable frontend code.
Each step includes a soft, rounded hybrid-style diagram to visually guide the user.

1️⃣ Step 1, Open Google Stitch
To begin, you visit Stitch and select your mode (Web or App).
This is where you pick the model and start your design session.

2️⃣ Step 2, Enter Your First Prompt
Stitch works best with clear natural‑language instructions. You describe the structure and feel of the landing page, and Stitch generates the UI.
Example prompt:

“Create a modern landing page with a hero section, feature grid, testimonials, and a CTA. Keep it clean and easy to rebuild using React + Tailwind.”

3️⃣ Step 3, Stitch Generates the Layout
Stitch analyzes your prompt and files, then produces the first version of your layout.
It typically includes full sections like the following

4️⃣ Step 4, Refine Using Follow‑Up Prompts
Just like a conversation, you can refine the design by telling Stitch what to change.
This is ideal for adjusting spacing, layout balance, color contrast, and visual hierarchy.
Examples:

“Increase spacing in the hero section.”
“Make the color palette darker.”
“Increase CTA visibility.”

5️⃣ Step 5, Export the Code

One of Stitch’s strengths is its code export ability.
After generating your design, you can extract HTML/CSS or even React‑friendly markup to speed up your build, you will find

Landing page (html)
Design file contains rules
Screen file is full Image of your landing page design

6️⃣ Step 6, Paste Into Your Code Editor
Paste the exported code into your editor (VS Code, WebStorm, etc.).
From here, you refine the structure, add Tailwind or your design tokens, and integrate real content.

🎉 Final Thoughts
Using Google Stitch as a frontend developer dramatically accelerates:

UI ideation
Layout prototyping
Early‑stage design exploration
Hand‑off between design & code
Building real landing page code faster

Stitch doesn’t replace designers or developers, but it makes frontend workflows smoother and faster, especially when you need structure before styling.