Coder Legion - Recent posts tagged frontenddevelopment

🔥 30 Days of Frontend — Day 5: React DevTools Profiler

Sat, 17 Oct 2026 16:39:44 +0000

When a React application starts feeling slow, one of the first things developers often do is reach for useMemo, useCallback, or React.memo.

We've all seen this pattern:

A component renders more often than expected.
The UI feels sluggish when interacting with a page.
A large list becomes noticeably slower as more items are added.
Updating one piece of state seems to trigger work across an entire component tree.

The natural reaction is to start memoizing components and functions.

But here's the problem: you might be optimizing code that isn't responsible for the slowdown in the first place.

React performance optimization should start with understanding what is happening, not guessing what might be happening.

That's where the React DevTools Profiler becomes useful.

1. What Is the React DevTools Profiler?

React DevTools is a browser extension that helps developers inspect React component trees, props, state, and other component-related information.

It includes two particularly useful panels:

Components: Inspect the component hierarchy, props, state, and component details.
Profiler: Record rendering activity and investigate how React updated the component tree.

The Profiler helps you understand the rendering work associated with a particular interaction.

For example, imagine you're working on an e-commerce application with a product grid containing hundreds of products.

When a user changes a filter, several things might happen:

The parent component updates.
The product list renders again.
Individual product cards render.
Sorting or filtering calculations run.
Some components render even though their visible data hasn't changed.

Some of this work might be necessary. Some might be avoidable.

Instead of assuming which component is responsible, you can record the interaction and inspect the results.

The goal isn't to eliminate every render. It's to understand whether the work is necessary and whether it affects the user experience.

2. Understanding How React Rendering Relates to Profiling

Before opening the Profiler, it's worth understanding what it actually measures.

A React update generally involves two important phases.

The render phase

During the render phase, React calls components as needed to determine what the next UI should look like.

This phase includes calculating the next React element tree and determining the changes required.

A component rendering doesn't automatically mean that the browser DOM will change.

For example:

function Counter({ count }) {
  console.log("Counter rendered");

  return <p>Count: {count}</p>;
}

Whenever React calls Counter, the component function executes and returns a React element describing the UI.

React may then determine that the resulting output doesn't require a DOM mutation.

A render is not the same thing as a DOM update.

This distinction is important because developers sometimes interpret every component render as expensive browser work.

The commit phase

After React finishes the necessary render work, it can commit the changes to the host environment, such as updating the DOM in a browser.

The Profiler helps you investigate rendering activity, but its measurements shouldn't be interpreted as a complete measurement of every part of browser performance.

For example, a page can have relatively inexpensive React rendering but still feel slow because of:

Expensive JavaScript outside React.
Large amounts of DOM layout or painting.
Long-running event handlers.
Network delays.
Large images or other resources.
Main-thread work that blocks user interactions.

This is why the React Profiler is one tool in a broader performance investigation, not a replacement for the browser's Performance panel.

3. What Can You Learn From the Profiler?

When you record a profiling session, the Profiler provides several useful ways to understand React's work.

A. Which components rendered?

The Profiler helps you identify the components involved in an update.

Suppose your component tree looks like this:

App
├── Header
├── SearchBar
├── FilterSidebar
└── ProductGrid
    ├── ProductCard
    ├── ProductCard
    ├── ProductCard
    └── ...

When the user types into the search field, you might discover that SearchBar, ProductGrid, and many ProductCard instances rendered.

That doesn't automatically mean all those renders are unnecessary.

You need to understand why they rendered and whether the work was expensive.

The component tree gives you a starting point for that investigation.

B. How often did components render?

Repeated rendering can be perfectly normal.

For example, typing into a controlled input typically updates state as the user types:

function SearchBar() {
  const [query, setQuery] = React.useState("");

  return (
    <input
      value={query}
      onChange={(event) => {
        setQuery(event.target.value);
      }}
      placeholder="Search products..."
    />
  );
}

Each keystroke can trigger an update.

That's expected behavior.

The more interesting question is what else happens during those updates.

If typing into the search field also triggers expensive calculations or unnecessary rendering across a large product grid, the Profiler can help you investigate that work.

Render frequency is a clue, not a performance verdict.

C. What caused a component to render?

This is one of the most useful parts of profiling.

A component might render because:

Its state changed.
Its parent rendered.
Its props changed.
Its context value changed.
An external store or another subscription triggered an update.

The exact cause depends on the component and the update mechanism.

For example:

function ProductPage() {
  const [query, setQuery] = React.useState("");
  const [selectedCategory, setSelectedCategory] =
    React.useState("all");

  return (
    <>
      <SearchInput
        value={query}
        onChange={setQuery}
      />

      <CategoryFilter
        value={selectedCategory}
        onChange={setSelectedCategory}
      />

      <ProductGrid query={query} />
    </>
  );
}

When selectedCategory changes, ProductPage renders again.

Because ProductGrid is a child of ProductPage, React may also render ProductGrid, even though its query prop hasn't changed.

That can be a candidate for optimization, but it isn't automatically a problem. First, determine whether the work is expensive enough to matter.

Also, remember that React DevTools' ability to display detailed render reasons depends on the React version, development tooling, and available settings. Don't assume every render will always have a definitive explanation displayed.

4. How to Use React DevTools Profiler: A Step-by-Step Workflow

Let's turn this into a practical workflow.

Step 1: Reproduce the actual performance problem

Start with the user interaction that feels slow.

Examples include:

Typing into a search field.
Changing a product filter.
Switching tabs.
Expanding a large navigation menu.
Updating a dashboard with multiple charts.
Scrolling through a long list.

Avoid profiling random interactions without a clear question.

A useful starting question might be:

Why does changing a product filter cause so much rendering work?

This gives you a specific behavior to investigate.

Step 2: Open React DevTools

Install React Developer Tools for your browser if you haven't already.

Open your application, launch the browser's developer tools, and locate the Profiler tab.

Make sure you're profiling the application and interaction you want to investigate.

For realistic performance measurements, prefer a production build or a profiling-enabled production build where appropriate. Development mode can introduce extra overhead, and Strict Mode may intentionally invoke rendering-related logic more than once to help reveal bugs.

Development profiling is still valuable for understanding component behavior, but don't assume its timings represent production performance.

Step 3: Start recording

In the Profiler tab, start a recording.

Then perform the exact interaction that causes the slowdown.

For example:

Start recording.
Type a search query.
Change a category filter.
Wait for the UI to settle.
Stop recording.

Keep the recording focused.

Step 4: Inspect the recorded commits

The Profiler organizes recorded updates into commits.

A commit represents a point at which React applied an update to the host environment

Select a commit related to your interaction, then inspect the available visualization and component details.

Look for patterns such as:

A large subtree rendering during a small interaction.
An expensive component repeatedly appearing in relevant commits.
Components rendering even though their inputs appear unchanged.
Expensive calculations associated with frequently occurring updates.

Don't immediately optimize the component with the largest-looking bar. First establish what the measurement represents and whether that component is related to the user-visible problem.

Step 5: Make one targeted change

Change one thing at a time whenever possible.

If you simultaneously add React.memo, introduce several useMemo calls, restructure the component tree, and change how state is managed, you won't know which change made the difference.

A focused experiment makes the results easier to interpret.

Step 6: Profile again

Repeat the same interaction under comparable conditions.

Compare:

Actual rendering duration.
Which components rendered.
How much of the subtree participated in the update.
Whether the interaction feels more responsive.
Whether the optimization introduced additional complexity or bugs.

If the measured React work decreased but the interaction still feels slow, investigate other parts of the performance pipeline.

An optimization isn't complete until you've verified its effect.

The React DevTools Profiler helps turn vague performance complaints into concrete questions about rendering behavior.

Instead of asking:

"Why is React so slow?"

Start by asking:

"Where is my application actually spending time, and what evidence do I have?"

That shift—from guessing to measuring—is what makes performance optimization more systematic.

🔥 30 Days of Frontend — Day 4: Memoization in React

Sun, 11 Oct 2026 17:45:13 +0000

Have you ever looked at a React component and thought:

“Maybe I should wrap this function with useCallback, this calculation with useMemo, and the component with React.memo?”

You're not alone.

Memoization is one of the most frequently discussed React performance techniques. But it's also one of the easiest to misuse.

You can add memoization to an application, introduce more complexity, and still fail to improve its performance.

Why?

Because memoization is not about preventing every render. It's about avoiding work that doesn't need to happen again.

Let's understand how it works, when it helps, and when it becomes unnecessary complexity.

1. What Is Memoization?

Memoization is an optimization technique that caches the result of a computation so it can be reused when the relevant inputs haven't changed.

Imagine you have an expensive function:

function calculateTotalPrice(products: Product[]) {
  console.log("Calculating total price...");

  return products.reduce(
    (total, product) => total + product.price,
    0
  );
}

Every time you call this function, it calculates the total again.

If the product list hasn't changed, repeating the same calculation may be unnecessary.

Memoization lets us reuse a previous result when the inputs are still valid.

Conceptually:

Inputs
  |
  v
Have relevant inputs changed?
  |
  +---- Yes ----> Recalculate and cache the result
  |
  +---- No -----> Reuse the cached result

React provides three commonly used memoization APIs:

useMemo — caches a calculated value.
useCallback — caches a function reference.
React.memo — can skip a component render when its props are unchanged.

They solve different problems, so they shouldn't be treated as interchangeable.

2. `useMemo`: Cache an Expensive Calculation

Consider a product dashboard containing thousands of products.

You need to filter products by category and calculate which products match a search query.

function ProductList({
  products,
  search,
}: {
  products: Product[];
  search: string;
}) {
  const filteredProducts = products.filter((product) =>
    product.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <ul>
      {filteredProducts.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

The filtering operation runs whenever ProductList renders.

That may be perfectly fine for a small list. But imagine the filtering logic is expensive and the component also renders because some unrelated state changes.

We can cache the calculated array with useMemo:

import { useMemo } from "react";

function ProductList({
  products,
  search,
}: {
  products: Product[];
  search: string;
}) {
  const filteredProducts = useMemo(() => {
    return products.filter((product) =>
      product.name.toLowerCase().includes(search.toLowerCase())
    );
  }, [products, search]);

  return (
    <ul>
      {filteredProducts.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

What changed?

React recalculates filteredProducts when products or search changes.

If the component renders again while both dependencies remain unchanged, React can reuse the previous result.

For example:

Initial render
  └── products + search
        └── Calculate filtered products

Unrelated state changes
  └── products + search unchanged
        └── Reuse cached result

Search changes
  └── New search value
        └── Calculate filtered products again

An important limitation

useMemo does not make every search update faster.

When the user types another character, search changes. The filtering calculation must run again to produce the correct results.

Memoization is most useful when a calculation is expensive and its dependencies remain unchanged across renders.

3. `useCallback`: Cache a Function Reference

Now let's look at useCallback.

Consider a parent component that passes an event handler to a child:

function ProductPage() {
  const [count, setCount] = useState(0);

  const handleAddToCart = (productId: number) => {
    console.log("Added product:", productId);
  };

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <ProductCard onAddToCart={handleAddToCart} />
    </>
  );
}

Whenever ProductPage renders, the function expression creates a new function reference.

Even though the function's logic hasn't changed, the reference is different.

That matters if ProductCard is memoized and receives the handler as a prop.

const ProductCard = React.memo(function ProductCard({
  onAddToCart,
}: {
  onAddToCart: (productId: number) => void;
}) {
  console.log("ProductCard rendered");

  return (
    <button onClick={() => onAddToCart(42)}>
      Add to cart
    </button>
  );
});

By default, React.memo compares props. A new function reference means the handler prop is considered changed, so the child may render again.

We can stabilize the function reference with useCallback:

import { useCallback, useState } from "react";

function ProductPage() {
  const [count, setCount] = useState(0);

  const handleAddToCart = useCallback((productId: number) => {
    console.log("Added product:", productId);
  }, []);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <ProductCard onAddToCart={handleAddToCart} />
    </>
  );
}

Because the callback doesn't depend on any reactive values from the component, its dependency array is empty.

Now, when count changes, React can reuse the same callback reference. That allows the memoized ProductCard to skip rendering if its other props also remain unchanged.

What about dependencies?

Consider this callback:

const handleAddToCart = useCallback(() => {
  setCartCount(cartCount + 1);
}, [cartCount]);

The callback depends on cartCount, so its reference changes whenever cartCount changes.

For state updates that depend on the previous state, a functional update can sometimes avoid that dependency:

const handleAddToCart = useCallback(() => {
  setCartCount((currentCount) => currentCount + 1);
}, []);

This works because the updater receives the latest state value.

Important: useCallback caches a function reference; it doesn't make the function's execution inherently faster.

If you're not passing the function to a memoized child or using it in another dependency-sensitive context, useCallback may provide no meaningful benefit.

4. `React.memo`: Skip Unnecessary Component Renders

React.memo is different from the two hooks.

It wraps a component and lets React skip rendering it when its props are unchanged, subject to React's normal rendering behavior.

For example:

const ProductCard = React.memo(function ProductCard({
  name,
  price,
}: {
  name: string;
  price: number;
}) {
  console.log("Rendering ProductCard:", name);

  return (
    <article>
      <h3>{name}</h3>
      <p>${price}</p>
    </article>
  );
});

Suppose the parent updates a separate counter:

function ProductPage() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount((current) => current + 1)}>
        Count: {count}
      </button>

      <ProductCard name="Keyboard" price={120} />
    </>
  );
}

The parent renders when the counter changes, but the ProductCard props remain the same.

React can skip rendering ProductCard.

However, React.memo is not an absolute rendering lock. The component can still render because of its own state changes, consumed context changes, or other React behavior.

A common mistake: unstable object props

Consider this example:

<ProductCard
  product={{
    id: 1,
    name: "Keyboard",
    price: 120,
  }}
/>

A new object is created whenever the parent renders.

Even if the object contains the same data, its reference is different.

Consequently, a memoized child can still render.

This is why understanding referential equality matters when optimizing React applications.

Two objects can contain identical properties and still be different references:

const first = { name: "Keyboard" };
const second = { name: "Keyboard" };

console.log(first === second); // false

Memoization works best when the values that cross component boundaries have the stability needed for the optimization to be effective.

5. How These Three APIs Work Together

Let's put the concepts together.

Imagine a dashboard with:

A product search field
A product list
A shopping cart counter
Expensive product filtering
Memoized product cards

A possible optimization strategy is:

ProductPage
    |
    ├── useCallback
    |      └── Stabilize a handler passed to a memoized child
    |
    ├── useMemo
    |      └── Cache filtered products when dependencies are unchanged
    |
    └── ProductList
           |
           └── React.memo
                  └── Skip rendering when props are unchanged

The APIs address different sources of repeated work:

API	What it caches or optimizes	Useful when
`useMemo`	A calculated value	A calculation is expensive and dependencies often stay unchanged
`useCallback`	A function reference	Stable identity helps a memoized child or dependency-sensitive hook
`React.memo`	A component's render work based on props	A component renders often with unchanged props and rendering is costly

The key is not to use all three together automatically. Use only the optimization that addresses the measured bottleneck.

6. When Memoization Doesn't Help

Memoization has costs too.

It adds some combination of dependency tracking, comparisons, cached values, and code complexity.

Consider this example:

const fullName = useMemo(() => {
  return `${firstName} ${lastName}`;
}, [firstName, lastName]);

Unless there is a specific reason to cache this value, the direct version is simpler:

const fullName = `${firstName} ${lastName}`;

Combining two strings is inexpensive. Memoizing it is unlikely to produce a measurable improvement.

Another example:

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

If this function is used only by a regular button in the same component, stabilizing its identity may not improve anything.

The lesson is simple:

Not every calculation is expensive, not every render is a problem, and not every new function reference matters.

7. React Compiler Changes the Conversation

Modern React projects may use the React Compiler, which can automatically memoize components, values, and functions when it can safely do so.

This means manually adding useMemo, useCallback, and React.memo everywhere is less necessary in compiler-enabled applications.

However, the compiler does not eliminate the need to understand performance.

It cannot make every expensive algorithm cheap, remove the cost of rendering thousands of unnecessary elements, or guarantee that a slow interaction will become fast.

You should still understand:

What triggers a render
How props and references change
Which calculations are expensive
When state should live closer to the components that use it
How to measure actual rendering performance

If your project uses React Compiler, follow its guidance and avoid adding manual memoization without a reason. Manual memoization can still be useful in appropriate cases, but it shouldn't be automatic boilerplate.

8. Final Takeaway

Memoization is a tool, not a coding style, and the goal isn't to eliminate every render, the goal is to make the application responsive while keeping the code maintainable.

My preferred performance workflow remains:

Measure → Identify the bottleneck → Optimize → Measure again.

Don't optimize because a component rendered, optimize because you've found work that is unnecessarily expensive.

🔥 30 Days of Frontend — Day 2: React Reconciliation

Fri, 25 Sep 2026 17:17:09 +0000

Why doesn't React update the entire UI after every state change?

Because React uses reconciliation.

When a component renders again, React produces a new element tree.

React then determines what changed compared with the previous result and prepares the necessary updates.

Think of it as:

Previous tree + New tree
          ↓
    Reconciliation
          ↓
   Required updates

🧠 A Simple Example

Imagine we have a list of todos:

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <TodoItem key={todo.id} todo={todo} />
      ))}
    </ul>
  );
}

Initially, our list looks like:

[A, B, C]

Then it changes to:

[A, B, D]

Because we're using stable keys, React can reason about the identity of each item:

A → same item
B → same item
C → removed
D → new item

The important part isn't just that the data changed.

It's that React can understand which elements represent the same identity across renders.

🔑 Why Do Keys Matter?

Consider this:

items.map((item) => (
  <Item key={Math.random()} />
))

Every render produces a different key.

That makes it difficult for React to identify the item as the same item from the previous render.

Instead, use a stable identifier:

items.map((item) => (
  <Item key={item.id} />
))

Now React has a stable way to understand:

"This is the same item as before."

This becomes especially important when components contain local state.

For example, if each Item contains an input field, unstable keys can cause component instances to be recreated and lead to unexpected state behavior.

🧩 A Useful Mental Model

When debugging list rendering, don't only ask:

"Why did this component render?"

Also ask:

"Does React know this is the same component as before?"

That question can help explain many confusing behaviors involving:

List keys
Component identity
Local state
Re-renders
Elements being added or removed

⚙️ Where Does Reconciliation Happen?

Reconciliation happens during React's render phase.

React determines what work needs to be done first. The resulting changes are then applied during the commit phase.

A simplified mental model is:

State Update
     ↓
Render
     ↓
Reconciliation
     ↓
Determine required changes
     ↓
Commit
     ↓
DOM updates

It's important to remember that rendering does not mean React immediately changes the DOM.

The render phase is where React figures out what the next UI should look like.

The commit phase is where React applies the necessary changes to the DOM.

🎯 The Takeaway

Reconciliation is one of the core ideas behind how React updates the UI efficiently.

Once you understand reconciliation, concepts like keys, component identity, and rendering behavior become much easier to reason about.

SEO Basics Every Frontend Developer Should Know

Tue, 01 Sep 2026 05:00:00 +0000

Introduction

SEO gets treated like it's purely a marketing job — write good content, use the right keywords, done. But a huge chunk of what actually affects search rankings is technical, and it lives entirely in the code, meaning it's the frontend developer's job whether anyone officially assigns it or not.

Here's what I actually implement on every project, client or personal, without needing a marketing background.

1. Semantic HTML (This Matters More Than You Think)

Search engines read your HTML structure to understand what's important on the page.

<!-- Weak -->
<div class="title">Best Frontend Tools</div>
<div class="text">Content here...</div>

<!-- Semantic -->
<h1>Best Frontend Tools</h1>
<p>Content here...</p>

Rules to follow:

One <h1> per page, describing the main topic
Use <h2>, <h3> in proper hierarchical order, not just for visualsize
Use <nav>, <header>, <main>, <footer>, <article> where appropriate instead of generic <div>s everywhere

2. Meta Tags (The Basics Actually Matter)

<head>
  <title>15 Free Frontend Tools Every Developer Should Know | Your Site</title>
  <meta name="description" content="Discover 15 free frontend tools for design, CSS, icons, and testing — perfect for beginners and pros.">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

<title> should be unique per page, under ~60 characters, with your main keyword near the front
meta description doesn't directly boost ranking, but it's what shows in search results — a good one improves click-through rate, which does matter
viewport meta tag is required for mobile-friendliness, which Google explicitly factors into ranking

3. Image Alt Text

<img src="react-hooks-diagram.png" alt="Diagram showing useState and useEffect hook lifecycle in React">

Alt text serves two purposes: accessibility (screen readers rely on it) and SEO (search engines can't "see" images, only read this text). Never leave it empty on meaningful images, and never stuff it with random keywords — describe what's actually in the image.

4. Page Speed (A Direct Ranking Factor)

Google explicitly uses Core Web Vitals — loading speed, interactivity, and visual stability — as ranking signals. This connects directly to earlier articles in this series:

Optimize images with Squoosh or TinyPNG (Article 1)
Use max-width: 100% and proper responsive images instead of oversized
files (Article 6)
Lazy-load images below the fold: <img loading="lazy">
Check your score with Lighthouse and fix what it flags (Article 1)

A fast site isn't just a nice-to-have anymore — it's a direct, measurable ranking factor.

5. Mobile-Friendliness

Google uses mobile-first indexing, meaning it primarily looks at your site's mobile version when determining rankings, even for desktop search results. Everything covered in Article 6 (Responsive Design) directly affects SEO, not just user experience.

6. Clean, Descriptive URLs

Weak:  yoursite.com/page?id=4829
Better: yoursite.com/blog/free-frontend-tools

Descriptive URLs help both search engines and users understand what a page is about before even clicking.

7. Internal Linking

Link related pages/articles to each other within your site (like this series does, referencing earlier articles). This helps search engines understand your site structure and helps visitors discover more of your content — both of which support better rankings over time.

8. Structured Data (Optional but Powerful)

Adding Schema.org markup (JSON-LD format) helps search engines understand your content type — a blog post, a product, a review — and can unlock rich search result features like star ratings or FAQ dropdowns.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO Basics Every Frontend Developer Should Know",
  "author": "Muhammad Farhan"
}
</script>

This is more advanced and not essential for every project, but worth knowing it exists.

Common Beginner Mistakes

Using <div> for everything instead of semantic tags. Costs you nothing to fix and genuinely helps both SEO and accessibility.
Skipping alt text entirely. Easy to forget, meaningfully impactful when done right.
Shipping unoptimized images. The single most common performance (and therefore SEO) killer on beginner and even client projects.
Ignoring mobile experience because the desktop version "looks fine." Google mostly doesn't care how your desktop version looks.

Final Thoughts

You don't need to become an SEO specialist to meaningfully improve how a site ranks — most of the technical fundamentals are just good development practices you should be doing anyway: semantic HTML, fast load times, proper alt text, and mobile responsiveness. Build these habits into every project from the start, and SEO stops being a separate task tacked on at the end.

That wraps this 15-article series — if you've followed along from Article 1, you now have a solid, practical foundation across CSS, React, tooling, deployment, freelancing, and SEO. Go build something with it.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

No More Fake DOM: Testing Library Unit Tests in the Real Browser

Mon, 31 Aug 2026 07:54:58 +0000

Every Testing Library test you have written runs against a simulated DOM. You know this. You accepted it years ago, along with the small pile of things that come with it: no real layout, nothing ever drawn on a screen, jsdom throwing on APIs it does not implement, and the quiet suspicion that a passing test and a working component are not quite the same claim.

I co-maintain twd-js, which runs tests inside your actual dev server. It was built for flow testing: visit a route, click through the app, assert on what the user sees. Component testing was the thing it did not do, and I said so in print when I compared it to Vitest Browser Mode.

Then I tried calling render() inside a TWD test, mostly to see what would break.

import { render, screen, cleanup } from "@testing-library/react";
import { describe, it, afterEach } from "twd-js/runner";
import { AppProvider } from "@/context/AppContext";
import { twd } from "twd-js";
import { Add } from "../Add";
import { componentHost, restorePage } from "@/twd-tests/support/componentHost";

describe("Add Component", () => {
  afterEach(() => {
    cleanup();
    restorePage();
  });

  it("renders the Add component", () => {
    // componentHost() is a blank div on an empty page. More on it below.
    render(<AppProvider><Add /></AppProvider>, { container: componentHost() });

    twd.should(screen.getByText("Add Item"), "be.visible");
  });
});

Nothing broke. The component mounts into the page, the sidebar shows it running, and the assertion checks an element that exists in a real browser. Same Testing Library API, no fake DOM under it.

That AppProvider is the real one, not a test double. Add uses a hook that reads from context and posts to an API, and in a real browser both of those work, so there is nothing to stand in for. That turns out to matter more than the missing jsdom.

Why this works at all

Testing Library was never tied to jsdom. @testing-library/react renders a component into a DOM node and @testing-library/dom queries it. jsdom is just the DOM most people hand it. Give it a real one and the same code runs, except now the component is actually on a screen, with a real size, a real position, and your CSS applied to it.

TWD already runs inside your app in the browser, so the real DOM is right there. render() uses it.

The setup

One helper, and no changes to your app.

render() appends its container to document.body, so the component lands after the app, a full viewport below the layout. The app is also still on the page, so screen matches its elements as well as the ones your test just rendered. Both of those are the same problem: the app is in the way.

const HOST_ID = "twd-component-host";
const APP_ROOT_ID = "root";

let appRoot: HTMLElement | null = null;
let placeholder: Comment | null = null;

export function componentHost(): HTMLElement {
  detachApp();

  let host = document.getElementById(HOST_ID);
  if (!host) {
    host = document.createElement("div");
    host.id = HOST_ID;
  }
  if (!host.isConnected) {
    document.body.prepend(host);
  }

  host.innerHTML = "";
  return host;
}

export function restorePage(): void {
  document.getElementById(HOST_ID)?.remove();
  attachApp();
}

function detachApp(): void {
  if (placeholder) return;

  const root = document.getElementById(APP_ROOT_ID);
  if (!root) return;

  appRoot = root;
  placeholder = document.createComment(" app detached by twd component test ");
  root.replaceWith(placeholder);
}

function attachApp(): void {
  if (!placeholder || !appRoot) return;

  placeholder.replaceWith(appRoot);
  placeholder = null;
  appRoot = null;
}

Detaching the app root is not the same as emptying it. root.innerHTML = "" pulls the DOM out from under React while it still holds references to those nodes, and the app does not come back. Moving the node out and putting it back leaves the references intact, so restorePage() returns a live app.

prepend rather than append puts the component at the top of the page instead of below where the app used to be, so you can watch it run without scrolling.

The payoff is that screen behaves exactly like it does in jsdom. The only thing in the document is what your test rendered, which also covers anything the component renders through a portal, since that lands on document.body rather than inside the container.

One detail worth keeping: cleanup() and restorePage() belong in afterEach, not beforeEach. In jsdom the environment is torn down for you between files. In a real browser it is not, so renders stack up, and your flow tests need the app back before they run.

That is the whole setup. Your app does not change.

Two traps

screenDom will not find your component. TWD exposes screenDom, a wrapper around Testing Library queries scoped to your app root so it never matches the TWD sidebar. Testing Library's render() mounts outside that root. I probed it in a real app to be sure:

container.parentElement=<body>   inside #root=false
screen: found   screenDom: not found   screenDomGlobal: found

So use Testing Library's own screen, or TWD's screenDomGlobal, which queries the whole document. If you pick screenDomGlobal, keep queries specific, because it can also match elements inside the sidebar.

Everything else works normally. twd.should takes any element you hand it, whether a query found it in your app or in a component you just rendered.

Your test pattern probably says .ts. Component tests are .tsx. A pattern of /**/*.twd.test.ts skips them silently, with no error and no missing-file warning. They simply never appear in the sidebar:

twd({
  testFilePattern: "/**/*.twd.test.{ts,tsx}",
}),

If you also run Vitest in the same repo, exclude the browser tests from it. Vitest matches *.test.tsx by default, collects the TWD files, finds no describe it recognises, and fails the run with No test suite found in file:

test: {
  exclude: [...configDefaults.exclude, "**/*.twd.test.*"],
},

Both kinds of test, one run

This is the part I did not expect to matter as much as it does.

Component tests and flow tests are now the same kind of artifact. They are files in the same project, running in the same browser, in the same session, against the same instrumented bundle. So one command runs both:

$ npx twd-cli run
Running 14 test(s)...
Code coverage data written to .nyc_output/out.json

--- Run complete ---
  Passed: 14 | Failed: 0 | Skipped: 0
  Duration: 6.9s

Ten of those drive the whole app through routing, search, sorting and deletion. Four render a single dialog component in isolation. One coverage file comes out the other end, covering both.

That last part is usually where multi-runner setups get tedious. Component coverage in one report, end-to-end coverage in another, and a merge step that someone maintains. Here there is nothing to merge, because there was only ever one run.

Where each style fits

Rendering a component in isolation is the right move when the component is the subject: a form's validation states, a dialog that opens and closes, a table that sorts. You skip the navigation, you skip the fixtures, and the test says exactly what it is about.

Flow tests stay the right move for anything that crosses a boundary. Routing, data loading, a sequence of screens, state that survives a navigation. Rendering a component in isolation to test those means rebuilding the app around it, which is how component test files end up longer than the components.

The useful change is not that one replaced the other. It is that choosing between them is now a decision about scope, made per test, instead of a decision about which runner and which DOM you are committing to.

Try it

If you already have Testing Library tests, the fastest way to see this is to copy one, change the imports for describe and it to twd-js/runner, and hand render() the component host.

The example app from this post is on GitHub, with the same component tested in jsdom and in the browser side by side: kevinccbsg/frontend-challenge.

In the next post I look at what happened when I put those two versions next to each other. The jsdom test mocked the hook it was testing through, and once I stopped mocking, it turned out the mocks had been doing most of the work.

How I Landed My First Freelance Client as a Frontend Developer

Fri, 28 Aug 2026 05:00:00 +0000

Introduction

I'm not going to pretend this was some overnight success story — it wasn't. It took real, unglamorous effort before anything happened. But I think that's exactly why this story is more useful than the polished "I made $10k my first month" posts you see floating around.

Here's honestly what happened, and what I'd tell any beginner developer trying to land their first client right now.

Where I Started

I had a portfolio (see Article 12 for what actually goes into a good one), a few personal projects, and zero client work. No reviews, no testimonials, nothing to point to except "trust me, I can build this."

That's a genuinely hard position to sell from — and I want to be upfront about that instead of skipping past it.

What Didn't Work

Mass-applying to generic Fiverr/Upwork gigs with a copy-pasted message. I sent probably 15-20 near-identical proposals early on. Zero responses. Clients can tell instantly when a message wasn't written specifically for their project.

Underpricing to "compete." I dropped my rate low, assuming price was the deciding factor. It wasn't — the clients I was losing to weren't choosing based on price; they were choosing based on trust, and a rock-bottom price can actually read as a red flag rather than a selling point.

What Actually Worked

Before sending a proposal, I'd actually look at the client's existing website or business, and mention something specific in my message.

Instead of: "Hi, I'm a frontend developer available for your project."

I wrote: "I checked out your current site — the mobile menu doesn't
open properly on iPhone Safari, which is likely costing you visitors.
I can fix that as part of rebuilding your homepage."

That single specific observation did more than 20 generic messages combined.

2. I Led With a Live Demo, Not Just a Portfolio Link

For one prospect, instead of just sending my portfolio, I built a quick, rough homepage mockup based on their existing brand and sent a live preview link alongside my proposal. It took maybe 90 minutes, and it was the deciding factor in getting that first "yes."

This doesn't scale to every application — but for a client you genuinely want, showing instead of just telling is worth the extra effort.

3. I Asked for a Testimonial Immediately After Finishing

The moment that first project wrapped up and the client was happy, I asked directly for a short written testimonial and permission to list the project in my portfolio. That single testimonial made every proposal after it noticeably stronger — I finally had proof, not just a promise.

4. I Treated the First Project as a Portfolio Investment, Not Just a Paycheck

I overdelivered slightly on that first project — a bit more polish, a bit more communication than strictly required. It wasn't about being a pushover; it was a deliberate decision, because that project was going to be my proof for every client after it.

What I'd Tell Beginners Specifically

Your first client won't come from volume — it'll come from one genuinely well-researched, specific pitch. Send fewer, better proposals.
A rough live demo beats a polished portfolio link for a serious prospect. It proves you can actually do the specific thing they need, not just that you can build things in general.
Don't undercharge to compete. Price confidently for the value, and let your specificity and communication build trust instead.
Ask for a testimonial the moment you finish, while the client is happiest. Don't wait — that window closes fast.
Your first project is marketing, not just income. Treat it that way, and the second client comes noticeably easier than the first.

Final Thoughts

There's no trick that skips the hard part — you do have to put in real, specific effort before that first client says yes. But once you have that first project and testimonial, everything after it gets meaningfully easier, because you're no longer selling a promise. You're selling proof.

If you're still working on landing your first client, I'd genuinely love to hear where you're stuck — drop it in the comments.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

How to Build a Portfolio Website That Actually Gets You Hired

Fri, 21 Aug 2026 05:00:00 +0000

Introduction

I've rebuilt my own portfolio more times than I can count, and every rebuild taught me something the last version got wrong. Most developer portfolios fail for the same handful of reasons — and none of them are "not enough animations" or "not a fancy enough design."

This article covers what actually matters, based on what I've learned building my own portfolio and two client portfolio sites.

What a Portfolio Is Actually For

A portfolio has one job: convince someone (a client or a hiring manager) that you can solve their problem. It's not a design showcase for its own sake — every section should answer the visitor's unspoken question, "can this person help me?"

The Sections That Actually Matter

1. A Clear Headline (Not Just Your Name)

Weak: "Muhammad Farhan"
Better: "Frontend Developer building fast, clean websites with React & Tailwind CSS"

The second version tells a visitor exactly what you do within two seconds — no scrolling required.

2. 3-5 Real Projects (Quality Over Quantity)

A portfolio with 3 well-explained projects beats one with 10 half-finished ones. For each project, include:

A live link (not just a GitHub repo — most non-developers won't clone your code)
A short description of the problem it solves
Your specific role and the tech stack used
1-2 sentences on a challenge you solved

Example:
"UX Gazette — A blog platform built for a real client using WordPress.
Customized the theme, set up categories and SEO structure, and optimized
page speed from a 60 to a 92 Lighthouse score."

That last sentence — a specific, measurable outcome — is worth more than any amount of visual polish.

3. About Section (Keep It Short and Human)

Skip the generic "passionate developer who loves clean code" line — everyone writes that. Say something specific: how you started, what you're currently learning, what kind of projects you enjoy.

4. Clear Contact Options

Don't make people hunt for how to reach you. Email, and at minimum one social/professional link (GitHub, LinkedIn), visible without scrolling to the very bottom.

What to Leave Out

A skills section with progress bars. "HTML — 90%" means nothing measurable — show skill through projects instead, not arbitrary percentages.
Every single project you've ever built. Tutorial clones and unfinished experiments dilute your best work. Curate ruthlessly.
Overly complex animations that slow load time. A portfolio that takes 6 seconds to load is actively working against you, no matter how good it looks once it finally does.

Technical Details That Quietly Matter

Mobile responsiveness. A huge percentage of visitors, including recruiters, will open your link on their phone first. If it breaks there, that's often the entire impression formed.
Fast load time. Run it through Lighthouse (see Article 1). Aim for 90+ on performance.
Working links. Sounds obvious, but broken project links are one of the most common portfolio mistakes I've seen — test every single one before sharing.
A resume/CV download link, if you're job hunting alongside freelancing.

Real Example: My Own Approach

My portfolio Muhammad Farhan follows exactly this structure: a clear one-line headline about React + Tailwind, a curated project section instead of everything I've built, and direct contact info without needing to scroll far. It's not the most visually elaborate portfolio out there — but it's fast, clear, and gets straight to the point.

Common Beginner Mistakes

Launching a portfolio, then never updating it. Add your best new project as soon as it's live — an outdated portfolio signals inactivity.
No live demo links. A GitHub repo alone asks too much of a busy visitor. Deploy everything (see Article 10) and link the live version.
Copying a template without understanding it. If someone asks about your portfolio's code in an interview and you can't explain a decision, that's a red flag they'll notice.
Burying your best project. Lead with your strongest, most relevant work — not chronologically, but by impact.

Final Thoughts

A great portfolio isn't the flashiest one — it's the clearest one. Someone should be able to land on your site, understand what you do, see proof you can do it, and know how to contact you, all within about 30 seconds. Everything else is secondary.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Why Do AI-Generated Websites All Look the Same?

Thu, 13 Aug 2026 17:42:07 +0000

Have you noticed something strange lately?

You ask AI to build a modern website.

And suddenly, your website looks like hundreds of other AI-generated websites.

Blue or purple gradient.

Big hero section.

Rounded cards.

Glassmorphism.

Huge headline.

A glowing CTA button.

Three feature cards.

And some random abstract 3D shapes in the background. 😅

Then you try another AI tool.

Different prompt.

Different project.

Same design.

So...

Why does this happen?

🤖 AI Is Getting Better at Coding, But Something Is Missing

AI can now generate:

React applications
Next.js websites
Dashboards
Landing pages
Mobile interfaces
Complete frontend systems

It can write thousands of lines of code in minutes.

But there's a difference between:

Building a website

and

Designing a unique product experience.

AI is extremely good at the first one.

The second one still needs human judgment.

🎨 Why Does Everything Become Blue and Purple?

Let's say you ask:

"Create a modern, professional SaaS website."

What does "modern" actually mean?

AI has to make a decision.

So it looks at patterns that commonly appear in modern digital products.

And those patterns often include:

Blue
Purple
Gradients
Dark backgrounds
Rounded corners
Minimal typography
Glass effects
Large hero sections

These aren't necessarily bad design choices.

They're simply safe choices.

AI knows these patterns usually look acceptable.

So it uses them again.

And again.

🧠 AI Loves Familiar Patterns

This is probably the biggest reason.

AI learns from enormous amounts of existing information.

That includes:

Websites
Open-source projects
Design systems
UI libraries
Documentation
Product pages
Code repositories
Public design examples

So when you ask for a website, AI doesn't magically invent an entirely new visual language.

It generates something based on patterns it has learned.

It's basically saying:

"I've seen thousands of websites like this. This combination usually works."

And honestly...

It's often right.

That's why the result looks good.

But also familiar.

🧩 The Prompt Makes a Huge Difference

Here's where developers sometimes make the problem worse.

Imagine asking:

"Build a modern landing page for my AI startup."

You'll probably get a very predictable result.

Now compare that with:

"Build a website for a local blood donation platform. The design should feel trustworthy, community-focused, warm, and human. Avoid SaaS-style gradients, glassmorphism, excessive rounded cards, and generic AI illustrations."

Now AI has more direction.

You're not just asking for a website.

You're giving it a design identity.

🚫 "Modern" Is Not a Design System

This is something worth remembering.

Words like:

Modern
Clean
Professional
Premium
Minimal
Beautiful

are extremely vague.

Two designers can interpret "modern" completely differently.

AI has to guess what you mean.

And when AI guesses...

It usually chooses the most common interpretation.

That's where similarity starts.

👨💻 Developers Also Have a Role

It's easy to blame AI.

But developers are part of the problem too.

We often say:

"Make it look like a modern SaaS website."

Then complain:

"Why does AI-generated UI look generic?"

😂

What did we expect?

If you give AI a generic instruction, you'll probably get a generic design.

🎯 Give AI Product Context

Instead of only telling AI what to build, tell it who it's for.

For example:

Don't say:

Build a job portal.

Say:

Build a job portal for fresh graduates who are applying for their first job. The interface should feel encouraging and simple, reduce anxiety, make job information easy to scan, and prioritize mobile users.

Now AI has something meaningful to work with.

It can make better design decisions.

🎨 Tell AI What NOT to Do

This is surprisingly powerful.

You can tell AI:

Don't use purple gradients.

Don't use glassmorphism.

Don't use generic 3D illustrations.

Don't use three identical feature cards.

Don't use oversized hero sections.

Don't make every component rounded.

These constraints force AI away from its default patterns.

Sometimes negative instructions create more originality than adding more instructions.

🧠 Human Taste Still Matters

AI can generate 20 different designs.

But someone still needs to ask:

Which one actually fits the product?

That's where humans matter.

A good designer or developer understands things AI may not know automatically:

Brand personality
Target audience
Cultural context
User emotions
Business goals
Product positioning
What competitors are doing
What should feel different

AI can generate possibilities.

Humans decide what feels right.

🚀 AI Isn't Making Design Worse

This is important.

The problem isn't:

"AI-generated design is bad."

The real problem is:

"AI-generated design is becoming predictable."

And there's a big difference.

AI gives developers an incredible starting point.

You can build a working interface in minutes instead of days.

That's huge.

But if you simply accept the first design AI gives you...

Your product may look like every other AI-built product.

🔥 The Future Might Be Different

I think we're going to see a shift.

Right now, people are excited about:

"AI can build my website."

Soon, the more interesting question will be:

"Can AI understand my product well enough to design something truly unique?"

That's a much harder problem.

Because unique design isn't just about colors and fonts.

It's about understanding context, users, emotions, and purpose.

💡 The Real Skill for Developers

AI is making implementation cheaper.

You don't need to spend hours creating every button or card from scratch.

But that makes another skill more valuable:

Design judgment.

Knowing:

What to keep
What to remove
What feels generic
What fits the brand
What improves usability
What makes the product memorable

That's becoming increasingly important.

🎯 Final Thought

AI can build your website.

AI can choose your colors.

AI can generate your components.

AI can even create the entire frontend.

But if you don't give it a clear identity...

It will probably give you something that already exists in a thousand different forms.

So the next time AI gives you another beautiful purple gradient with rounded cards...

Don't immediately accept it. 😄

Ask yourself:

"Does this actually represent my product, or does it just look like an AI-generated website?"

Because in the age of AI...

Building a website is becoming easier.

Making it feel different is becoming harder.

AI #WebDesign #AIDevelopment #FrontendDevelopment #UIUX #SoftwareEngineering #WebDevelopment #GenerativeAI #Developers #ArtificialIntelligence

CSS Animations for Beginners: Transitions, Keyframes & Transforms

Tue, 11 Aug 2026 05:00:00 +0000

Introduction

CSS animations were the thing that made me actually enjoy frontend development. Building a static layout is satisfying, but the moment something moves smoothly on hover or fades in on load, a project suddenly feels alive.

The good news: you only need three concepts to cover almost every animation you'll want to build — transitions, transforms, and keyframes. Let's go through all three.

1. Transitions — Smoothing Out State Changes

A transition smooths out a property change between two states (like normal and hover).

.button {
  background-color: #3b82f6;
  transition: background-color 0.3s ease;
}

.button:hover {
  background-color: #2563eb;
}

Without transition, the color change would be instant. With it, the color smoothly shifts over 0.3 seconds.

Syntax breakdown: transition: [property] [duration] [easing];

In Tailwind:

<button class="bg-blue-500 hover:bg-blue-600 transition duration-300">

2. Transform — Moving, Scaling, Rotating

transform changes an element's position, size, or rotation without affecting the layout of surrounding elements.

.card {
  transition: transform 0.3s ease;
}

.card:hover {
  transform: translateY(-8px) scale(1.02);
}

This lifts a card slightly and grows it a tiny bit on hover — a very common effect on portfolio sites and product cards.

Common transform values:

translateY(-8px) — moves up
scale(1.05) — grows by 5%
rotate(5deg) — rotates slightly
translateX(20px) — moves right

In Tailwind:

<div class="transition hover:-translate-y-2 hover:scale-105">

3. Keyframes — Multi-Step Animations

Transitions handle two states. @keyframes handles animations with multiple steps, or ones that run automatically without needing a trigger like :hover.

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

.hero-title {
  animation: fadeInUp 0.8s ease-out;
}

This makes an element fade in while sliding up slightly — a very common "page load" effect.

You can also define multiple steps with percentages:

@keyframes pulse {
  0% { transform: scale(1); }
  50% { transform: scale(1.1); }
  100% { transform: scale(1); }
}

.notification-dot {
  animation: pulse 2s infinite;
}

This creates a continuous pulsing effect, useful for notification badges or "live" indicators.

Putting It Together: A Real Example

Here's a button with a hover lift, a smooth color transition, and a subtle entrance animation on page load:

@keyframes fadeIn {
  from { opacity: 0; }
  to { opacity: 1; }
}

.cta-button {
  background-color: #3b82f6;
  transition: all 0.3s ease;
  animation: fadeIn 0.6s ease-in;
}

.cta-button:hover {
  background-color: #2563eb;
  transform: translateY(-4px);
  box-shadow: 0 10px 20px rgba(59, 130, 246, 0.3);
}

This is genuinely how most polished-feeling buttons on real websites are built — nothing exotic, just transitions and transforms combined thoughtfully.

Common Beginner Mistakes

Animating too many properties at once. Subtlety wins — one or two properties changing smoothly looks more professional than five things moving at once.
Using all in transitions carelessly. transition: all 0.3s works, but is slightly less performant than specifying exact properties like transition: transform 0.3s, background-color 0.3s.
Animating width/height/top/left instead of transform. These properties trigger layout recalculation and can feel janky. transform and opacity are GPU-accelerated and much smoother.
Overusing infinite animations. A pulsing badge is fine. A constantly bouncing hero heading gets annoying fast — use continuous animation sparingly.

Final Thoughts

You don't need a JavaScript animation library for most of what makes a website feel polished — smooth hovers, subtle lifts, and clean entrance animations are all achievable with plain CSS. Start by adding a transition to every hover state in your next project and see how much more "finished" it instantly feels.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

How to Build Your First React Component (Step-by-Step)

Fri, 07 Aug 2026 05:00:00 +0000

Introduction

Your first React component doesn't need to be complicated. In fact, the biggest mistake beginners make is trying to build something too ambitious right away and getting stuck on concepts they haven't learned yet.

We're building something practical and genuinely useful: a reusable Testimonial Card component — the kind of thing that shows up in real portfolios and client projects constantly.

Step 1: Understand What a Component Actually Is

A React component is just a JavaScript function that returns some JSX (HTML-like syntax). That's the whole concept.

function Greeting() {
  return <h1>Hello, world!</h1>;
}

You use it like an HTML tag:

<Greeting />

Step 2: Build the Static Version First

Before adding any dynamic data, get the layout right with hardcoded content:

function TestimonialCard() {
  return (
    <div className="bg-slate-800 rounded-2xl p-6 max-w-sm shadow-lg">
      <p className="text-slate-300 mb-4">
        "This developer delivered exactly what we needed, on time and with great communication."
      </p>
      <div className="flex items-center gap-3">
        <div className="w-10 h-10 rounded-full bg-blue-500"></div>
        <div>
          <p className="text-white font-semibold">Sarah Ahmed</p>
          <p className="text-slate-400 text-sm">Product Manager</p>
        </div>
      </div>
    </div>
  );
}

Notice: no state, no props, nothing dynamic. Just structure and styling. This is genuinely how you should approach every new component — get the static layout right first.

Step 3: Make It Reusable with Props

Right now this card only shows one testimonial. Props let you reuse the same component with different data:

function TestimonialCard({ quote, name, role }) {
  return (
    <div className="bg-slate-800 rounded-2xl p-6 max-w-sm shadow-lg">
      <p className="text-slate-300 mb-4">"{quote}"</p>
      <div className="flex items-center gap-3">
        <div className="w-10 h-10 rounded-full bg-blue-500"></div>
        <div>
          <p className="text-white font-semibold">{name}</p>
          <p className="text-slate-400 text-sm">{role}</p>
        </div>
      </div>
    </div>
  );
}

Now you use it like this:

<TestimonialCard
  quote="This developer delivered exactly what we needed, on time."
  name="Sarah Ahmed"
  role="Product Manager"
/>

{ quote, name, role } is destructuring the props object — same as writing props.quote, props.name, props.role, just cleaner.

Step 4: Render a List of Them

In a real project, you'd map over an array of testimonial data:

const testimonials = [
  { quote: "Great work, fast turnaround.", name: "Ali Raza", role: "Founder" },
  { quote: "Clean code and clear communication.", name: "Sarah Ahmed", role: "PM" },
  { quote: "Would hire again without hesitation.", name: "James Lee", role: "CTO" },
];

function TestimonialGrid() {
  return (
    <div className="grid md:grid-cols-3 gap-6 p-6">
      {testimonials.map((item, index) => (
        <TestimonialCard key={index} {...item} />
      ))}
    </div>
  );
}

{...item} spreads the object properties as individual props automatically — a common React pattern once you're comfortable with the basics.

Important: the key prop is required whenever you render a list. React uses it to track which items changed. In a real project, use a unique ID from your data rather than the array index if possible.

Step 5: Add a Bit of Interactivity (Optional)

Want to show a "Read more" toggle for long quotes? That's where useState comes in — covered in detail in Article 5, but here's the quick version:

function TestimonialCard({ quote, name, role }) {
  const [expanded, setExpanded] = useState(false);

  return (
    <div className="bg-slate-800 rounded-2xl p-6 max-w-sm shadow-lg">
      <p className={`text-slate-300 mb-4 ${!expanded && "line-clamp-2"}`}>
        "{quote}"
      </p>
      <button onClick={() => setExpanded(!expanded)} className="text-blue-400 text-sm mb-4">
        {expanded ? "Show less" : "Read more"}
      </button>
      {/* rest of the card */}
    </div>
  );
}

Common Beginner Mistakes

Trying to add state and interactivity before the static layout is right. Get the structure and styling working first — add logic after.
Forgetting the key prop when rendering lists. React will warn you in the console — don't ignore that warning.
Not destructuring props. Writing props.quote everywhere instead of destructuring is more typing and harder to read.
Building one giant component instead of small, focused ones. If a component is doing three different jobs, split it into three components.

Final Thoughts

Building your first real component is less about React "magic" and more about breaking a UI down into small, reusable pieces — static first, then props, then interactivity if needed. Rebuild this same pattern (static → props → list → interactivity) for your next few components and it'll start feeling automatic.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Eight Weeks From Classroom to Production: My Software Engineering Internship Journey

Tue, 04 Aug 2026 10:35:41 +0000

What I learned building a real talent funnel from SRS and Figma to QA, handover, and closing without a perfect ending.

Hey everyone,

If you followed my weekly Hashnode series, you already know the short version: eight weeks, one real product, a lot of shipping, and a quieter finale than I expected.

This post is the longer reflection on the whole arc in one place.

Series link: My Software Engineering Internship Journey

How it started

Week 1 did not feel like “writing production code on day one.” It felt like orientation into a different kind of seriousness.

We were not building toys. We were joining a live talent funnel product, the Talent Funnel, where candidates move through discovery, onboarding, assessments, and interviews, while admins need tools they can trust.

Before the flashy UI work, there was the quieter foundation work: requirements, diagrams, architecture conversations, and learning how classroom theory behaves once real stakeholders and real timelines enter the room.

That first week taught me something I kept rediscovering: industry work is less about knowing everything, and more about becoming useful quickly without breaking what already exists.

The middle: building for real users

Across the middle weeks, the work widened fast.

We moved through:

requirements and data architecture
monorepo structure and type-safe environments
custom auth and onboarding flows
candidate home hubs, assessment surfaces, and UI states
landing pages, hierarchy polish, and painful but necessary rework
admin portals, route hardening, and access control

Some weeks felt like invention. Others felt like correction.

Week 5 especially stuck with me: being right about a UI direction did not always protect the work from being redone. Branch overlap, merge calls, and scope cleanup taught me more than the feature itself. That was uncomfortable. It was also one of the most useful lessons of the internship.

By Weeks 6 and 7, the focus shifted again from “can we build this?” to “can this survive without scaffolding?” We migrated out of temporary paths, cleaned legacy naming, unified branding, hardened staff access, improved analytics and candidate summaries, and started thinking about handover as part of engineering, not as an afterthought.

What the work actually looked like

If I had to name the through-line of my internship, it would be consistency.

Not just visual consistency. Product consistency.

Making routes make sense. Making emails point to real places. Making settings and permissions match how staff actually work. Making responsive layouts behave on phones, not only on laptops. Making localization expose every missing string before a user does. Shipping in related batches instead of one giant pile that nobody can review.

Those details do not always look impressive in a weekly update. They are what make a product feel intentional.

How it ended

Week 8 was the finale: QA, test documentation, and project handover.

As a team, we closed the project. We did not get full client feedback before we wrapped. That is the honest part. Timelines move. Stakeholders are busy. Final reviews do not always land when you hope they will.

Even so, we know they appreciated the work. That appreciation showed up in the collaboration, the trust, and the way the product kept moving forward with us. A long written review would have been nice. Knowing the work mattered still counts.

Closing without a cinematic ending taught me something I did not expect to learn so clearly:

Finishing well is not the same as finishing loudly.

Sometimes a good ending looks like regression checks, documented test cases, known issues written down honestly, and a handover package that lets the next engineers continue without reconstructing the story from commit messages alone.

What I take with me

I leave with more than a portfolio of screens.

I leave with better instincts around:

shipping in related batches
treating documentation as part of delivery
seeing responsive UI, localization, and access control as product integrity, not polish
treating merge conflicts, CI surprises, and overlapping branches as the work itself
measuring progress not only by what I can build, but by whether someone else can continue after me

Somewhere between Week 1 and Week 8, I stopped thinking of an internship as a sequence of tasks. I started seeing it as practice in becoming leaveable, leaving systems, decisions, and context in a state where the team can keep going.

If you are starting your own internship

A few things I would tell my Week 1 self:

Ask for context early. Why a decision exists matters as much as how to implement it.
Expect rework. Being right once does not freeze the product forever.
Write things down while they are still fresh. Future you and future teammates need that.
Care about the unglamorous paths: empty states, mobile, permissions,
broken links.
Learn to close. Shipping is not only starting features. It is also QA, honesty about risk, and handover.

Closing

Internships end. Products keep going.

I am proud of what we built, proud of how we closed, and grateful for the team, mentors, and trust that made the experience real.

If you want the week-by-week story, start here:
My Software Engineering Internship Journey

Thanks for reading.

AI Made Code Review the Bottleneck. Attach the UI to Your PR

Mon, 03 Aug 2026 07:01:36 +0000

You open a frontend pull request. The diff is 400 lines, an AI agent wrote most of it, and the description says "adds the checkout flow". CI is green.

You read the diff. It looks reasonable. You still have no idea what the UI actually does.

So you do what you always do. You pull the branch, install dependencies, start the dev server, and click through the flow yourself.

Ten minutes later you approve the PR.

That ten minutes is the bottleneck now.

AI made writing code dramatically faster. Reviewing frontend behavior did not.

Tests solve part of the problem

Tests already reduce a large part of that uncertainty.

With twd-js, they execute inside a real browser, against the real DOM, with the network mocked so runs stay deterministic. A green run means the entire flow actually executed.

But a green run only tells the reviewer that the assertions passed.

It does not tell them what the user sees.

Was the validation message attached to the correct field?

Did the modal actually close?

Does the empty state look intentional, or does it look broken?

Those are exactly the things reviewers still verify manually, and they are difficult to express as assertions alone.

Put the flow in the pull request

Your tests already drive the application through the exact flow under review.

If reviewers could simply watch that execution, they would not need to pull the branch just to understand the UI.

twd-cli can record the run:

npx twd-cli run --record --test "checkout flow"

That produces:

twd-artifacts/checkout-flow.mp4

Drop the video directly into the pull request description.

The first problem you'll hit

The first time you try this, you discover something unexpected.

The tests finish in about a second.

The recording is technically correct.

It is also almost impossible for a human to follow.

Slowing the video down is the wrong fix

The obvious solution is to stretch the recording afterwards.

A simple ffmpeg filter can do that, but it stretches the same frames across a longer duration. As playback slows down, the effective frame rate drops.

Speed	Duration	Effective FPS
1x	1.00s	30
0.5x	1.90s	15.3
0.25x	3.90s	7.7

At quarter speed, you're watching an 8 FPS video.

It also slows every moment equally. The interesting interactions and the idle time both become longer. The result is not easier to understand. It is simply slower.

This is where architecture matters

Most testing tools record a browser that is being driven from the outside.

The recording is a byproduct of automation, so once execution has finished, post processing is your only option.

TWD works differently.

Its commands execute as JavaScript inside the page itself.

Because TWD owns the command loop, it can control when commands execute, not just how the recording is encoded.

Instead of stretching frames afterwards, it spaces out execution while the test is running.

Frames are still captured at full frame rate.

Pauses happen only after meaningful interactions.

Typing is paced character by character instead of appearing all at once.

That produces a recording that feels natural to watch without sacrificing smoothness.

Which is why recordings are paced by default:

# Default: 300ms pause after each command
npx twd-cli run --record --test "checkout flow"

# Better for demos or stakeholder reviews
npx twd-cli run --record --record-pace 500 --test "checkout flow"

In practice, values between 200ms and 500ms are usually enough to make interactions comfortable to follow while keeping recordings concise.

The result is still a smooth 30 FPS video.

Only the moments that matter become easier to observe.

What the reviewer gets

The reviewer watches the actual flow.

Driven by the actual tests.

Running against the actual application.

Not a screen recording someone remembered to make.

Not a Loom video that becomes outdated after the next commit.

The recording is regenerated every time the tests run.

The review changes from:

"Does this diff look correct?"

to:

"Is this the behavior we actually wanted?"

That is the question worth a human's attention.

The bottleneck moved

Every improvement in software development moves the bottleneck somewhere else.

Today, AI has made writing code significantly faster.

Frontend review is still largely manual because reviewers need to understand behavior, not just source code.

A green checkmark confirms that the tests passed.

It does not show what happened.

Browser based tests can produce something much more valuable than a success badge.

They can produce evidence.

Sometimes, that evidence is a short video that saves every reviewer ten minutes.

npx twd-cli run --record --test "the flow you changed"

If your tests already know how to reproduce the feature, your pull request should show it.

See the Recording Runs documentation for all available options.

A Standard Arithmetic Calculator

Sat, 01 Aug 2026 13:03:10 +0000

It is simple interface on the surface, but a good exercise in building interactive, state-driven user experiences.
For the UI design I got it from the famous https://www.frontendmentor.io

Features include:
🧮 Standard calculator operations
🎨 Three switchable UI themes
📱 Responsive design across screen sizes
⚡ Smooth user interactions with JavaScript

Projects like this are a reminder that even straightforward applications require thoughtful UI design, clean logic, and attention to user experience.

I'd love to hear your thoughts or suggestions

Responsive Design 101: How to Make Any Website Mobile-Friendly

Fri, 31 Jul 2026 05:00:00 +0000

Introduction

The first website I ever built looked great on my laptop and completely broken on my phone. Text overflowing, buttons cut off, images stretched way too big. That's the exact moment "responsive design" stopped being a buzzword and became something I actually had to understand.

Here's the good news: responsive design isn't complicated once you learn a handful of core habits. This article covers exactly those.

Mobile-First: Start Small, Then Grow

The most important mindset shift: design for the smallest screen first, then add complexity as the screen grows — not the other way around.

/* Base styles = mobile */
.container {
  display: flex;
  flex-direction: column;
}

/* Then adjust for larger screens */
@media (min-width: 768px) {
  .container {
    flex-direction: row;
  }
}

In Tailwind, this is built into the framework by default:

<div class="flex flex-col md:flex-row">

No media query needed — flex-col is the mobile default, md:flex-row overrides it on tablets and up.

Understanding Breakpoints

A breakpoint is a screen width where your layout changes. Tailwind's defaults are a solid starting point for almost any project:

(none) — Default styles apply to all screen sizes starting from 0px
(Mobile).
sm: — Applies styles on screens 640px and wider (Large phones).
md: — Applies styles on screens 768px and wider (Tablets).
lg: — Applies styles on screens 1024px and wider (Laptops).
xl: — Applies styles on screens 1280px and wider (Desktops).

You rarely need custom breakpoints — these five cover the vast majority of real devices.

Flexible Units Over Fixed Pixels

Fixed pixel widths break responsive layouts. Use flexible units instead:

% — relative to the parent container
rem — relative to the root font size (better than px for text)
vw / vh — relative to viewport width/height
fr — flexible fraction, used in CSS Grid

/* Breaks on small screens */
.card { width: 400px; }

/* Adapts to any screen */
.card { width: 100%; max-width: 400px; }

That second version is the pattern to remember: set a max-width for large screens, but let it shrink to 100% on smaller ones.

Responsive Images

Images are the #1 cause of layout breakage for beginners. The fix is almost always this:

img {
  max-width: 100%;
  height: auto;
}

In Tailwind:

<img src="photo.jpg" class="max-w-full h-auto" />

This ensures an image never overflows its container, regardless of screen size, while keeping its aspect ratio intact.

Testing Your Responsive Design

Don't just resize your browser window manually — use these instead:

Chrome DevTools Device Mode (Ctrl+Shift+M) — simulates real device sizes, including touch input
Responsively App — tests multiple device sizes side by side, syncing scroll and clicks (covered in Article 1)
Actually open the site on your own phone before calling it done — emulators are close, but not perfect

Common Beginner Mistakes

Designing desktop-first, then trying to "fix" mobile later. Almost always results in more work and more bugs.
Fixed-width containers. width: 1200px will always cause horizontal scrolling on smaller screens. Use max-width instead.
Text that's too small on mobile. 16px is a safe minimum for body text — anything smaller strains readability on phones.
Forgetting touch targets. Buttons and links need enough padding to be tappable with a thumb — 44px height minimum is the common accessibility guideline.

Final Thoughts

Responsive design isn't a separate skill you learn once and forget — it's a habit you build into every single component from day one. Start mobile-first, use flexible units, test on real devices, and most layout bugs simply won't happen in the first place.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

Understanding React Hooks: useState and useEffect Explained Simply

Tue, 28 Jul 2026 05:00:00 +0000

Introduction

Hooks confused me for longer than I'd like to admit. Not the syntax — the syntax is simple. What confused me was when to use useEffect versus just writing normal logic in my component.

If you're at that stage right now, this article is for you. We're keeping this practical — real examples, real mistakes, no theory-heavy explanations of React's internal fiber architecture.

useState: Giving Your Component Memory

Without state, a component renders once and forgets everything. useState lets a component remember values between renders — and re-render automatically when that value changes.

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increase</button>
    </div>
  );
}

count is the current value. setCount is the function you call to update it. Calling setCount tells React "re-render this component with the new value" — you never update count directly.

Common Mistake: Updating State Based on Old State

This looks fine but can cause bugs:

setCount(count + 1);
setCount(count + 1); // still only adds 1, not 2!

Fix it with the function form:

setCount(prev => prev + 1);
setCount(prev => prev + 1); // now correctly adds 2

This matters more than it seems — always use the function form when your new state depends on the previous state.

useEffect: Running Code at the Right Time

useEffect lets you run code in response to a component rendering, or a specific value changing — things like fetching data, updating the page title, or setting up an event listener.

import { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`https://api.example.com/users/${userId}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }, [userId]);

  if (!user) return <p>Loading...</p>;
  return <h2>{user.name}</h2>;
}

The array at the end — [userId] — is the dependency array. It tells React "only re-run this effect when userId changes."

The Three Dependency Array Patterns

useEffect(() => { /* code */ });          // runs after EVERY render
useEffect(() => { /* code */ }, []);       // runs ONCE, after the first render
useEffect(() => { /* code */ }, [userId]); // runs when userId changes

Beginners almost always want one of the last two. An empty array [] is for one-time setup (like fetching initial data). A populated array is for "re-run this when X changes."

Cleaning Up After Effects

Some effects need cleanup — like removing an event listener when the component unmounts:

useEffect(() => {
  const handleResize = () => console.log(window.innerWidth);
  window.addEventListener('resize', handleResize);

  return () => {
    window.removeEventListener('resize', handleResize);
  };
}, []);

The function you return inside useEffect is the cleanup function. React calls it automatically before the component unmounts, or before the effect runs again.

Common Beginner Mistakes

Forgetting the dependency array entirely. This causes the effect to run after every single render, often triggering infinite fetch loops.
Missing a dependency. If your effect uses a variable from outside it, add it to the array — ESLint's react-hooks/exhaustive-deps rule will warn you about this.
Putting everything in useEffect. Not all logic needs to live in an effect. If you're just calculating a value from props or state, do it directly in the component body — no hook needed.

Final Thoughts

useState gives your component memory. useEffect lets it react to changes and the outside world (APIs, timers, event listeners). Once you separate those two jobs clearly in your head, hooks stop feeling mysterious.

Try rebuilding a small feature — a search box with an API call, for example — using exactly these two hooks. That's usually the exercise that makes it click.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

10 VS Code Extensions Every Frontend Developer Needs

Fri, 24 Jul 2026 05:00:00 +0000

Introduction

I used to install every extension that looked interesting — ended up with 40+ extensions and a VS Code that took 10 seconds just to open. Eventually I stripped it back down to the ones I actually use every single day.

These 10 are the ones that survived that cleanup. If you're setting up a fresh frontend dev environment, start here.

1. ESLint

Catches bugs and enforces consistent code style before you even run your code. If you're working in a team (or want to look like you know what you're doing), this is non-negotiable.

2. Prettier — Code Formatter

Auto-formats your code on save. No more arguing about tabs vs. spaces or where semicolons go — Prettier just decides and moves on.

Setup tip: Enable "Format on Save" in VS Code settings so it happens automatically.

3. Tailwind CSS IntelliSense

If you're using Tailwind (and you should be, per Article 3), this gives you autocomplete for class names, shows the actual CSS values on hover, and even highlights conflicting classes.

4. Auto Rename Tag

Rename an opening HTML/JSX tag and the closing tag updates automatically. Small thing, saves real time, especially in nested JSX.

5. Bracket Pair Colorizer (Built-in now)

VS Code now has this built in by default — matching brackets get color-coded so you can actually see which { belongs to which } in deeply nested code. Just make sure it's enabled in settings.

6. GitLens

Shows you who changed a line of code and when, right inline in the editor. Incredibly useful once you're working with any kind of version history — even solo projects benefit from seeing your own commit history at a glance.

7. Live Server

Spins up a local development server with live reload in one click — no need to manually refresh the browser every time you save a file. Especially useful for plain HTML/CSS/JS projects without a build tool.

8. Thunder Client

A lightweight REST API client built directly into VS Code. If you're testing an API endpoint for a project, you don't need to leave your editor or open Postman separately.

9. Error Lens

Shows error and warning messages inline, right next to the line of code causing the problem, instead of making you check the Problems panel. Cuts down debugging time noticeably.

10. Material Icon Theme

Purely visual, but genuinely useful — gives every file type a distinct, recognizable icon in your file explorer. Makes navigating a large project noticeably faster once your eyes learn the icon shapes.

How to Install Any of These

Open VS Code
Click the Extensions icon in the sidebar (or Ctrl+Shift+X)
Search the extension name
Click Install

That's it — no restart usually needed.

Final Thoughts

You don't need 40 extensions to be productive — you need the right 8 to 10. Install these, use them for a week, and you'll notice fewer small annoyances and less time spent on formatting, tag matching, and manual browser refreshing.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

Hire Me: Muhammad Farhan — Frontend Developer Available for Remote Work

Thu, 23 Jul 2026 09:31:37 +0000

Hi, I'm Muhammad Farhan

I'm a frontend developer based in Dera Ismail Khan, Pakistan, and I build clean, modern, fast-loading websites using React.js, Tailwind CSS, and WordPress. If you need a website built, a design turned into working code, or an existing site improved, I'd genuinely like to help — and I'm available to start right away.

What I Actually Do

I specialize in:

React.js — component-based, interactive web apps built to scale
Tailwind CSS — clean, modern, fully responsive UI, my go-to styling approach
HTML5 & CSS3 — solid, semantic, accessible markup underneath every project
JavaScript (ES6+) — smooth interactivity, no clunky or broken UI
Bootstrap — for projects that need it, including maintaining older sites
WordPress — theme customization, blog setup, and full client websites, including custom frontend features layered on top

Real Work, Not Just Promises

UX Gazette — a professional blog website I built for a real client on WordPress, live at uxgazette.com
Personal Portfolio — my own site, showcasing my design and development work
Multiple additional projects across business landing pages, animated websites, and UI design work

I don't just talk about being able to build things — every skill listed above has a real, live, shipped project behind it that you can actually visit and click through.

Why Work With Me

I communicate clearly and respond fast. No chasing me for updates — I keep you informed without being asked.
I care about clean, maintainable code, not just something that looks right on the surface and breaks the moment it needs a change.
I'm affordable for the quality I deliver, especially compared to larger agencies, while still meeting professional standards.
I'm available now — for a single project, an ongoing freelance arrangement, or a part-time/remote role.

What I Can Help You With

Building a new website from scratch (business site, portfolio, landing page)
Converting a Figma or Adobe XD design into a fully working, responsive website
Fixing bugs or improving performance on an existing site
Customizing or maintaining a WordPress site
Building custom tools, dashboards, or interactive features with React

Let's Talk About Your Project

If you have a project in mind — big or small — I'd love to hear about it. Reach out directly using any of the details below, and I'll get back to you quickly.

Email: Emails are not allowed
Phone / WhatsApp: +92 335-4051272
Portfolio: Click Here
GitHub: Click Here
Behance: Click Here
Instagram: Click Here
X (Twitter): Click Here
WhatsApp Channel: Click Here

Feel free to message me directly on WhatsApp for the fastest response — I usually reply within a few hours.

Muhammad Farhan — Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.

Tailwind CSS for Beginners: From Zero to Your First Component

Tue, 21 Jul 2026 05:00:00 +0000

Introduction

The first time I saw a Tailwind CSS class list — something like flex items-center justify-between p-4 bg-slate-800 rounded-lg shadow-md — I genuinely thought it looked messy. Why not just write regular CSS?

Then I actually used it on a real project, and within a week I understood why so many developers (myself included now) switched permanently. You stop context-switching between HTML and a separate CSS file, you stop naming classes like .card-wrapper-inner-2, and you build UI noticeably faster.

This is the guide I wish I had when I started.

What Tailwind CSS Actually Is

Tailwind is a utility-first CSS framework. Instead of writing custom CSS classes, you compose your design directly in your HTML using small, single-purpose utility classes.

Regular CSS:

.button {
  padding: 8px 16px;
  background-color: #3b82f6;
  border-radius: 8px;
  color: white;
}

Tailwind:

<button class="px-4 py-2 bg-blue-500 rounded-lg text-white">
  Click Me
</button>

Same result. No separate CSS file needed for this button.

Setting It Up (React + Vite)

npm create vite@latest my-app -- --template react
cd my-app
npm install tailwindcss @tailwindcss/vite

In vite.config.js:

import tailwindcss from '@tailwindcss/vite'

export default {
  plugins: [tailwindcss()],
}

In your main CSS file:

@import "tailwindcss";

That's it — no separate config file required for modern Tailwind setups. Restart your dev server and you're ready to use utility classes anywhere.

Core Concepts You Need to Know

1. Spacing

p-4 = padding on all sides, px-4 = horizontal padding only, py-4 = vertical only, m-4 = margin. The number is a spacing scale (4 = 1rem = 16px).

2. Flexbox & Grid utilities

flex, items-center, justify-between, grid, grid-cols-3, gap-4 — everything from the Flexbox/Grid article, just as classes.

3. Responsive Design

Prefix any class with a breakpoint: md:flex-row means "apply this on medium screens and up."

<div class="flex flex-col md:flex-row gap-4">

This stacks items vertically on mobile, then switches to a row on tablets and larger.

4. Hover & State Variants

<button class="bg-blue-500 hover:bg-blue-600 transition">

hover: applies only on hover. Same pattern works for focus:, active:, disabled:.

Building Your First Component: A Pricing Card

<div class="max-w-sm mx-auto bg-slate-800 rounded-2xl p-6 shadow-lg">
  <h3 class="text-xl font-bold text-white mb-2">Starter Plan</h3>
  <p class="text-slate-400 mb-4">Perfect for small projects</p>
  <p class="text-3xl font-bold text-white mb-6">$9<span class="text-base font-normal text-slate-400">/mo</span></p>
  <button class="w-full py-2 bg-blue-500 hover:bg-blue-600 rounded-lg text-white font-medium transition">
    Get Started
  </button>
</div>

Notice what's happening: max-w-sm mx-auto centers and constrains the card width, rounded-2xl and shadow-lg give it depth, and everything is readable directly from the class names — no jumping to a separate file to understand the styling.

Common Beginner Mistakes

Fighting the spacing scale. Don't reach for custom pixel values
immediately — Tailwind's default scale (4, 8, 12, 16...) covers 95%
of real use cases.
Not using @apply for repeated patterns. If you're copy-pasting the
same 8 classes everywhere, extract them into a component instead of
a CSS class — that's the React way to do it, not @apply.
Ignoring the official docs. Tailwind's docs (tailwindcss.com) are
genuinely excellent — searchable, example-driven, and the fastest
way to find the exact class you need.

Final Thoughts

Tailwind feels weird for about a week, then it feels like the only sane way to write CSS. The speed difference is real — I build UI noticeably faster now than when I wrote custom CSS files for every component.

Start small: rebuild one existing component using Tailwind instead of your old CSS, and see how it feels.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

CSS Flexbox vs Grid: When to Use Which (Beginner's Guide)

Fri, 17 Jul 2026 05:00:00 +0000

Introduction

Every beginner hits this wall eventually: "Do I use Flexbox or Grid here?"

I remember avoiding this question for months by just using Flexbox for everything — including things Grid was clearly built for. It worked, technically, but I was fighting the tool instead of using the right one.

Here's the short version before we go deep: Flexbox is for one direction (a row or a column). Grid is for two directions at once (rows AND columns together). Once that clicks, the decision gets easy.

Let's break it down properly.

What Flexbox Actually Does

Flexbox arranges items along a single axis — either horizontally or vertically.

.container {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

justify-content controls spacing along the main axis (usually horizontal), and align-items controls alignment on the cross axis (usually vertical).

Flexbox is perfect for:

Navigation bars (logo left, links right)
Buttons sitting side by side
Centering a single element vertically and horizontally
Card content where items need to stretch or wrap in one direction

What Grid Actually Does

Grid lets you define rows and columns at the same time, and place items precisely into that structure.

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 20px;
}

This creates 3 equal-width columns with 20px gaps — no media queries needed to get a basic responsive layout going.

Grid is perfect for:

Full page layouts (header, sidebar, main content, footer)
Image galleries
Card grids (like a blog listing page)
Anything where you're thinking in rows AND columns

The Real Test: Ask Yourself This

"Am I arranging things in one line, or am I building a layout?"

One line → Flexbox
Layout/grid of items → Grid

A Practical Example: Building a Card Grid

Here's a common beginner project — a responsive grid of cards, done the right way with Grid:

<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
  <div class="bg-slate-800 p-4 rounded-lg">Card 1</div>
  <div class="bg-slate-800 p-4 rounded-lg">Card 2</div>
  <div class="bg-slate-800 p-4 rounded-lg">Card 3</div>
</div>

(That's Tailwind CSS classes, but it maps directly to Grid under the hood — grid, grid-cols-3, gap-6.)

Now, inside each card, if you need to align an icon next to a title, or push a button to the bottom of the card — that's Flexbox's job:

<div class="bg-slate-800 p-4 rounded-lg flex flex-col justify-between">
  <div class="flex items-center gap-2">
    <span>🔥</span>
    <h3>Card Title</h3>
  </div>
  <button>Learn More</button>
</div>

This is the pattern you'll use constantly: Grid for the outer layout, Flexbox for the inner content.

Common Beginner Mistakes

Using Grid for a simple navbar. Overkill — Flexbox does this in 3
lines.
Using Flexbox for a full page layout. You'll end up wrapping and
fighting widths that Grid handles natively.
Not using gap. Both Flexbox and Grid support gap now — no more
margin hacks between items.
Forgetting Grid can do more than equal columns.
grid-template-columns: 200px 1fr gives you a fixed sidebar +
flexible main content in one line.

Final Thoughts

You don't have to pick one and stick with it forever — most real websites use both together, Grid for structure and Flexbox for alignment inside components. Once you stop treating this as an either/or decision and start asking "one direction or two?", it stops being confusing.

Try rebuilding one of your old projects using this rule and see how much cleaner the CSS gets.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

15 Free Frontend Tools Every Developer Should Know in 2026

Tue, 14 Jul 2026 06:38:30 +0000

Introduction

When I started learning frontend development, I thought I needed expensive software to build things that looked "professional." Turns out, that's completely false.

Some of the best frontend tools out there are free — and a lot of developers, even experienced ones, don't know half of them exist. Whether you're picking colors, generating CSS animations, testing responsiveness, or just trying to find the right icon, there's a free tool for almost everything.

In this post, I'm sharing 15 tools I personally use (or have used) while building real projects — from client websites to personal portfolios. No fluff, no "100 tools you'll never open" lists. Just the ones that actually save time.

Let's get into it.

1. Design & Color Tools

Good design starts with good colors and layout inspiration. These tools take the guesswork out of it.

Coolors

Coolors is the fastest way to generate a color palette. Hit the spacebar and it keeps generating combinations until you find one you like. You can lock colors you love and regenerate the rest.

Why beginners love it: No design theory needed — just pick what looks good.
🔗 coolors.co

Adobe Color

More advanced than Coolors, this lets you build palettes based on color theory rules (complementary, triadic, monochromatic, etc.) and even extract a palette from an image.

Why it's useful: Great when you want a palette that matches a client's brand photo or logo.
🔗 color.adobe.com

2. CSS Generators (Stop Writing Gradients by Hand)

CSS Gradient

Pick colors, choose the direction, and copy the ready-made CSS. Simple, fast, and works for linear and radial gradients.
🔗 cssgradient.io

Neumorphism.io

If you want that soft, "pressed-in" neumorphic UI style, this generator gives you the exact box-shadow code — adjustable by distance, blur, and intensity, with light/dark background support.
🔗 neumorphism.io

Clippy

Need a custom shape (hexagon, arrow, triangle) using clip-path? Clippy lets you drag points visually and copies the CSS for you. No more guessing polygon coordinates.
🔗 bennettfeely.com/clippy

Pro tip: These generators are amazing for learning too — generate the code, then read it and understand why it works. That's how I actually learned box-shadow and clip-path properties.

3. Icons That Don't Look Generic

Lucide Icons

A clean, consistent icon set that works beautifully with React and Tailwind CSS. Lightweight, tree-shakable, and has an official React package (lucide-react).
🔗 lucide.dev

Heroicons

Made by the Tailwind CSS team, so naturally it pairs perfectly with Tailwind projects. Comes in outline and solid styles.
🔗 heroicons.com

Font Awesome (Free Tier)

The classic. Massive icon library, and the free tier alone covers most needs — social icons, UI icons, brand logos.
🔗 fontawesome.com

My pick for React + Tailwind projects: Lucide. It's the one I use across my own builds because it's lightweight and easy to customize with Tailwind classes.

4. Fonts & Typography

Google Fonts

The obvious one, but don't just grab the first font you see. Google Fonts also shows you popularity, styles, and lets you preview your own text before choosing.
🔗 fonts.google.com

Fontjoy

Struggling to pair a heading font with a body font? Fontjoy uses AI to suggest font combinations that actually work together — and you can lock one font and regenerate the other.
🔗 fontjoy.com

5. Online Code Playgrounds

CodePen

Great for quick CSS/JS experiments, sharing snippets, and browsing what other developers are building. Perfect for testing an animation idea before adding it to a real project.
🔗 codepen.io

StackBlitz

A full online IDE that runs actual React, Vue, or Node projects in your browser — no local setup needed. I use this a lot when testing a quick React component idea.
🔗 stackblitz.com

CodeSandbox

Similar to StackBlitz, with strong support for sharing full working React apps and instant deployment previews. Great for collaborating or showing a client a live demo without deploying anywhere.
🔗 codesandbox.io

6. Image Optimization Tools

Heavy images kill website speed — and speed affects both user experience and SEO rankings.

Squoosh

Made by Google. Drag in an image, compare compression formats (WebP, AVIF, JPEG) side by side, and download the optimized version — all in your browser, nothing uploaded to a server.
🔗 squoosh.app

TinyPNG

Bulk compress PNG and JPEG images with barely noticeable quality loss. I run every client project's images through this before deployment.
🔗 tinypng.com

7. Responsive & Accessibility Testing

Responsively App

A free desktop app that shows your website on multiple device sizes at once, side by side, and syncs scrolling and clicks across all of them. Saves so much time compared to resizing your browser manually.
🔗 responsively.app

Chrome DevTools (Lighthouse)

Built right into Chrome. Open DevTools → Lighthouse tab → run an audit. It scores your site on performance, accessibility, best practices, and SEO, and tells you exactly what to fix.

Why this matters for freelancers: Clients love seeing a 90+ Lighthouse score. It's an easy way to prove your work is solid.

WAVE

A free accessibility checker. Paste your URL and it visually flags missing alt text, low contrast, and other accessibility issues directly on the page.
🔗 wave.webaim.org

8. Reference & Learning

MDN Web Docs

The single most reliable source for HTML, CSS, and JavaScript documentation. When in doubt, check MDN before trusting a random blog post (including this one).
🔗 developer.mozilla.org

Can I Use

Before using a newer CSS or JS feature, check browser support here. Saves you from shipping something that breaks in Safari or older browsers.
🔗 caniuse.com

Final Thoughts

You don't need a paid design subscription or premium plugin to build clean, professional websites. The tools above cover almost every stage of frontend work — design, coding, testing, and optimization — and they're all free.

My honest advice as someone who's been learning and building for the past couple of years: don't try to learn all 15 tools at once. Pick 2–3 that solve a problem you're facing right now, use them in your next project, and the rest will come naturally as you build more.

If you found this useful, save it — you'll probably come back to this list more than once.

Written by Muhammad Farhan — Frontend Developer specializing in React.js & Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev
GitHub: github.com/muhammad-farhan-dev

Why Every Frontend Project Should Have Its Own UI Layer

Wed, 20 May 2026 11:48:03 +0000

Modern frontend development is heavily centered around component frameworks: Vue, React, Svelte, Solid, Angular, and others. The ecosystem also provides endless UI libraries: Vuetify, PrimeVue, Naive UI, MUI, Ant Design, Chakra, Radix, Headless UI, shadcn/ui, and hundreds more.

Most teams directly import these libraries into application code.

I think that is a long-term architectural mistake.

Every serious frontend project should have its own internal UI layer — its own component system — even if internally it relies almost entirely on third-party libraries.

Not because reinventing buttons is fun.
Because abstraction boundaries matter.

The Problem With Directly Using UI Libraries

Direct usage tightly couples the application to external implementation details.

You start with something simple:

<ElButton type="primary" size="small">
    Save
</ElButton>

A year later:

the library changes APIs,
design requirements evolve,
accessibility requirements appear,
dark theme becomes mandatory,
SSR breaks,
bundle size becomes a problem,
a component becomes abandoned,
or the team simply wants another UI system.

Now the entire codebase depends on thousands of scattered library-specific decisions.

The UI library stops being a dependency.

It becomes infrastructure.

Your UI Layer Is An Architectural Boundary

Instead of using third-party components directly, create your own application-level components:

<AppButton>
<AppInput>
<AppDialog>
<AppTable>
<AppDatePicker>
<AppPageLayout>
<AppEntityEditor>

Internally, these components may use:

PrimeVue
Vuetify
Radix
native browser APIs
custom rendering
or completely different implementations

The application itself should not care.

This creates a stable internal contract between the product and external dependencies.

The application talks to your UI architecture.

Your architecture talks to vendor libraries.

Wrappers Are Not "Extra Boilerplate"

A common objection:

"Why wrap everything? That's just unnecessary abstraction."

It is not abstraction for abstraction's sake.

It is containment.

The wrapper layer centralizes:

naming conventions,
defaults,
accessibility,
theme propagation,
behavior normalization,
analytics hooks,
keyboard handling,
validation,
localization,
performance workarounds,
SSR compatibility,
browser quirks,
and migration strategy.

Without wrappers, all of this leaks into product code.

Then every page becomes infrastructure code.

The Biggest Advantage: Replaceability

This is the most important benefit.

When UI libraries are hidden behind your own components, replacing them becomes feasible.

Example:

<AppDatePicker>

Today internally:

PrimeVue DatePicker

Tomorrow:

Flatpickr

Or:

Native browser date input

Or:

Custom implementation

The application code remains unchanged.

This matters more than most teams realize.

UI ecosystems move extremely fast. Libraries become abandoned surprisingly often.

A thin internal UI layer dramatically reduces migration cost.

Mixing Multiple UI Libraries Becomes Safe

Direct usage of multiple UI systems usually creates chaos.

Different:

design languages,
spacing systems,
keyboard behavior,
focus handling,
overlay logic,
animation systems,
theming models,
and accessibility semantics.

But with an internal UI layer, multiple libraries can coexist safely.

Example:

one library provides excellent tables,
another has better dialogs,
another has superior date pickers,
another has accessible comboboxes.

Your application never sees this complexity directly.

Your wrapper layer normalizes it.

This is extremely powerful.

Your UI Layer Is Also A Design System

The important shift:

Your design system should not belong to the UI vendor.

It should belong to the product.

That means:

your naming,
your semantics,
your defaults,
your UX patterns,
your layout philosophy,
your interaction rules.

Not whatever the library authors decided.

Example:

<AppDangerButton />

is far more meaningful than:

<ElButton type="danger" plain />

The first expresses product semantics.

The second expresses vendor implementation details.

That distinction becomes critical at scale.

Default Configuration Reduces Massive Verbosity

One underrated benefit of internal wrappers:

They eliminate repetitive configuration.

Without wrappers:

<ThirdPartyInput
    size="small"
    variant="filled"
    density="compact"
    clearable
    rounded
    theme="dark"
/>

Repeated hundreds or thousands of times.

With wrappers:

<AppInput />

The wrapper already encodes:

project defaults,
theme defaults,
accessibility defaults,
density rules,
validation behavior,
localization behavior,
analytics integration,
focus handling.

This massively reduces UI noise in application code.

The application becomes more declarative.

Theme Propagation Becomes Centralized

Third-party UI libraries usually bring their own theme systems.

That becomes problematic when multiple libraries coexist.

Each library wants:

its own tokens,
its own variables,
its own dark mode implementation,
its own color system.

Your internal UI layer solves this.

The application owns the real design tokens:

:root {
    --color-bg: #ffffff;
    --color-text: #111111;
    --color-primary: #3b82f6;
}

Then wrapper components propagate these tokens into underlying libraries.

Your product controls the visual system.

Libraries adapt to you, not the other way around.

This is one of the cleanest ways to support:

dark mode,
white-labeling,
custom themes,
enterprise branding,
runtime theme switching.

Modern Browser APIs Make Custom UI More Realistic

Five years ago, fully custom UI infrastructure was expensive.

Today browsers provide much better primitives.

Examples:

<dialog>
Popover API
anchor positioning
:has()
CSS nesting
container queries
inert
view transitions
modern focus management
top-layer behavior

Especially important are the newer overlay-related APIs.

Historically, dialogs, dropdowns, popovers, tooltips, and context menus were extremely difficult because of:

z-index wars,
focus traps,
scroll locking,
portal systems,
positioning,
stacking contexts.

Modern browser primitives increasingly solve these problems natively.

This changes the economics of UI architecture.

Building internal abstractions is becoming cheaper and more maintainable.

UI Architecture Is More Than Form Controls

Many teams think only about atomic components:

buttons,
inputs,
selects,
checkboxes.

But the real value appears higher in the hierarchy.

Your internal UI layer can orchestrate:

page layouts,
entity editors,
filter panels,
data tables,
toolbar systems,
sidebars,
navigation structures,
CRUD workflows,
master-detail layouts,
save/cancel flows,
loading orchestration,
permissions handling.

Example:

<EntityPage>
    <EntityToolbar />
    <EntityFilters />
    <EntityTable />
</EntityPage>

Now your product develops consistent workflow patterns.

Not just reusable buttons.

This is where frontend architecture starts becoming a platform.

Internal UI Layers Improve Long-Term Stability

Projects live longer than frontend trends.

The average enterprise frontend outlives:

multiple framework trends,
multiple design trends,
multiple UI libraries,
and sometimes even multiple frontend teams.

A dedicated UI layer creates isolation from ecosystem volatility.

It reduces the blast radius of change.

That is not premature abstraction.

That is operational risk management.

This Applies Beyond Vue

Vue examples are convenient because Vue component composition is extremely ergonomic.

But the idea is framework-agnostic.

The same architecture works in:

React
Svelte
Angular
Solid
Web Components
even server-rendered systems

Any component-based frontend benefits from stable internal UI contracts.

A Practical Rule

One of the first architectural tasks in a frontend project should be:

Define the project's internal UI hierarchy before building product pages.

Not after.

Not during migration.

Not after technical debt accumulates.

At the beginning.

Because once product code directly depends on third-party UI libraries, decoupling becomes expensive.

Potential Downsides

This approach is not free.

Possible drawbacks:

initial setup cost,
additional maintenance,
risk of over-abstraction,
wrapper drift from underlying libraries,
documentation burden,
onboarding complexity,
temptation to reinvent mature solutions.

Poorly designed wrappers can absolutely become worse than direct usage.

The goal is not to hide everything.

The goal is to own the architectural boundary.

Final Thought

Frontend developers often discuss frameworks.

But frameworks are transient.

Architecture lasts much longer.

A frontend codebase should not structurally depend on the internal API decisions of a third-party UI vendor.

It should depend on its own UI language.

That language becomes one of the most valuable assets in the entire frontend architecture.

What additional advantages or disadvantages have you seen with internal UI layers and wrapper-based component systems?

Why Your Backend, Frontend, and Database “Don’t Talk”

Fri, 17 Apr 2026 11:13:45 +0000

I expected my first ever full-stack project to end with a sense of completion. my plan was to build the frontend, set up the backend, connect a database, then watch everything come together into a finished product.

Instead, I ran into something far more frustrating than your average bug: nothing was connected properly, and i had no idea why. The strangest part was that, on the surface, everything looked completely fine. The frontend loaded without issues, the backend server ran, and the database connection didn’t show any errors, nothing was fundamentally wrong. But the moment I tried to use the system as a whole, everything collapsed in a way that didn’t make sense at fisrt.

Requests didn’t behave correctly, data didn’t flow properly between layers, and responses that I did manage to recieve didn’t match what I was expecting at all. It felt less like a broken program, and more like 3 separate systems pretending to. be connected, but never actually communicating in any meaningful way.

Naturally, I fell into what i now call the debugging spiral. I started guessing, checking to see if the frontend was sending the right requests. When I failed to find anything, i moved to the backend routes, assuming something wasn’t being handled correctly. I went back and forth, checking the database connections, back to the front end, repeating the same cycle slightly differently each time.

But there was no single obvious error that I could fix. And this was where the real frustration came in, because debugging becomes almost disorientating when you have nothing concrete to grasp onto. You move endlessly between parts of the system, hoping if you look at it from a slightly different angle, something will eventually look wrong. But everything remains to appear technically correct, and the system remains to behave incorrectly.

The real issue, which I didn’t realise at the time, was that I was treating the app as separate components instead of a single, connected system. In my head, the frontend was one thing, the backend was another, and the database was another independent piece. So, I assumed debugging meant finding which one of them was broken and fixing it in isolation. But, when dealing with full-stack systems, things don’t usually fail in a clean, isolated way. They fail in the spaces between components, the communication layers that tie everything together. But at that point in my learning, I didn’t really understand those connections properly, and understand how fragile they really are.

What I eventually started to realise is that ‘connection’ in full-stack development isn’t just an abstract idea that magically links everything together. It consists of a series of very explicit interactions that all have t line up perfectly for a system to work.

You define routes on the backend that expect specific requests, which you have to send from the frontend in a particular format. The data has to be structured using formats like JSON so both sides can understand each other. You handle responses manually and then update the UI based off of that data. If even one of these steps fails, the system doesn’t only partially fail, or break a little bit, it quietly stops behaving in the way you would expect, without always sowing you a clear error message explaining why.

That is part of what made the whole experience so confusing. The most deceptive part for me wasn’t that things were breaking, it was that everything looked like it was working. No console errors were being logged, no visible crashes, which lead me to a dangerous assumption: if nothing is visibly wrong, then everything must be fine. But when dealing with full-stack development, that assumption falls apart incredibly quickly.

You can have a system that is completely broken in terms of logic and data flow, while showing no obvious signs of failure in wither the logs or the interface. The system doesn’t always announce it’s problems, it expects you to connect the dots yourself.

Looking back, the real lesson I learnt wasn’t about fixing one specific bug in my code. It was about changing how I think about a system as a whole. I spent hours looking for broken parts, when I should’ve been looking for broken communication instead. And that difference matters more than I realised at the time, because debugging isn’t all about understanding individual components, you have to also understand how those components interact with one another, and where that interaction has the possibility of falling apart.

My project didn’t fail because I wrote bad code, it failed because I failed to understand that debugging a system is a completely different skill to debugging a single piece of code.

Exploring the power of 3D experiences on the web

Sun, 15 Mar 2026 12:29:25 +0000

This is an experimental 3D sports landing page built with modern frontend technologies. The goal was to create a more immersive and interactive experience compared to traditional flat landing pages.
Inspired by a great tutorial from JS Mastery, I built this 3D Basketball Landing Page as a creative frontend experiment.

Tech stack
• Three.js – for rendering interactive 3D scenes
• GSAP – for smooth, high-performance animations
• Next.js – for modern React architecture and performance

Three.js allows developers to render interactive 3D graphics directly in the browser using WebGL, enabling immersive web experiences and real-time animations.

The page combines 3D elements, animated transitions, and camera movement to make the interface feel more alive and interactive.

The idea was to move beyond static layouts and create a landing page where motion, depth, and interactivity become part of the user experience.

I also used AI tools during development to speed up experimentation and explore different creative approaches.

Live project:
https://3d-basketball-template.vercel.app/

Exploring the power of 3D experiences on the modern web

Sun, 15 Mar 2026 12:28:47 +0000

Tech stack
• Three.js – for rendering interactive 3D scenes
• GSAP – for smooth, high-performance animations
• Next.js – for modern React architecture and performance

Three.js allows developers to render interactive 3D graphics directly in the browser using WebGL, enabling immersive web experiences and real-time animations.

The page combines 3D elements, animated transitions, and camera movement to make the interface feel more alive and interactive.

The idea was to move beyond static layouts and create a landing page where motion, depth, and interactivity become part of the user experience.

I also used AI tools during development to speed up experimentation and explore different creative approaches.

Live project:
https://3d-basketball-template.vercel.app/

Boosting Frontend Productivity with Large Language Models

Mon, 16 Feb 2026 15:35:31 +0000

Large Language Models (LLMs) such as GPT are starting to reshape how frontend developers build, debug, and deliver applications. They are no longer just tools for chatbots or natural language processing—they are becoming development assistants that reduce repetitive work, accelerate prototyping, and even power features inside modern web applications.

In this post, we’ll explore how LLMs can be applied to different areas of frontend development, from scaffolding and debugging to prototyping and integration.
Scaffolding and Boilerplate Generation

One of the most time-consuming aspects of frontend work is setting up repetitive structures. Developers often spend hours creating responsive navigation bars, authentication forms, or reusable UI components. With an LLM, these tasks can be simplified dramatically.

By describing what you need in natural language, you can instantly generate starting points for React, Vue, or Angular components. For example, a simple prompt like “Create a responsive React navbar with Tailwind CSS, including a dropdown and dark mode toggle” can produce a functional scaffold in seconds. The generated code won’t be perfect, but it provides a strong foundation that can be refined and customized.
Debugging and Refactoring

LLMs can also function as on-demand code reviewers. Instead of searching through documentation or debugging forums, you can paste your code into a model and ask for help. Models are particularly effective at identifying common mistakes in state management, suggesting optimizations, and even refactoring legacy code into modern frameworks.

Imagine a scenario where a Vue watch function isn’t firing as expected. Instead of spending an hour troubleshooting, you could simply ask an LLM, “Why isn’t this watch function firing, and how can I fix it?” In many cases, the model will highlight the issue and provide a working alternative.
Prototyping for UI and UX

Frontend development is about speed and iteration, and this is where LLMs excel. They allow developers to quickly experiment with variations of UI components, test accessibility improvements, and even convert text-based requirements into functional wireframes.

Combined with design tools like Figma, LLMs can bridge the gap between design and implementation. This means teams can move from concept to code faster, while still keeping accessibility and best practices in mind.
Documentation and Learning

Good documentation is often an afterthought, yet it is essential for maintainable projects. LLMs make it easier to generate clear explanations for complex logic, produce onboarding notes for new developers, and even create project README files.

For example, by asking a model to “Explain what this custom React hook does in plain English,” you can transform intricate code into developer-friendly documentation that can be immediately reused. This not only saves time but also improves team communication.
Embedding LLMs in Frontend Applications

LLMs are not only useful during development they can also become part of the product itself. Modern web applications are increasingly embedding AI-powered features to enhance user experience.

This can include smart search bars that understand user intent, chat assistants for customer support, AI-generated content such as product descriptions, or personalized dashboards that adapt to user behavior. Implementing these features typically involves connecting the frontend to an LLM API and building intuitive interfaces around the responses.
Best Practices

While the benefits are clear, it’s important to use LLMs responsibly. Generated code should always be reviewed for accuracy, security, and maintainability. LLMs should be seen as accelerators rather than replacements—tools that help you focus on creativity and architecture rather than boilerplate.

When integrating LLMs directly into applications, developers must also consider the trade-offs of cost, latency, and privacy. A well-designed implementation balances these factors while still delivering value to the end user.
Conclusion

Large Language Models are quickly becoming part of the frontend developer’s toolkit. They help cut development time, improve code quality, and unlock new possibilities for user experience. More importantly, they allow developers to focus on solving meaningful problems rather than getting stuck on repetitive tasks.

The future of frontend development isn’t just about writing code faster—it’s about building smarter, more adaptive, and more user-centered applications. LLMs are not here to replace frontend developers, but to amplify their skills and open up new ways of thinking about how we design and build the web.

Setting Up a Frontend Build for HTML Email Templating with MJML

Thu, 18 Dec 2025 10:17:17 +0000

In this article, we'll break down two key stages: first, we'll create a repository for email templating, and then we'll configure local test sending via SMTP.

Why go through all this?

On one of our projects, we actively use HTML emails. Initially, templates were placed directly in the backend microservices - scattered and with repetitive parts. This created difficulties in maintenance and email testing. We wanted to simplify the development process, and most importantly - make email templating and checking convenient.

And as we know, email templating is painful. It's like you're developing for Internet Explorer - if you even remember what that is.

Moving Emails to a Separate Repository

We decided to create a separate repository where all email templates would be stored. The backend would be able to pull them centrally.

The next step was choosing tools for templating and testing. We considered:

MJML
Maizzle
Foundation HTML

We wanted to write in a higher-level language, using pre-built components. With Maizzle and Foundation HTML, it seemed like we'd have to write more raw HTML code.

In the end, we settled on MJML - a markup language for email templates that compiles into full-fledged HTML, adapted for the specifics of email clients.

What is MJML and Why is it Convenient?

MJML is a language designed for HTML email templating, which compiles into regular HTML. This means you can write in an abstract syntax that then turns into HTML code with support for different mail clients. This eases adaptation for various mail clients and gives the ability to use:

responsive templating;
pre-built components;
code reuse with mj-include.

You can see how MJML code turns into HTML here.

Basic Project Setup

Let's go through the basic project setup - without delving into MJML syntax.

Install dependencies:

npm install mjml live-server concurrently

What each one does:

mjml - compilation MJML → HTML
live-server - starting a dev server with live reload (you can use any
server)
concurrently - running commands in parallel

Configuring package.json

Add to scripts:

"scripts": {
  "start": "mjml --watch ./src/templates/**/*.mjml --output ./templates",
  "server": "live-server --host=localhost --watch=templates --open=templates --ignorePattern=\".*.mjml\"",
  "dev": "concurrently \"npm run start\" \"npm run server\"",
  "build": "mjml ./src/templates/**/*.mjml --output ./templates"
}

What each command does:

start - watches *.mjml files in src/templates/, compiles them to ./templates
server - starts a server and tracks changes in ./templates
dev - runs start and server in parallel
build - one-time template compilation without a watcher

Creating the First Template

Create a file example.mjml at /src/templates/example.mjml. All templates will be in the /src/templates folder. Add the following code to the file:

<mjml>
  <mj-body background-color="#f5f5f5">
    <mj-section padding="40px 0 20px">
      <mj-column>
        <mj-text align="center" font-size="28px" font-weight="bold">Email built with MJML</mj-text>
      </mj-column>
    </mj-section>
    <mj-section background-color="#ffffff">
      <mj-column>
        <mj-image src="https://placehold.jp/300x200.png" />
      </mj-column>
      <mj-column>
        <mj-text font-size="18px" font-weight="bold">Hello, world!</mj-text>
        <mj-text>This email was sent using MJML.</mj-text>
      </mj-column>
    </mj-section>
    <mj-section>
      <mj-column>
        <mj-button href="#" background-color="#4CAF50">Subscribe</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Run npm run dev - and a browser will open with the HTML generated from MJML. Each time the template changes, the page will automatically update. It's also useful to create a ./src/parts folder for reusable layout components.

As a result, we'll get desktop and mobile versions.

In the ./src/parts folder, create reusable email parts:

./src/parts/global-settings.mjml

<mj-style inline="inline">
  body { background-color: #f0f4f6; font-family: Arial, sans-serif; }
  a { color: #1d5cdb; text-decoration: none; }
</mj-style>
<mj-attributes>
  <mj-text
    font-size="17px"
    line-height="24px"
    color="#000"
    padding-top="5px"
    padding-bottom="5px"
  />
</mj-attributes>

./src/parts/header.mjml

<mj-section>
  <mj-column>
    <mj-image
      src="https://placehold.jp/82x47.png"
      alt="Logo"
      width="82px"
      height="47px"
    />
  </mj-column>
</mj-section>

Let's include them in example.mjml and remove unnecessary styles:

<mjml>
  <mj-head>
    <mj-include path="../parts/global-settings.mjml" />
    <mj-title>Example</mj-title>
  </mj-head>
  <mj-body>
    <mj-include path="../parts/header.mjml" />
    <mj-section padding="40px 0 20px">
      <mj-column>
        <mj-text align="center" font-size="28px" font-weight="bold">Email built with MJML</mj-text>
      </mj-column>
    </mj-section>
    <mj-section background-color="#ffffff">
      <mj-column>
        <mj-image src="https://placehold.jp/300x200.png" />
      </mj-column>
      <mj-column>
        <mj-text font-size="18px" font-weight="bold">Hello, world!</mj-text>
        <mj-text>This email was sent using MJML.</mj-text>
      </mj-column>
    </mj-section>
    <mj-section>
      <mj-column>
        <mj-button href="#" background-color="#4CAF50">Subscribe</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

We get the result:

In summary:

We can globally set common styles and settings for components using
global-settings.
We can similarly extract code parts, as done with header.
We develop and see changes in the browser in real-time thanks to the configured dev server.

Using Templates on the Backend (Go)

Our project backend is written in Go. The compiled email templates end up in the ./templates folder. From there, the backend can pull them and send emails. In our case, connecting templates looks like this:

In the project root - go.mod:

module gitlab.site.ru/front-html-email-templates

go 1.22.0
In ./templates/templates.go

package templates

import _ "embed"

//go:embed example.html

var Example string

When adding a new template, a similar variable needs to be added to templates.go.

Also, emails have variables that the backend substitutes using its templating engine. In our case, the syntax for variables is {{.variableName}}.

<mjml>
  <mj-body>
    <mj-section padding="40px 0 20px">
      <mj-column>
        <mj-text align="center" font-size="28px" font-weight="bold">{{.title}}</mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

To understand what variables are needed in a template, we created a ./docs/templates folder where we store markdown files with the same name as the template and a description of which variables are used, for example:

## Candidate

Email template 'Application without a vacancy'

### Variables
- `{{.date}}` Application Date
- `{{.title}}` Vacancy Title
- `{{.region}}` Region
- `{{.name}}` Full Name
- `{{.phone}}` Phone
- `{{.email}}` Email
- `{{.comment}}` Comment
- `{{.resume_link}}` Resume Link
- `{{.year}}` Current Year

The variables themselves can be added to the files by the backend developer, and the frontend developer just needs to place them in the layout in the correct spots.

Local SMTP Testing

Let's write a simple JS script that will send our templates to a real email.

First, install the following packages:

npm install dotenv nodemailer

dotenv — package for loading .env files in JS;
nodemailer — package for sending emails with SMTP support.

After that, create a file ./send-test-email.js and add the code:

import nodemailer from 'nodemailer'
import dotenv from 'dotenv'
import fs from 'fs/promises'

dotenv.config()

async function sendTestEmail() {
  const transporter = nodemailer.createTransport({
    host: process.env.SMTP_HOST,
    port: process.env.SMTP_PORT,
    secure: true, // true for port 587, false for other ports
    auth: {
      user: process.env.SEND_FROM_EMAIL,
      pass: process.env.SEND_FROM_EMAIL_PASSWORD,
    },
  })gmail.com

  const htmlEmailString = await fs.readFile(
    `./templates/${process.env.TEMPLATE_NAME}.html`,
    'utf-8'
  )

  const mailOptions = {
    from: `Test Sender <${process.env.SEND_FROM_EMAIL}>`,
    to: process.env.SEND_TO_EMAIL,
    subject: 'Test HTML Email',
    html: htmlEmailString,
  }

  const info = await transporter.sendMail(mailOptions)
  console.log('Message sent: %s', info.messageId)
}

sendTestEmail().catch(console.error)

This is a simple implementation for sending emails via SMTP. We also need to create a .env file with the necessary variables:

TEMPLATE_NAME=email-confirmation
SEND_TO_EMAIL=*Emails are not allowed*
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SEND_FROM_EMAIL=*Emails are not allowed*
SEND_FROM_EMAIL_PASSWORD=BcsftTdfdsf

TEMPLATE_NAME - the name of the template to be sent;
SEND_TO_EMAIL - where the email will be sent;
SMTP_HOST - SMTP host;
SMTP_PORT - port;
SEND_FROM_EMAIL - the sender's email address.
SEND_FROM_EMAIL_PASSWORD - the sender's email password.

Primarily, the TEMPLATE_NAME and SEND_TO_EMAIL variables change. For testing different templates and different mail clients.The other variables only need to be configured once.

After all the setup, to send an email, you need to run the script:

node ./send-test-email.js

For convenience, you can add a script to package.json. You can also implement support for bulk sending a template to different mail clients.

Conclusion

The current concept can be applied with other tools as well. As a result, we have:

a centralized repository for HTML emails;
email templating with best practices and reusable parts;
local SMTP testing.

It's important to keep in mind that templating can still break in old Outlook clients and with solutions like MJML where standard templates are provided. Even using best practices doesn't completely solve this issue. To avoid "breaking" in old solutions, you can use very trivial layout: simple texts and headings, no styling or visual elements.

Author: Dmitry Berdnikov

Architecture Pattern: "Compound Components" and Advanced Projection with `ngProjectAs`

Sat, 29 Nov 2025 17:37:29 +0000

When building a Design System or a library of shared components, the most difficult challenge is balancing consistency with flexibility.

You want all your Modals to look the same (consistency), but some Modals contain forms, others contain text, and others contain complex grids (flexibility).

The Architectural Pattern that solves this is Content Projection (specifically Multi-Slot Projection).

The Basics: The "Select" API

When you build a container, you define its API not by Inputs, but by Slots.

@Component({
  selector: 'app-layout',
  template: `
    <header>
      <ng-content select="nav"></ng-content>
    </header>
    <main>
      <ng-content></ng-content>
    </main>
  `
})
export class AppLayoutComponent {}

The Senior "Gotcha": Wrapper Elements

Here is a problem 99% of devs hit.

Imagine your app-layout expects a <nav> tag because of select="nav".

But you want to project a custom component called <app-top-bar>.

<app-layout>
  <app-top-bar></app-top-bar>
</app-layout>

Your app-top-bar will fall into the default slot (Main), not the Header slot.

The Junior Fix:
Wrap it in a nav tag.

<app-layout>
  <nav> <app-top-bar></app-top-bar>
  </nav>
</app-layout>

Problem: You just introduced an extra DOM node (<nav>) that might mess up your Flexbox or Grid layout.

The Senior Fix: ngProjectAs
Angular has a special attribute that allows you to "disguise" an element so it matches a specific selector, without adding extra DOM nodes.

<app-layout>
  <app-top-bar ngProjectAs="nav"></app-top-bar>
</app-layout>

This tells Angular: "Treat this component as if it were a <nav> tag for the purposes of projection."

The "Projected Content" Lifecycle Risk

As a Senior Developer, you need to know the performance cost.

Projected content is instantiated EAGERLY.

If you project a heavy component:
<app-modal><app-heavy-chart></app-heavy-chart></app-modal>

The app-heavy-chart is created, its constructor runs, and its ngOnInit runs immediately, even if the modal is hidden via display: none.

The Optimization:
If the content is extremely heavy, do not use basic Content Projection. Use Template Projection (ng-template).

<app-modal [contentTemplate]="myChart"></app-modal>

<ng-template #myChart>
  <app-heavy-chart></app-heavy-chart>
</ng-template>

// Child (Modal)
@Input() contentTemplate: TemplateRef<any>;

<ng-container *ngTemplateOutlet="contentTemplate"></ng-container>

This ensures the chart is not instantiated until the Modal actually renders the template outlet.

Mastering these nuances—ngProjectAs and TemplateRef—is what separates a component library author from a component user.

Deep Dive: Solving Race Conditions and Concurrency with RxJS Operators

Tue, 25 Nov 2025 05:39:27 +0000

Race conditions are the nightmares of frontend development. They happen when your code assumes that network request A will finish before network request B, but the internet decides otherwise.

In React or Vue (without RxJS), managing complex concurrency often requires boolean flags (isLoading), timestamp checks, or AbortControllers.

In Angular, we solve this elegantly with RxJS Mapping Operators.

But RxJS gives us four different tools: mergeMap, switchMap, concatMap, and exhaustMap. Choosing the wrong one isn't just a style choice; it determines whether your app creates bugs or prevents them.

Let's break down exactly which concurrency strategy each operator uses.

1. `switchMap`: The "Latest and Greatest" (Fixing Read Races)

The Strategy: Cancel the previous request if a new one arrives.

The Scenario:
Imagine a user is on a "User Details" page.

They click "User A". (Request A starts - Slow Network).
They get bored and click "User B" immediately. (Request B starts - Fast Network).

The Bug (without switchMap):
Request B finishes first and shows User B. Then, Request A finishes and overwrites the screen with User A. The URL says "User B", but the screen shows "User A". This is a dirty UI state.

The Fix:

this.route.params.pipe(
  // When params change, cancel any pending request!
  switchMap(params => this.userService.getUser(params.id))
).subscribe(user => {
  // We are GUARANTEED that 'user' matches the current URL.
  this.displayUser(user);
});

Best For: GET requests (Search, Route Params, Filters).

2. `concatMap`: The "Single File Line" (Fixing Write Races)

The Strategy: Wait for the current request to finish before starting the next.

The Scenario:
An "Auto-Save" feature in a text editor.

User types "Hello". (Request A sent).
User immediately types " World". (Request B sent).

The Bug (with switchMap):
If you used switchMap, Request B would cancel Request A. The server only receives " World". The word "Hello" is lost forever.

The Fix:
We need a Queue. Request B must wait in line.

this.textInput.valueChanges.pipe(
  // Queue the requests. Request B waits for Request A to complete.
  concatMap(text => this.api.saveDraft(text))
).subscribe();

Best For: PUT/POST requests where order matters (Auto-saves, sequential steps).

3. `mergeMap`: The "Free-for-All" (Parallel Execution)

The Strategy: Run everything immediately. I don't care about order.

The Scenario:
A "Bulk Delete" feature. The user selects 5 items from a list and clicks "Delete Selected".

The Strategy:
We don't want to wait for Item 1 to delete before starting Item 2 (too slow). And we certainly don't want to cancel Item 1 if Item 2 starts (bug). We want them all to fly to the server at once.

The Fix:

const idsToDelete = [1, 2, 3, 4, 5];

from(idsToDelete).pipe(
  // Fire 5 network requests in parallel
  mergeMap(id => this.api.deleteItem(id))
).subscribe(deletedId => {
  console.log(`Deleted ${deletedId}`);
});

Best For: DELETE requests or fetching unrelated data (e.g., getting Widget A and Widget B at the same time).

4. `exhaustMap`: The "Do Not Disturb" (Spam Prevention)

The Strategy: Ignore new requests while I am busy.

The Scenario:
A "Pay Now" button or a Login form.
A nervous user clicks the button 10 times in one second because the spinner didn't appear instantly.

The Bug (with mergeMap):
You charge the user's credit card 10 times.

The Bug (with switchMap):
You cancel the payment 9 times, and only the 10th one works (maybe).

The Fix:
We want to completely ignore clicks 2 through 10.

fromEvent(this.payButton, 'click').pipe(
  // If a payment is processing, IGNORE this click.
  exhaustMap(() => this.paymentService.chargeCard())
).subscribe();

Best For: Non-idempotent POST requests (Login, Payment, Submit).

Summary Cheat Sheet

Operator	Concurrency Strategy	Ideal Use Case
switchMap	Kill the previous	Reads (Search, Routing)
concatMap	Wait in line	Ordered Writes (Save)
mergeMap	Run in parallel	Parallel Writes (Delete)
exhaustMap	Ignore the new	Submit Buttons (Auth)

RxJS operators are tools for managing time. Master these four, and you master concurrency.

The Complete Guide to Angular Subscriptions: Template vs. Component Logic

Wed, 19 Nov 2025 18:25:11 +0000

Every Angular developer eventually faces the dilemma: How do I get my data out of the Observable?

There are two correct answers, and they serve different purposes. Let's look at the code for both.

Scenario 1: Pure Display (The Happy Path)

If your data is just going onto the screen, use the Async Pipe. It is Declarative, meaning you describe what you want (the stream value), not how to get it.

The Code:

// component.ts
data$ = this.service.getData(); // No subscription here!

<p>{{ data$ | async }}</p>

Verdict: Use this 90% of the time. It prevents memory leaks automatically.

Scenario 2: Component Logic (The Necessary Evil)

Sometimes, the Async Pipe isn't enough. You might need to:

Filter data based on local state.
Trigger a side effect (like a Toast notification).
Patch a Form Control value.

Here, you must subscribe. And to avoid Zombie Components (listeners that stay alive after the component dies), you need the takeUntil pattern.

The Code:

export class MyComponent implements OnDestroy {
  private destroy$ = new Subject<void>();

  ngOnInit(): void {
    this.dataService.getData()
      .pipe(takeUntil(this.destroy$)) // Use takeUntil with the destroy$ subject
      .subscribe(response => {
        this.data = response;
        this.form.patchValue(response); // Specific logic!
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next(); // Emit a value to signal completion
    this.destroy$.complete(); // Complete the subject
  }
}

Key Takeaway:
Don't be afraid of manual subscriptions, but respect them. They require explicit cleanup logic. If you can avoid them by using | async, do it. If not, use takeUntil.

The Indispensable Practice of Abstraction: Decoupling Your Frontend Logic from External Libraries

Mon, 20 Oct 2025 11:14:55 +0000

In modern frontend architecture, the principle of separation of concerns is paramount. Your application's core logic (business rules, state, and UI) must be entirely isolated from the specific Application Programming Interfaces (APIs) of third-party libraries. This best practice, known as creating an Anti-Corruption Layer (ACL), is the difference between a flexible, maintainable codebase and a fragile, tightly coupled one.

The Problem: Tight Coupling and Vendor Lock-in

When you directly integrate a library's specific methods into your components, you create a dependency that is rigid and difficult to change. For instance, directly using window.Stripe.redirectToCheckout() in a checkout button component couples your UI directly to the Stripe SDK.

The Core Risks:

Vendor Lock-in: You are locked into a specific vendor (e.g., Supabase, Auth0, Stripe). If a better, cheaper, or more performant alternative emerges, changing libraries means a massive, error-prone refactor across your entire application.
Difficult Testing: Unit testing a component that directly calls an external SDK requires complex mocking of that entire library's API, cluttering your test setup.
Inconsistent Code: Error handling, data formatting, and asynchronous logic become inconsistent when repeated across many components.

The Solution: The Abstraction Layer

The solution is an intermediate layer—a Service, Repository, or Utility module—that acts as the single point of entry for all library interactions.

How Abstraction Works:

Generic Interface: Define functions using domain language (e.g., getProducts, processPayment) that describe what your app needs to do, not how it's done.
Encapsulation: All library-specific imports and calls are encapsulated within this single module.
Standardization: The layer is responsible for translating the external library's quirky response formats and error structures into the simple, predictable formats your application expects.

1. Abstracting Data Access (The Repository Pattern)

This is the most critical area for separation. We separate the database library (like Supabase) from the code itself by creating a Service or Repository layer with generic names.

Example: Decoupling Data Fetching (Supabase vs. Custom REST API)

Let's assume our application needs to fetch product data.

Tightly Coupled (Bad)

// src/components/ProductList.jsx

import { supabase } from '../lib/supabaseClient'; // Directly importing the library

const fetchProducts = async () => {
  // Hard dependency on Supabase API structure (from, select, etc.)
  const { data: products, error } = await supabase.from('products').select(`
    id,
    name,
    price_cents,
    inventory:product_inventory(stock_count)
  `);

  if (error) throw new Error(error.message);

  // Data requires complex, specific formatting here
  return products.map(p => ({
      ...p,
      price: p.price_cents / 100,
      stock: p.inventory[0]?.stock_count || 0
  }));
};

Decoupled (Good) with a Service

First, the abstraction layer handles the library call and data standardization:

// src/services/productService.js (The Abstraction Layer)

import { supabase } from '../lib/supabaseClient'; // Encapsulates the library dependency

// Defines a predictable structure for the rest of the application
const formatProduct = (productData) => ({
    id: productData.id,
    name: productData.name,
    price: productData.price_cents / 100, // Standardize cents to dollars
    stock: productData.product_inventory[0]?.stock_count || 0,
});

export const productService = {
  // Generic function name: getProducts
  getProducts: async () => {
    // 1. Library-specific call is confined here
    const { data, error } = await supabase.from('products').select(`
      id,
      name,
      price_cents,
      product_inventory(stock_count)
    `);

    if (error) {
      // 2. Standardize error handling
      throw new Error("Failed to retrieve products from data source.");
    }
    // 3. Standardize and return clean, formatted data
    return data.map(formatProduct);
  },
};

Second, the component uses the clean interface:

// src/components/ProductList.jsx

import { productService } from '../services/productService'; // Generic interface

const fetchProducts = async () => {
  // Clean, generic call. The component doesn't know (or care) about Supabase
  const products = await productService.getProducts();
  // ... use products
};

The Flexibility: If you replace Supabase with a custom REST API using Axios, you only change productService.js. The component code remains untouched.

// src/services/productService.js (Rewritten for Custom REST API via Axios)

import axios from 'axios'; // Encapsulates the new dependency

// formatProduct function remains the same!

export const productService = {
  getProducts: async () => {
    try {
      // New library-specific call
      const response = await axios.get('/api/v1/products');
      // Assume the API returns raw data that still needs to be formatted
      return response.data.map(formatProduct);
    } catch (error) {
      throw new Error("Failed to retrieve products from REST API.");
    }
  },
};

2. Abstraction for All External Dependencies

This principle should be applied to every external dependency to ensure your application is future-proof and agile when a library becomes obsolete or unsuitable.

A. Payment SDKs (e.g., Stripe)

Your checkout flow must be protected from library changes.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Payment: Redirect to checkout screen.	Component calls: `window.Stripe.redirectToCheckout({ /... config / })`	Component calls: `paymentService.initiateCheckout(cartId)`
Abstraction Layer:	None	`paymentService.js` handles all Stripe SDK imports, configurations, and API calls.
Flexibility:	Switching to PayPal or Square requires modifying every component that touches payment.	Only `paymentService.js` needs to be rewritten. The `initiateCheckout` function signature is preserved.

B. Internationalization (i18n) Libraries (e.g., FormatJS vs. react-i18next)

Components should only request a translated string using a generic key.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Translation: Get a welcome message.	Component uses: `const { formatMessage } = useIntl(); return formatMessage(messages.welcome)` (FormatJS-specific)	Component uses: `const { T } = useAppTranslation(); return T('welcome_message', { name: user.name })`
Abstraction Layer:	None	`useAppTranslation.js` wraps the specific library's translation hook/functionality.
Flexibility:	Switching to a different i18n library means changing hook imports and function names in every component.	Only the implementation inside `useAppTranslation.js` changes, maintaining the generic `T` interface.

C. Client-Side Authentication (e.g., Auth0 vs. Firebase Auth)

Decoupling auth ensures your routing and UI logic are stable regardless of the provider.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Auth Status: Check if a user is logged in.	Router guard calls: `Auth0Client.isAuthenticated()`	Router guard calls: `authService.isLoggedIn()`
Abstraction Layer:	None	`authService.js` or `useAuth` hook handles token storage, session checks, and specific library methods.
Flexibility:	If you migrate from Auth0 to Firebase Auth, you need to update logic everywhere Auth0's specific methods are called.	Only `authService.js` is rewritten to use Firebase SDK methods, keeping the generic interface intact.

Key Takeaways for Robust Frontend Architecture

Practice	Principle	Rationale
Name Generically	Domain Language Over Technology: Use names like `userService` or `paymentService`, not `clerkAuthService` or `supabasePosts`.	The name reflects the domain concept, not the implementation detail.
Standardize Data	ACL Responsibility: The service layer must convert the library's output (e.g., a complex object with metadata) into the exact clean object your app needs.	The rest of your application code deals with a single, predictable data format.
Error Handling	Translate Errors: Catch library-specific errors and re-throw them as simple, standardized application-level errors (e.g., a `DataFetchError`).	Components only need to handle a few generic error types, simplifying UI feedback.
Apply Universally	Systematic Abstraction: If you use a library, abstract it. This applies to data access, state management, auth, analytics, utility functions, and more.	Maximizes code agility, testability, and reduces maintenance complexity across the board.

By committing to this principle of universal abstraction, you build a frontend application that is architecturally sound, easier to test, and perfectly positioned to adapt to the technological shifts of tomorrow.

JavaScript: Array Iteration and DOM Manipulation in Game Development

Mon, 13 Oct 2025 17:54:24 +0000

This article explores JavaScript array iteration and DOM manipulation, including practical game development examples. You will also learn a game-state sync technique to enhance your own projects!

Array Iteration

What is array iteration? Array iteration is the process of sequentially accessing each element in an array to perform operations or calculations. This technique is essential in JavaScript for efficiently managing and manipulating data stored in arrays, such as updating game states or displaying information.

In my JavaScript Pac-Man game, I store information in arrays and iterate through them for my game logic to carry out various tasks. For example, the fruit bonus that appears twice per level utilizes an emoji and a matching point value based on the level.

For a simple demonstration, the code block below shows an iteration over the fruitBonus array: The console logs the corresponding emoji along with the point value stored in the fruitBonusValue array.

// Arrays store fruit icons and their bonus values for each level
export const fruitBonus = ['','','','','','','','','','',''];
export const fruitBonusValue = [100,300,500,500,700,700,1000,1000,2000,3000,5000];

// Example: Display all fruit bonuses and their values
for (let i = 0; i < fruitBonus.length; i++) {
  console.log(`Level ${i + 1}: ${fruitBonus[i]} = ${fruitBonusValue[i]} points`);
}

// Console log:
"Level 1:  = 100 points"
"Level 2:  = 300 points"
"Level 3:  = 500 points"
"Level 4:  = 500 points"
"Level 5:  = 700 points"
"Level 6:  = 700 points"
"Level 7:  = 1000 points"
"Level 8:  = 1000 points"
"Level 9:  = 2000 points"
"Level 10:  = 3000 points"
"Level 11:  = 5000 points"

(The actual game logic is more complex but follows the same iterative approach.)

Array Iteration and DOM Manipulation

The Document Object Model (DOM) is a programming interface for web documents, representing the page structure as a tree of objects. With JavaScript, you can manipulate the DOM to dynamically alter a webpage's content, structure, and style, enabling you to build interactive and responsive user experiences.

The main functionality of game level completion in my project is for Pac-Man to eat all the pellets on the game board. I initially handled this by checking if Pac-Man’s current index also had a CSS pellet class, using the JavaScript includes method. However, this approach proved unreliable for tracking game progress. To solve this, I created a dedicated pelletState array to track the state of each pellet throughout the game.

Now with the pelletState array, I can properly track the status of every pellet and power pellet on the board, regardless of visual glitches or overlapping game elements. This ensures that Pac-Man’s progress, level completion, and scoring are always accurate, and the game logic remains in sync with what the player sees.

However, a new glitch emerged: ghosts occasionally removed CSS pellet classes while traversing through the gameboard, preventing level completion because the corresponding pellets remained in the pelletState array. It was a pretty funny glitch because the ghosts would eventually return the pellets when they passed by the divs they took them from, as if they were cheating me out of finishing the level!

As part of my pelletState array solution, the CSS pellet classes are temporarily removed from a square when a ghost enters and restored when the ghost leaves. The pellet’s state, however, is always tracked in the array, ensuring consistent game logic regardless of visual changes. This approach is necessary due to CSS scaling; ghosts visually shrink to the size of the pellet when sharing a square, so managing the classes separately prevents display issues.

Syncing Game State and DOM with Array Iteration

I created a syncPelletClasses function to keep the pelletState array and pellet CSS classes in sync, running it every time the board state changes. This function, syncPelletClasses(), iterates through the pelletState array and updates the DOM for each square: if a pellet or power pellet is present in the array and no ghost is on that square, the corresponding CSS class is added; if a ghost is present, the class is removed. This keeps the visuals accurate without affecting the underlying game logic.

By separating the visual state (CSS classes) from the game state (the array), I ensured that pellets are never “lost” due to ghost movement or display quirks. Pac-Man’s progress and level completion are now reliably tracked, and the game remains arcade-authentic—even when ghosts and pellets overlap.

export function syncPelletClasses() {
  for (let i = 0; i < pelletState.length; i++) {
    // Only add pellet class if no ghost is present
    if (pelletState[i] === 'pellet' && !squares[i].classList.contains('ghost')) {
      squares[i].classList.add('pellet');
    } else {
      squares[i].classList.remove('pellet');
    }
    if (pelletState[i] === 'powerPellet' && !squares[i].classList.contains('ghost')) {
      squares[i].classList.add('powerPellet');
    } else {
      squares[i].classList.remove('powerPellet');
    }
  }
}

Tip: By utilizing this game-state sync technique, you can build more reliable, visually accurate games and interactive apps. Try applying array-driven state management in your own projects for smoother, bug-free experiences!

JS Pac-Man Project Links:

Link to the deployed project

Link to GitHub

Link to the sprint board

Note: Since I’m following team development practices and pushing updates to the develop branch, some of the changes I describe in this article may not be live in the deployed version of the game yet.

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

With CodeMonkey, learning can be all fun and games! CodeMonkey transforms education into an engaging experience, enabling children to evolve from tech consumers to creators. Use CodeMonkey's FREE trial to unlock the incredible potential of young tech creators!

With a structured learning path tailored for various age groups, kids progress from block coding to more advanced topics like data science and artificial intelligence, using languages such as CoffeeScript and Python. The platform includes features for parents and teachers to track progress, making integrating coding into home and classroom settings easy.

Through fun games, hands-on projects, and community interaction, CodeMonkey helps young learners build teamwork skills and receive recognition for their achievements. It fosters a love for coding and prepares children for future career opportunities in an ever-evolving tech landscape.

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Become a hireable developer with Scrimba Pro! Discover a world of coding knowledge with full access to all courses, hands-on projects, and a vibrant community. You can read my article to learn more about my exceptional experiences with Scrimba and how it helps many become confident, well-prepared web developers!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Array iteration lets you efficiently access and update each element in a collection, making it a foundation for managing dynamic data in JavaScript. The Document Object Model (DOM) is a programming interface representing a webpage's structure as a tree of objects, which, in JavaScript, allows for dynamic modification of content, structure, and style for interactive experiences.

Using array iteration for DOM manipulation, I solved glitches in my game using array-driven state management: I used a syncPelletClasses function to align the pelletState array with the DOM, updating visuals based on game state changes. This solution ensured that the game logic always matched what players saw on screen and what was accessible to the code.

If you’re building interactive apps or games, try leveraging array-driven state management and DOM syncing techniques to help create smoother, more reliable user experiences!

Let’s connect! I’m active on LinkedIn and Twitter.

Beyond the Array: Why Normalized Maps and Sets Supercharge Your Frontend Performance

Mon, 06 Oct 2025 17:31:36 +0000

In modern frontend development, API responses often arrive as arrays of objects. While simple, relying solely on these arrays for state management introduces a fundamental performance bottleneck: linear time complexity (O(N)).

By adopting a normalization strategy using JavaScript's Map and Set, we shift critical operations to constant time (O(1)), making applications faster, more consistent, and scalable.

The Core Performance Barrier: Array's O(N) Lookups

The problem with a simple array is that accessing an item by its ID requires iterating through the list until a match is found.

Impact: If you have N items, finding a specific one requires an average of N/2 checks. As your data scales, retrieval and update times worsen linearly. This manifests as UI lag and sluggish response times, especially on large datasets.

The solution is to decouple the data's storage structure from its display order.

️ The Normalized Solution: O(1) Consistency and Access

Normalization is the architectural practice of storing each unique entity (like a product, user, or post) in a single, central location keyed by its unique identifier.

1. `Map` as the Entity Store (The Source of Truth)

The Map becomes your application's single source of truth because its hash-table-like structure allows for instantaneous key-based retrieval (O(1)), regardless of the map's size.

Advantage A: Guaranteed Data Consistency

In large applications, the same data might be displayed in a main feed, a sidebar, and a notification area.

Map Impact: When an update arrives (e.g., a post's like count increases), you mutate the single object within the Map. Because all views are referencing this same object, consistency is guaranteed automatically by the reactive framework. There is no need for slow searches across multiple separate arrays.

Advantage B: Instantaneous Updates

In high-frequency scenarios, like social media feeds or chat applications, every millisecond counts.

Map Impact: When a specific item needs updating (e.g., Post ID 500), the system skips the array search entirely and performs a direct, instantaneous lookup: postsMap.get(500).likes = 101. This efficiency is crucial for real-time responsiveness.

2. `Set` for Ultra-Fast Membership Testing

The Set is ideal when you only need to know if an item exists, not the item's details.

Set Impact: Using a Set to store active user IDs in a chatroom allows the system to check permissions with O(1) speed. This is far more efficient than an O(N) array check, particularly for operations like sending messages that are triggered frequently.

The Hybrid Approach: Filtering and Display Order

While Maps handle storage, Arrays are still necessary for ordered display. The optimal strategy is a hybrid: use the Map for the data, and an Array of IDs for the view structure.

The Display Logic Flow

This pattern is most powerful when managing complex filtering and sorting:

Filtering: When a user applies criteria (e.g., location, salary), the system iterates through the keys of the massive jobsMap (the only remaining O(N) step).
Resulting Array: The output is a small array of matching IDs (e.g., [205, 112, 340]), not an array of full data objects.
Sorting: The application only sorts this small array of IDs, which is dramatically faster than sorting the original 10,000-item dataset.
Rendering: The application iterates through the small array of IDs. For each ID, it performs an instant O(1) lookup in the jobsMap to retrieve the full object details for rendering.

This hybrid approach isolates the O(N) complexity to the filtering step, making all subsequent and more frequent operations (retrieval, sorting, and single-item updates) perform at O(1) efficiency. This separation of concerns ensures your UI remains fast and responsive, regardless of the size of your underlying data.

Space vs. Gap — Tailwind CSS Explained

Sat, 04 Oct 2025 07:32:09 +0000

Tailwind is an awesome resource when styling web applications. It’s fast, lightweight, and easy to use once you get used to the class-first syntax. But what do you use when you need to add some spacing between items — gap or space?
Let’s get into it.

What do I use?

To tackle this question, let’s create a scenario. We’ll be using three boxes represented by divs in an HTML document.

<section>
  <div class="w-48 h-48 bg-slate-300">Box 1</div>
  <div class="w-48 h-48 bg-slate-400">Box 2</div>
  <div class="w-48 h-48 bg-slate-500">Box 3</div>
</section>

In this example, there are three boxes we need to add some spacing to. Normally, the way to go about this would be to:

Use a flex layout on the section parent element and add a gap value to create space.
Use a margin on each box.

But what happens when there’s no need to use a flex layout or margin? What do we use?

That’s where the space Tailwind class comes in. Picture it as what gap is capable of in a grid or flex layout, but without the flex/grid. So let's see a side-by-side comparison.

<!-- with tailwind space -->
<section class="space-5">
  <div class="w-48 h-48 bg-slate-300">Box 1</div>
  <div class="w-48 h-48 bg-slate-400">Box 2</div>
  <div class="w-48 h-48 bg-slate-500">Box 3</div>
</section>

<!-- with tailwind gap -->
<section class="flex gap-5">
  <div class="w-48 h-48 bg-slate-300">Box 1</div>
  <div class="w-48 h-48 bg-slate-400">Box 2</div>
  <div class="w-48 h-48 bg-slate-500">Box 3</div>
</section>

In the first code block, using Tailwind spacecreates spacing between the items in the section element. The main difference is that when using gap, a flex or grid layout is required, whereas when using space, it's not.

This is something I discovered earlier when exploring more of what Tailwind CSS can do in my projects.

Hopefully, this article has helped to simplify the gap vs. space concept in Tailwind. For more detailed documentation, please visit the official Tailwind docs: Tailwind gap vs. Tailwind space.

Thanks for reading, and have a great day.
Ciao

Blockchain and Frontend Development: Building the Decentralized Web

Wed, 13 Aug 2025 20:47:13 +0000

Where Blockchain Meets the Frontend

At a high level:
Blockchain is the backend layer in many decentralized applications (dApps).
Frontend is the user interface that allows people to interact with that blockchain.

Unlike traditional apps where the frontend talks to a server and database you control, in blockchain apps:

The frontend communicates with smart contracts on a blockchain network.
Data is fetched from decentralized sources instead of centralized APIs.
Users connect their wallets (e.g., MetaMask) to sign and send transactions.

2. How Frontend Connects to Blockchain

To bridge frontend with blockchain, developers use:

Web3 Libraries

ethers.js – Lightweight and modern.
web3.js – Older but widely used.

Wallet APIs

Browser extensions like MetaMask or Phantom inject JavaScript APIs
(e.g., window.ethereum).
Smart Contract ABIs
The ABI (Application Binary Interface) acts like a contract’s “menu”
— telling the frontend what functions exist and how to call them.

Example flow:

User clicks “Buy NFT” button on a React app.
Frontend calls a function in a smart contract via ethers.js.
Wallet pops up asking for confirmation.
Transaction is sent to the blockchain.
UI updates after blockchain confirms.
Common Frontend Tools for Blockchain Projects
Frameworks – React, Next.js, Vue.js, Svelte.
State Management – Redux, Zustand, Vuex.
UI Libraries – Tailwind CSS, Chakra UI, Ant Design.
Blockchain Integrations
WalletConnect (connect mobile wallets)
RainbowKit (wallet UI for Ethereum)
Apollo Client (for GraphQL APIs like The Graph)
Challenges in Blockchain Frontend
Transaction delays – Need loading states and confirmations.
Gas fees – Must display cost estimates clearly.
Network switching – Sometimes users are on the wrong blockchain
network.
Security – Never expose private keys in the frontend.
Real-World Examples
NFT Marketplaces – Frontend handles image galleries, bidding UI, and
wallet connections.
DeFi Dashboards – React or Vue UI showing real-time balances and
yield calculations.
Gaming dApps – Game UIs integrated with blockchain-based asset
ownership.

6. The Future of Blockchain Frontends

As Web3 grows:

Frontends will become more wallet-native (log in with your wallet
instead of username/password).
Data fetching will rely more on decentralized indexing tools like The
Graph.
Frameworks may include blockchain-ready templates out of the box.

What is Javascript and How It Powers Modern Websites

Tue, 12 Aug 2025 12:21:13 +0000

Picture this: You click a button on a webpage, and absolutely nothing happens .

There are no dropdown menus to explore, no fun animations to enjoy, and no validations on form submissions.

Basically, a lifeless piece of the internet.

That's what the web would look like without Javascript.

What is Javascript?

Javascript, often abbreviated as "JS", is the wacky genius of modern web development.

It's the magic wand that transforms static, boring HTML and CSS websites into lively, interactive, and engaging experiences that are hard to stop scrolling through.

Simply put, Javascript is a programming language that adds interactivity, animations, and dynamic features to websites. Whether it's a pop-up (), a dropdown menu (), or an animation that dances across your screen—Javascript is behind the curtain pulling the strings.

It's one of the holy trinity of web development:

HTML – gives structure
CSS – makes it pretty
Javascript – brings it to life ⚡

It's primarily a client-side language, event-driven, and runs directly in your browser without requiring installation. Magic? Nope—just good old scripting.

Technically:

It's interpreted (runs directly, no compiling)
It's dynamically typed (you don't have to declare types — more on this in a later article)
It uses prototypal inheritance instead of classical OOP (we'll unpack this later — no stress if that sounds unfamiliar!)
It runs using something called a Javascript engine inside your browser (don't worry, we'll explain what that means soon)

Oh, and it also works on the server side, but we'll dive into that later.

A Brief History of Javascript

Back in 1995, Brendan Eich developed Javascript in just 10 days. Yes, that's faster than most of us write a to-do list .

Originally called Mocha (mmm, coffee), then Live Script, it was finally rebranded as Javascript because, hey, Java was trendy at the time ☕.

Despite the misleading name, Java ≠ Javascript—that's like comparing ham to a hamster.

Fast-forward to today. Javascript has grown from a toy language into one of the web's core technologies, alongside HTML and CSS. It is now standardised under ECMAScript and powers everything on the web except your morning coffee .

✨ Core Features of Javascript

Javascript isn't just pretty code—it's flexible, feisty, and full of surprises.

Dynamically Typed – like, whatever
Event-Driven – reacts to user clicks, scrolls, and tantrums .
Fast – thanks to powerful browser engines ⚡
Versatile – works on browsers, servers, phones, fridges (not kidding !)
It Has Superpowers (via Ecosystem) - There's a massive library of tools and frameworks. React, Vue, D3, Express, Socket.io — you're never alone in Javascript land .

It's like that colleague who can debug complex code with ease, seamlessly integrate APIs, and always finds time to collaborate on projects.

How to Run Javascript in a Browser

Javascript is built right into all major browsers (Chrome, Firefox, Safari, Edge), like a secret snack drawer .

You can run Javascript in the browser in a few simple ways:

1. The Developer Console (For Quick Testing)

Open Chrome (or any browser).
Press F12 or right-click → Inspect.
The browser's developer tools will open up. Go to the Console Tab.

Type this, Hit Enter and watch the magic unfold ✨

console.log("Hello, World! ");

2. Add it directly to HTML

Use the <script> tag inside your HTML file - index.html:

<!DOCTYPE html>
<html>
    <body>
        <h1>Javascript Test</h1>

        <script>
            alert("Hello, World! ");
        </script>
    </body>
</html>

Open the index.html file in your favorite browser.

Boom! JS is live and will greet you like a chatty bot!.

How Javascript gets executed

Before getting our hands dirty with Javascript code, it is better to have a basic understanding of how Javascript gets executed. ☄️

Javascript alone is just syntax and logic; just like any other programming language, a compiler or an interpreter is needed to execute Javascript.

Well, there are still ongoing debates about whether Javascript is a compiled language or an interpreted language. It would be more accurate to say that Javascript in modern times is both compiled and interpreted, specifically through JIT (Just-In-Time) Compilation. More on this later.

To interact with web pages, forms, user events, or fetch data, it requires a host where this JIT Compiler (a Javascript engine) is embedded, much like the engine of a car—essential for driving the experience forward and making everything run smoothly.

What Is a Hosted Environment? ⚙️

A hosted environment — or, as seasoned developers call it, the runtime environment — is the setup provided by the host system, such as a web browser or Node.js, that embeds and interacts with the Javascript engine. This environment offers some juicy extras — such as fetch, document, and setTimeout — that the core Javascript language doesn't include.

Key Examples of Hosted Environments for Javascript

Web Browsers (Client-side Hosted Environment)
- DOM access: via document, window
- Browser APIs: like fetch(), alert(), console.log()
- Timers: setTimeout, setInterval. etc
Characteristics:
- Code runs in the context of a webpage.
- Controlled by the browser's security and event loop.
- Can access and manipulate the DOM.
Node.js (Server-side Hosted Environment)
- File System: via fs
- Network: http
- Other APIs: process, require, etc.
  
  Characteristics:
  - Code runs on a server, often with access to the filesystem and network.
  - No DOM or browser-specific features.
  - Includes an event-driven, non-blocking I/O model.
Other Examples:
- Deno: Secure TypeScript/Javascript runtime with modern APIs.
- Edge Functions / Serverless Platforms: Cloud-hosted Javascript executed in response to HTTP requests.

All major browsers have Javascript engines built into them (Chrome, Firefox, Safari, Edge)

Some well-known JS engines are,

Chrome → V8 Engine
Firefox → SpiderMonkey
Safari → JavaScriptCore

What happens when you load a web page?

So, how exactly does Javascript run when you load a web page?

Here's a simplified overview that doesn't require a PhD:

You load a page – Browser reads the HTML and finds a <script> tag.
The Javascript engine (like V8 in Chrome or SpiderMonkey in Firefox) kicks in.
The engine parses the code, converts it into something called bytecode or machine code.
It executes the code line by line, handling events, functions, loops, and more.
It interacts with the browser's APIs, including the Document Object Model (DOM) and the Browser Object Model (BOM), to enable engaging functionality on the screen.

The way everything unfolds within the browser and our Javascript engine is a fascinating process, which we will explore in more detail in a future article.

How to Add Javascript to a Website

There are three classic ways to add Javascript:

1. Inline Javascript

Directly inside HTML elements.

<button onclick="alert('You clicked!')">Click me</button>

✅ Easy to test. ❌ Not scalable or maintainable

2. Internal Scripts in Tags

In a <script> in the HTML.

<script>
    console.log("This runs when the page loads.");
</script>

Great for small scripts during development.

3. External Javascript Files

In a separate HTML file - index.html

<!-- In index.html - Withing <body> tag -->
<script src="script.js" defer></script>

Inside script.js:

// script.js
console.log("This is coming from an external file.");

Use defer to make sure the script runs after the HTML has loaded.

Best practice: Keeping your Javascript in a separate .js file helps to create cleaner and easier-to-manage code. No one likes spaghetti code.

⚡ How Javascript Powers Modern Websites

Javascript is the heartthrob of modern web design ❤️. Well, yeah, no second thoughts on that.

It's everywhere, like the air we breathe , and it's lightning-fast ⚡.

It transforms static pages into dynamic, interactive experiences. From simple interactions like button clicks to full-scale SPAs (Single-Page Applications) that feel like native apps, Javascript is the engine driving modern UX.

With powerful frameworks like React, Vue, and Svelte, and back-end tools like Node.js, Javascript isn't just hanging out in the browser anymore—it's running the whole show, front to back. There's literally a JS tool for everything.

If modern web design were a kitchen, HTML would be the recipe, CSS the presentation on the plate, and Javascript the chef, making the magic happen in real-time.

Client-side vs Server-side Javascript

Client-Side (Browser)

It runs on your Devices . It controls UI and responds to events.

Examples - React, Vue, Angular, etc

Server-Side (Node.js)

It runs on a remote server ️. It handles data, APIs and back-end logic.

Examples - Express, NestJS, etc

Core Javascript lays the foundation, and all the frameworks and libraries ️ build on top of it.

⚠️ Challenges and Limitations

It's not all sunshine and syntax.

Security – Cross-site scripting can be nasty ️
Browser quirks – Some browsers love being extra
Messy code – Write it clean or watch your app turn into spaghetti
Performance issues: Heavy scripts can slow your site down to turtle speed
Debugging hell: Sometimes finding that one missing semicolon feels like searching for a needle in a haystack

But hey, every hero has their flaws—Javascript's just keeping things spicy ️.

The Future of Javascript

Javascript isn't going anywhere except everywhere. It's growing wiser, faster, and maybe just a little weirder (in a good way). Here's what's cooking:

Web Assembly (Wasm): Javascript's hitting the gym. With Wasm, it's teaming up with languages like Rust and C++ to tackle tasks it was never built for, such as hardcore gaming, video editing, and heavy-duty number crunching — all in your browser. JS + Wasm = power couple of the web.

TypeScript: Javascript's awkward teen years are over. TypeScript is helping it adult properly, giving it types, better tooling, and fewer "undefined is not a function" moments.

AI and Smart Tooling: Development tools are becoming increasingly intelligent. Imagine writing code and your editor gently whispering, "Hey, you forgot a semicolon… again." AI-assisted coding (hello, Copilot and beyond) is making Javascript dev life faster, easier, and slightly creepier.

Framework Wars 2.0: React, Vue, Svelte, Solid, Qwik, and friends are all pushing the boundaries of fast, reactive UI. The future is about smarter rendering, less Javascript shipped to the browser, and fewer "why is my page load 3MB" moments.

⚙️ Server-side Evolution: Node.js, Deno, Bun — everyone's racing to make server-side Javascript faster, leaner, and cooler. Serverless functions and edge computing are making it possible to run Javascript anywhere... even on a fridge (probably).

Universal Everything: Full-stack Javascript is now the norm. Front-end, back-end, mobile apps, desktop apps, even IoT — all running Javascript. Pretty soon, your toaster might be sending JSON logs straight to your console ️—because even breakfast needs debugging .

Conclusion

Javascript isn't just code—it's the spark that makes the web come alive ⚡. Without it, your site is basically a mannequin in a shop window . But with Javascript? Boom—now you've got Iron Man flying across your screen .

So go ahead, crack open that browser console .

Build stuff ️. Break stuff . Fix stuff . Repeat .

That's the Javascript way .

From Vanilla Template to Still.js Components: A Full Build and Deployment Guide

Mon, 11 Aug 2025 02:56:47 +0000

A full Still.js build from raw HTML to deployment — with zero dependencies.

A few days ago, I was asked about migrating a project to Still.js, this article is accompanied by a video demonstrating it.

Because it’s built in Vanilla JavaScript, Still.js combines perfectly with a template that is based with pure/raw HTML, CSS and JavaScript, even if some library (e.g. jQuery, Bootstrap) was used, Still.js helps you to ease separate things into components, as show cased in this video.

What will be covered:

Migrating a Vanilla web template to Still.js
Back down the template into components conveniently
Load template’s JavaScript code properly according to Still.js architecture
Deploy to the cloud

Key Considerations:

When using templates with a lot animations, or that depends on different javaScript library to load, it’s important to deeply understand it (the template) so to orchestrate each
Script dependency just the same way it happens with raw HTML, CSS and JavaScript.

Minimalist third party Script dependency approach:

Now a days a lot of features like animation and more (e.g. parallax, singlePageNav, dialog, IntersectionObserver - Lazy animation) are browser native, hence, this would impact a lot in the choosing on what/when to use libraries especially when it comes to animation which some web pages are depending a lot.

Vanilla JavaScript is one of the core philosophy of Still.js, hence you can use everything as natural as possible from Web Semantic to straight DOM manipulation.

We’ll use this template, and we’ll be deploying our page to Render which will provide us with a custom domain.

In summary, on the coding and structure side of things the steps will be as follow:

the HTML code will be moved to the Still.js template/template file (.html)
Run template JavaScript animation in the stAfterInit hook, ensuring it executes after component load
Convert sections into autonomous components

Conclusion

Still.js helps turn vanilla templates into fast, modular, and lightweight sites with zero dependencies, giving you full control using pure JavaScript. Proper code organization is key to avoid issues like bloating or conflicts, and a vanilla-first approach is recommended, external libraries should only be used when necessary.

What’s Next?

Don't forget to follow the hands-on video till the end so we can make the deploy.

Expand Your Still.js Skills

Explore advanced Still.js features like state management, routing, or
integrating APIs.
Try building a small SPA or dashboard using
Still.js components capabilities.

Contribute to Still.js

Still.js is open-source, consider contributing or helping improve documentation.
Join the discord channel to get fast updates and follow the discussions

Ask more if needed

Share any topic you want to see cover so content (e.g. video, article) can be produced.

Se ya in the next one

VSCode vs IntelliJ: Where VSCode Still Struggles, and How to Push It Further

Sun, 20 Jul 2025 12:26:39 +0000

Over the past few years, VSCode has eaten the developer world. Lightweight, fast, deeply customizable—it feels like the ideal coding companion. On the other side sits IntelliJ: powerful, heavy, feature-packed, and—for some—overkill.

But let’s cut through the hype. If you’re building anything more complex than a quick script, IntelliJ isn’t just "heavier"—it’s smarter. It understands your code, your project, and your dependencies in a way that VSCode simply doesn’t.

Here’s a brutally honest breakdown of where VSCode is behind, backed with real examples—and how some of those gaps can be patched, including with tools like Depramanager.

1. Project Awareness: A Real IDE vs a Fancy Text Editor

IntelliJ knows what your project is. Whether it’s a Java Maven multi-module app, a Python virtual environment, or a full-stack Node.js + Docker + PostgreSQL repo, IntelliJ parses it top-down. It indexes your files, understands your build system, configures environments, and tracks project-wide issues.

VSCode? It sees folders. Just folders.

You might:

Manually configure Python interpreters
Hope your settings.json doesn’t get out of sync
Wrestle with 4–5 extensions just to handle testing, linting, formatting, and debugging

Example:

Open a Python project in IntelliJ? You get immediate virtualenv detection, test runner config, linting, and code inspections.
In VSCode? You manually point to your .venv, tweak launch configs, and guess why pylint isn't catching anything.

2. Dependency Management: Missing, Misconfigured, or Just Invisible

IntelliJ shows you:

Real-time dependency graphs
Conflicts between transitive and direct dependencies
Recommendations to remove unused packages
One-click updates
Vulnerability scanning (Ultimate edition)

VSCode gives you… the raw package.json, and maybe a terminal.

Need to find out if you’re using an outdated version of express, or if that left-pad package is still floating around doing nothing? You’ll need to:

Install some extensions (maybe)
Run CLI tools (probably)
Google half the errors when they break

It’s 2025, and managing dependencies in VSCode still feels like reading a package.json in Notepad.

3. Testing: Painfully Manual vs Seamless Integration

IntelliJ: You write tests. It discovers them. You click the green triangle. It shows test results with stack traces, variable values, and test history—all inline.

VSCode: Hope your language extension supports test discovery. Hope it integrates with your debugger. Hope it even knows what a "test" looks like. Otherwise, it’s back to terminal + npm test.

4. Code Intelligence and Refactoring

IntelliJ gives you:

Rename that works across files and modules
Safe refactoring with usage previews
Automatic method extraction
Inline documentation with type resolution
Semantic code search (e.g., “find all functions using X param pattern”)

VSCode? You can rename a variable. Most of the time.

Even with LSP-based extensions like Pyright or TS Server, you don’t get full project-wide understanding. IntelliJ is using a custom compiler per language to truly understand your project, not just parse symbols.

5. Debugging and Tooling Integration

IntelliJ has built-in:

Interactive debuggers
Coverage reports
Profiler
Local history (like git—but local and auto-saved)
Integration with Maven, Gradle, Docker, Kubernetes, Git, and more

VSCode can do some of this—but only with extensions, manual configuration, and in many cases, with a fraction of the stability. You’re building the tooling chain yourself—and it often breaks with updates.

So Why Do We Still Use VSCode?

Because it’s:

Fast
Lightweight
Highly customizable
Open-source
Has great community support
Easier to onboard juniors with
Doesn't need a beefy machine

But if you're working in real-world, multi-dependency, multi-environment projects—VSCode leaves a lot of heavy lifting to you. Especially when it comes to dependency and configuration intelligence.

Bridging the Gap: Introducing Depramanager

Bringing real dependency management to VSCode—without needing IntelliJ.

Depramanager is a free, open-source VSCode extension that adds actual dependency intelligence to your workflow.

Features:

Dependency Graphs
See what’s installed, declared, missing, or unused—at a glance.
Sync & Install
Automatically sync missing dependencies to your package.json, pyproject.toml, etc., or install manually from the editor.
Update Checker
Flags outdated packages and lets you update them with a click.
Security Scanning
Checks for known vulnerabilities across popular ecosystems.
Inline Highlights
Shows outdated or broken dependencies right inside the code editor.
Language-Aware Suggestions
Recommends VSCode extensions relevant to your project’s stack.

GitHub
Marketplace
Open vsix

Depramanager doesn’t try to make VSCode IntelliJ. It just fixes one of its most painful weaknesses.

Final Thoughts

VSCode is a beautiful tool. But let’s be honest—it’s not a full IDE. It can’t compete with IntelliJ on deep insight, project understanding, or smart refactoring out of the box.

But with the right tooling and extensions, you can bring some of that power to your daily workflow.

Use VSCode for what it does best. Use Depramanager to patch its biggest blind spot. And when you really need that fully-integrated IDE experience—don’t feel guilty booting up IntelliJ.

Animate Like a Pro: Build a Modern Scroll-Triggered Website with GSAP

Mon, 30 Jun 2025 06:17:22 +0000

Introduction

Modern websites aren’t just static layouts—they breathe, respond, and tell stories. In this guide, we’ll walk through how to build a modern, scroll-triggered, animation-rich website using GSAP (GreenSock Animation Platform).

Inspired by top-tier Awwwards websites, this post teaches you how to:

Animate text on page load

Trigger elements on scroll

Create parallax effects

Add interactive hover animations

Optimize for performance and responsiveness

All with clean code and professional structure.

Setting Up Your Project

Create your basic folder structure:

project/
├── index.html
├── styles.css
└── script.js

index.html

<section class="hero">
  <h1 class="headline">We Design for Impact</h1>
  <button class="cta">Discover More</button>
</section>

styles.css

body {
  margin: 0;
  font-family: 'Poppins', sans-serif;
  background: #121212;
  color: #fff;
}

.hero {
  min-height: 100vh;
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  text-align: center;
}

Include GSAP via CDN in your HTML:

<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/ScrollTrigger.min.js"></script>

Animate Hero Section with GSAP Timeline

Let’s animate the headline and button on page load using gsap.timeline():

const tl = gsap.timeline();

tl.from(".headline", {
  y: 100,
  opacity: 0,
  duration: 1.2,
  ease: "power4.out"
})
.from(".cta", {
  y: 20,
  opacity: 0,
  duration: 1,
  ease: "back.out(1.7)"
}, "-=0.5");

Result: Smooth fade-in entrance animation with professional timing and bounce.

ScrollTrigger Section Animations

Create reusable section reveals using ScrollTrigger:

<section class="section">About</section>
<section class="section">Projects</section>
<section class="section">Contact</section>

gsap.utils.toArray(".section").forEach(section => {
  gsap.from(section, {
    scrollTrigger: {
      trigger: section,
      start: "top 85%",
      toggleActions: "play none none reverse"
    },
    y: 100,
    opacity: 0,
    duration: 1
  });
});

Result: Each section fades and slides in when scrolled into view.

Create a Parallax Effect

Use a parallax background for depth:

<div class="parallax-wrapper">
  <img src="bg.jpg" class="bg-image" />
</div>

.parallax-wrapper {
  position: relative;
  height: 100vh;
  overflow: hidden;
}
.bg-image {
  position: absolute;
  width: 100%;
  top: 0;
  z-index: -1;
}

gsap.to(".bg-image", {
  scrollTrigger: {
    trigger: ".parallax-wrapper",
    scrub: true,
  },
  y: "-30%",
  ease: "none"
});

Result: Smooth scroll-linked background motion—eye-catching and modern.

Add Hover Animation to Elements

Create hover-based animations for interactive elements:

<div class="card">Hover me</div>

.card {
  width: 200px;
  height: 200px;
  background: #1e1e1e;
  display: flex;
  align-items: center;
  justify-content: center;
  transition: transform 0.3s;
}

document.querySelectorAll(".card").forEach(card => {
  card.addEventListener("mouseenter", () => {
    gsap.to(card, { scale: 1.05, duration: 0.3 });
  });
  card.addEventListener("mouseleave", () => {
    gsap.to(card, { scale: 1, duration: 0.3 });
  });
});

Result: Subtle interactivity that improves UX without overwhelming.

Responsive & Mobile Optimization

Use ScrollTrigger.matchMedia() to conditionally control animations based on screen size:

ScrollTrigger.matchMedia({
  "(min-width: 768px)": function() {
    gsap.from(".cta", {
      y: 50,
      opacity: 0,
      duration: 1,
      scrollTrigger: {
        trigger: ".cta",
        start: "top 80%"
      }
    });
  }
});

Pro Tip: Disable or simplify animations for low-powered mobile devices.

Final Touches & Best Practices

Use performance-friendly easing like "power2.out" or "none" for scroll-linked effects

Use will-change CSS property for elements that animate

Avoid layout jank: Animate transform, not top/left

Bonus: What Makes It Awwwards-Worthy?

Consistent motion rhythm

Smooth easing and microinteractions

Strategic use of white space and bold type

Layered visual depth (z-index, parallax, lighting)

✅ Conclusion

This step-by-step journey demonstrates how to transform basic markup into a sophisticated, animated web experience using GSAP. Whether you're enhancing a portfolio, creating a product landing page, or experimenting with scroll-based storytelling, GSAP and ScrollTrigger give you the control and fluidity needed to stand out.

Still.js - A way to leverage Vanilla JavaScript for Complex and Enterprise Level Web Development

Mon, 30 Jun 2025 00:03:03 +0000

When it comes to complex web application development on the frontend, we often encounter the need to implement features using vanilla JavaScript—whether it’s for direct DOM manipulation or integrating a specific jQuery plugin. Sometimes, a from-scratch implementation using plain HTML, CSS, and vanilla JavaScript is the best (or only) choice.

What is Still.js

Still.js is a modern Open Source framework that offers the same capabilities as Angular, React, and Vue—without abandoning vanilla JavaScript.

Because of its pure JS approach, Still.js:

Does not require preprocessing
Does not depend on bundlers like Webpack or Vite
Is ideal for teams and developers who prefer direct, no-compromise access to native web technologies in addition to those modern features a Web Framework provides.

Check it up:

Visit stilljs.dev or the github page
See youtube playlist
Join and discuss on
Discord channel
Still.js is an Open Source, contributions are welcomed, check the Github Repo

Suitable for complex and enterprise applications

Enterprise-grade web applications need more than just rich UI features. They require: modularization, user permission management, component routing, validation, separation of concern, communication management, Micro-frontend architecture (e.g. Frontend embedding and interaction), and more.

Still.js supports all of this features natively without the burden of a bundler increasing build time and potential complexity or even tooling overhead.

Some code samples

Note: Those will only work within a Still.js project with the correct setup, which is thoroughly explained in the official documentation.

Basic component:
Bellow is a simple component implementing a counter, inspite the template is placed inside the class, it can be moved to a .html file which is appropriate in complex apps.

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";

export class CounterComponent extends ViewComponent {

    isPublic = true;
    count = 0;

    template = `
    <div>
        <p>My counter state is @count</p>
        <button (click)="increment()">Increment (@count)</button>
    </div>
    `;

    increment() {
        this.count = this.count.value + 1;
    }
}

Basic User authorization management:
In the bellow implementation we're stating that some components won't be accessible by the user, this can be done with proper business logic according to the user role checking.

import { StillAppMixin } from "./@still/component/super/AppMixin.js";
import { Components } from "./@still/setup/components.js";
import { AppTemplate } from "./app-template.js";
import { CheckingAccount } from "./app/components/BankAccount/CheckingAccount.js";
import { NewAccountForm } from "./app/components/BankAccount/NewAccountForm.js";
import { SavingAccount } from "./app/components/BankAccount/SavingAccount.js";

export class StillAppSetup extends StillAppMixin(Components) {

    constructor() {
        super();
        //Bellow the entry point component is being set
        this.setHomeComponent(NewAccountForm);
        const blackListComponents = [SavingAccount, CheckingAccount];
        //Make components black-listed by passing it to setBlackList App configuration
        this.setBlackList(blackListComponents);
    }

    async init() {
        return await AppTemplate.newApp();
    }

}

Basic Form validation
Still.js provides built-in validators, but custom ones can be implemented effortlessly.

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";

export class BasicForm extends ViewComponent {

    isPublic = true;
    firstName = '';
    shoeSize;

    template = `
    <div>
        <form>
            <div class="form-group">
                <label>Shoe Size</label>
                <input 
                    (value)="shoeSize" 
                    (validator)="number" 
                    (validator-warn)="Invalid shoe size, number is required"
                    placeholder="Enter valid shoe size"
                >
            </div>
        </form>
    </div>
    `;

}

Global State management:
A service serves for both Global reactive storage and data flow (e.g. HTTP requests) implementations. Services path can be set in the application level, and we can overriden for specific service with @Path annotation.

import { ViewComponent } from "../../../@still/component/super/ViewComponent.js";
import { CustomersService } from "../../service/api/CustomersService.js";

export class BiddingDisplay extends ViewComponent {

    isPublic = true;

    /** Service declaration, will get injected automatically due to Inject anottation
     *  from the specified Path path due to the annotation
     * @Inject
     * @Path service/api/
     * @type { CustomersService } */
    custService;

    template = `<div></div>`;

    /** Component Hook which takes place when it's completly render and startder */
    stAfterInit() {

        this.custService.customerList.onChange((newValue) => { 
            console.log('Ths customerList store got updated with: ', newValue);
        });

    }

}

Hurry up, get yourself started with Still.js

Contribute for the project as you can, check the GitHub repository

Still.js is available through NPM on @stilljs/cli. Watch the Youtube ▶️ playlist and bear for more coming ones.

Watch this Tudo App tutorial on Youtube ▶️, clone or download the provided GitHub Todo app project and run locally. It demonstrates key concepts like component communication, event and state binding, reactive updates, @Proxy, and component styling.

Connect and share your feedback on the Discord channel.

Understanding JavaScript Prototypes: How Inheritance Works

Sat, 28 Jun 2025 10:38:24 +0000

Why You Should Understand Prototypes

When you start learning JavaScript, you’ll often hear this phrase:

In JavaScript, everything is an object.

But what’s often left out is how JavaScript handles inheritance not through classes (traditionally), but through prototypes.

In this post, we’ll explore:

What prototypes are
How the prototype chain works
__proto__ vs prototype
How JavaScript uses prototypes for inheritance
How ES6 classes relate to prototypes
When and why you should care

What Is a Prototype?

In JavaScript, every object has an internal link to another object called its prototype.
This prototype object can have its own prototype, forming a prototype chain. The chain ends when a prototype is null.

Think of it like a fallback mechanism — if a property or method isn’t found on an object, JavaScript looks up the chain.

Example

const person = {
  greet() {
    return "Hello!";
  }
};

const student = Object.create(person);
student.name = "Toni";

console.log(student.name);      // "Toni"
console.log(student.greet());  // "Hello!" (inherited from `person`)

Explanation

student doesn’t have greet()
JavaScript looks up the prototype chain (to person) and finds it there

The Prototype Chain in JavaScript

Every object in JavaScript has a hidden property [[Prototype]] (accessible via proto) that points to its prototype.

const obj = {};
console.log(obj.__proto__);             // Same as Object.prototype
console.log(obj.__proto__.__proto__);  // null (end of chain)

Diagram

student → person → Object.prototype → null

When you access student.greet(), JS will:

Look for greet in student
Not found? Check student.proto (which is person)
Still not found? Go up again (to Object.prototype)
If nowhere to be found → undefined

`proto` vs `prototype` : What’s the Difference?

This is a common confusion for new developers.

__proto__ The internal prototype of an instance

prototype A property on constructor functions used to create new instances

Example with Constructor

function Animal(name) {
  this.name = name;
}

Animal.prototype.speak = function () {
  return `${this.name} makes a noise.`;
};

const dog = new Animal("Rex");

console.log(dog.speak()); // "Rex makes a noise."
console.log(dog.__proto__ === Animal.prototype); // true

dog.__proto__ points to Animal.prototype, where speak() is defined.

ES6 Classes & Prototypes

class Vehicle {
  drive() {
    console.log("Vroom!");
  }
}

const car = new Vehicle();
car.drive(); // "Vroom!"

console.log(Object.getPrototypeOf(car) === Vehicle.prototype); // true

Even with class, JavaScript uses prototypes behind the scenes.

Why Use Prototypes?

Using prototypes provides several advantages:

Memory efficiency — methods are shared across instances
Performance — avoids recreating functions for every object
Structure — clear inheritance paths

Anti-pattern Example

function User() {
  this.sayHi = function () {
    console.log("Hi!");
  };
}

const u1 = new User();
const u2 = new User();

console.log(u1.sayHi === u2.sayHi); // false

Each sayHi is a separate function. That’s inefficient.

Recommended Prototype Approach

function User() {}
User.prototype.sayHi = function () {
  console.log("Hi!");
};

const u1 = new User();
const u2 = new User();

console.log(u1.sayHi === u2.sayHi); // true

Common Pitfalls When Using Prototypes

Avoid these mistakes when working with prototypes:

Don’t manually set __proto__ — use Object.create() or a proper constructor
Don’t overuse inheritance — favor composition where possible
Prototype chain lookups are slower than direct property access

Helpful Built-in Methods for Working with Prototypes

Object.create(proto)Creates a new object with a given prototype

Object.getPrototypeOf(obj)Returns the prototype of obj

Object.setPrototypeOf(obj, proto)Sets the prototype (avoid for performance reasons)

instanceofChecks if proto exists in the object’s prototype chain

hasOwnProperty()Checks if the property exists on the object itself, not its prototype

Debugging Prototype Issues

Use DevTools in your browser to inspect prototype chains.

Try these in the console:

Object.getPrototypeOf(obj);
obj.hasOwnProperty('prop');
console.dir(obj);

Conclusion

Understanding how JavaScript handles prototypes gives you the power to write clean, reusable, and performant code.

Key Takeaways

Every object in JS has a prototype, forming a chain
Inheritance flows up the prototype chain
Constructor functions and class use prototypes
Prototypes help reduce memory usage and improve structure
Don’t manually tinker with __proto__ — use proper patterns

If you’re still thinking only in classes, you’re missing JavaScript’s true inheritance model.

Turn Your Vue Web App into a Mobile App (Android & iOS) in Just 5 Minutes

Mon, 23 Jun 2025 15:49:53 +0000

In this quick tutorial, I’ll show you how to use CapacitorJS to convert your existing Vue.js web app into a fully functional mobile app for Android and iOS — without rewriting your codebase.

▶️ Watch the full tutorial here

This method is the fastest way to bring your frontend skills to mobile platforms using tools you already know.

Commands Used in This Video:
Install the Capacitor CLI locally

npm install -D @capacitor/cli
Initialize Capacitor in your Vue project

npx cap init
Install the required packages

npm install @capacitor/core @capacitor/ios @capacitor/android
Add native platforms

npx cap add ios
npx cap add android
Build and sync your app

npm run build
npx cap sync
Open the native projects in your IDE

npx cap open ios
npx cap open android
What is CapacitorJS and Why Use It?
CapacitorJS is a modern open-source native runtime developed by the Ionic team. It allows developers to build cross-platform mobile apps using web technologies like HTML, CSS, and JavaScript — without needing to rewrite your app in native languages such as Swift or Kotlin.

With Capacitor, your web app runs inside a native WebView container, enabling it to function like a true mobile app. Beyond just wrapping your app, Capacitor provides easy access to native device features like the camera, filesystem, geolocation, push notifications, and more through a rich plugin ecosystem.

Cross-Framework Compatibility
One of Capacitor’s biggest strengths is that it works with any modern JavaScript framework. Whether you are using:

Vue.js (like in this tutorial)
React
Angular
Svelte
Or even plain vanilla JavaScript
Capacitor can seamlessly integrate with your existing project. This flexibility means you don’t need to change your frontend framework or rewrite your codebase to build mobile apps — just add Capacitor and you’re good to go.

Why Choose Capacitor Over Other Solutions?
Compared to alternatives like Cordova, Capacitor is:

More modern and lightweight, built with a focus on web standards and developer experience
Better integrated with native SDKs, giving you easier access to device APIs
Supports live reload and faster development cycles
Actively maintained and backed by the Ionic team, ensuring ongoing support and improvements
How Capacitor Works Under the Hood
Capacitor takes your built web app (the static files you generate when you run npm run build) and packages it inside a native project shell for iOS and Android. This native shell includes:

A WebView component that loads your web app
A bridge that connects JavaScript code to native device APIs
Native projects that you can open and customize in Xcode (for iOS) or Android Studio (for Android)
This means your app behaves just like a native app on mobile devices but allows you to write your entire UI and logic in web languages.

What You Need to Get Started
Your web app ready to build (Vue, React, Angular, or vanilla JS)
Node.js and npm installed on your system
Android Studio and/or Xcode installed for running native projects
Basic familiarity with command-line tools
Wrapping Up
Using CapacitorJS, you can quickly turn your existing web app into a mobile app without the overhead of learning native development. This is a huge advantage for web developers looking to expand their reach to mobile users efficiently.

If you’re comfortable building with Vue (or any JavaScript framework), adding Capacitor to your workflow will open up new possibilities for app distribution on mobile platforms — faster and easier than ever before.

The Ultimate Front-end Challenge Is Live ON AquaScript

Sun, 22 Jun 2025 09:21:43 +0000

✨ Design. Innovate. Amaze. Become the Next AquaScript Champion.

Frontend Legends, Assemble!
The world of AquaScript just dropped a blazing new developer challenge – and this one’s all about bringing movies to life on the web. Get ready to dive into real API data, push your frontend limits, and build a mind-blowingly modern, fully responsive Movies Web App using AquaScript Movies Data APIs.

This is not just a challenge – it’s your gateway to dev stardom, portfolio power-ups, and a place in the AquaScript Hall of Fame.

What’s the Challenge?

Build a visually stunning, ultra-clean, and fully responsive Movies Website using AquaScript’s official Movies API or Movies+ API.
Your job? Create a masterpiece that makes users go “WOW!” the moment they land.

Use AquaScript API to pull live movie data and present it like a true frontend artist. We’re talking:

Grid-based movie layouts ️
Hover interactions & animations ✨
Mobile-first responsive magic
Custom fonts, AquaScript vibes, pro design
UI polish worthy of Dribbble

You’ve Got the Tools:

✅ AquaScript Movies API or Movies+ API
✅ Any frontend stack: HTML, CSS, JavaScript, Bootstrap, jQuery, Tailwind, etc.
❌ NO AI-generated code allowed – this is about your real skill
Pure creativity, real logic, responsive coding

The Rules You MUST Follow:

Your code must be clean, readable, and well-structured ✅
Design must be responsive across all screen sizes ✅
Use only AquaScript’s API (Movies or Movies+) ❗
Submit your entry via GitHub repository
Multiple submissions allowed – show us your full potential
Submit using the official Challenge Submission Form (on AquaScript)
No late entries will be accepted after the deadline is announced. ⏰

Note: The submission deadline & winner announcement date will be shared soon. Start building now!

Prizes That Level You Up Like Crazy:

First Place Winner:

Custom Domain – Own your dev identity
Free Promotion on AquaScript Platform
10 Pro Web Templates
Personalized Dev Portfolio
Hackathon Time Capsule Feature
Mini Workshop Hosting Opportunity
⚡ AquaScript Dev Boost Pack
Official “AquaScript Champion” Badge (PNG + HTML Embed)

Second Place:

Free Promotion on AquaScript
10 Pro Web Templates
Personalized Portfolio
Hackathon Time Capsule Feature
⚡ AquaScript Dev Boost Pack
Official Badge

Third Place:

Free Promotion
10 Pro Web Templates
Personalized Portfolio
Hackathon Time Capsule Entry
Official Badge

Submission Portal:

Head to https://aquascript.xyz → Find the Submission Form
Make sure your GitHub repo is clean, public, and includes:

Live Preview Link (if deployed)
README.md with clear instructions
Technologies Used
Screenshots (optional but impressive)

Questions?

Need help understanding the APIs or how to get started? Want to partner or collaborate?
Contact the AquaScript Team directly via the site or social platforms.

Are You the Next Frontend Icon?

Whether you’re a beginner looking to rise, or a pro dev ready to dominate – this is your moment.
Push pixels. Fetch data. Animate interfaces.
Build the Movies Experience the world hasn’t seen yet.

Challenge is officially live – Start Now. Build Bold. Win Big.

Shine bright, AquaScript Champion
— Team AquaScript

Code Rain’s Revelation: Embracing Existence Before Perfection

Tue, 27 May 2025 06:39:56 +0000

I would like to start this article by thanking the editorial team of JavaScript in Plain English for featuring my previous article on setting up a LLM chatbot as my editor. Within the article I mentioned turning the final draft into a script for video production, and I am in the process of finally taking the plunge. Now that I have the script done, what else is needed? Let’s start by building a short intro animation.

A cute illustration from Copilot on the topic

My Unexpected Journey: Why a Video Intro?

Despite hearing the suggestion numerous times, I never really considered going the video production route. The main reason was stated in the featured article — I am not ready to commit to a periodic release. Fast-forward to last weekend, I decided to publish my study notes on the book titled Dao of Functional Programming. Due to the complexity, I could only do it on an irregular basis. After publishing the first chapter, the implication became a big “Why not?” hovering in my mind.

Most of my recent articles are structured as a story writing project, including the one published last week. After publishing the article, I had the LLM chatbot assemble a video script out of the final draft. The proposed script, just as my previous attempts, appeared very actionable. After giving it a thought, I decided to bite the bullet.

As a sidenote, I definitely can see the appeal of the LLM especially for people working solo.

Though I may not be able to finish the video in time, I read through the script to figure out the needed components for a video. First thing I noticed is a short intro sequence. Shouldn’t be too difficult, I figured, there should be a generator somewhere over the Internet. Let’s quickly make one and be done with it. However, after some failed attempts with the LLM video generator, I decided to just make a simple animated sequence myself.

A code raining effect inspired by The Matrix, how hard can it be, right?

After checking through my weekly TODO, I only had one take-home assignment for a job application. Considering I did not have much idea on how to do it, I allocated a day for that. The point was getting a usable version out anyway. Fortunately, it was not that difficult, I managed to whip out a version with jQuery, lodash and Chance.js within a day.

Yes, it is a simple web application.

On the other hand, I find the project more interesting than the coding take-home assignment I did the next day. Most of these assignments are about creating a prototype website involving a variation of CRUD (Create, Retrieve, Update, Delete) operations from scratch. Usually that would take 2–3 days end-to-end but I often allocate at most a day and a half for them.

On the other end of the spectrum, we have overly extensive assignments that even the hiring company would expect more than a day of work. Job applicants are often not being paid for the work (hence my 1 day allocation), but in this climate many would still submit their work without compensation. Alongside other problems shared by many fellow engineers when applying jobs, it prompted me to rethink my strategy.

This blog was started as my part of a longer-term plan, exploring options outside software engineering. Recently it turned into an instrument I use to improve my visibility in the job market, showcasing my ability to hopefully avoid take-home assignment in future applications. Being featured in a well-established article is a very unexpected confidence boost, and I can’t express my gratitude enough for that.

Though it is equally important to acknowledge oneself internally.

While I still send out applications and meet folks for the possibility of collaboration, publishing content regularly is becoming a complement to my job hunting strategy. Producing video, in a way can be seen as an extension to all the technical writing I am doing here in this blog. A friend calls this “signalling”, but to me it is more an attempt to adapt.

The “Good Enough” Code Rain: Starting the Build

One common problem I often observe in life is that people often ask the wrong question “is it good?”, when there is nothing to improve on. This could be an oversimplification of life problems, but in my point of view, most things in life often boils down to either “does it exist” or “is it good?”. Both these questions are distinct from each other, but apparently enough people have a problem differentiating the two.

If there is one thing I learn, after meeting all the people approaching for project collaboration, that would be that ideas are worthless unless executed. There is never a shortage of brilliant ideas, the thing that is lacking is the will to bring them to reality. A conceived idea will inevitably grow over time and gets so ambitious such that it is close to impossible to begin working on it.

We do have a different name for this phenomenon — daydreaming.

The right question to start asking, in my humble opinion, is always “does it exist?”. In the case we are discussing today, it would be about the components of a video. There is none at the moment, so let’s start the collection and building. If the generator is not giving me the intro animation I wanted, then just build one myself, answer the existential question first.

And I did.

The crude initial version

It was a fairly simple animation featuring the code rain, ending with a display of the name of the channel. As mentioned earlier, it worked right away, which was good enough as a quick and dirty hack. Next the clip was uploaded t̶o̶ ̶s̶h̶o̶w̶ ̶o̶f̶f̶ ̶m̶y̶ ̶1̶3̶3̶7̶ ̶h̶a̶c̶k̶i̶n̶g̶ ̶s̶k̶i̶l̶l̶ to collect feedback from peers.

“Is it good enough?” should usually be asked, after answering the first “does it exist?” question. I fully expected to revisit the animation, addressing this question much later. In spite of that, Meta threw me a curveball after it ate my clips, returning an error saying I violate some rules. The linked help topic was a generic document on how to post videos.

Typical Meta, surprise surprise.

That prompted an immediate revision to the animation. If Meta doesn’t like the short clip, it means any uploaded videos containing the clip would be banned as well. To a certain extent, this is a blessing in disguise, I did receive feedback, though in the most unexpected way. Imagine how devastating this could be if I spent my whole life planning for it, only to find the work banned right away.

There are indeed rare occasions where these two should be considered in parallel. Yet, for most cases, where time and resources are limited, the two questions should be addressed separately, in the right order. We can spend our lifetime pondering how things can be perfected, but it changes nothing if no work is being laid out.

Existence != Perfection

Crafting the Rain: Modules, Events, and Iteration

This is the meta-approved (for now) version.

Meta-approved revision

Still based on the same code rain animation, but I am turning the channel name display into an ASCII art, and including the display of a video title. An outro is also added so it doesn’t end abruptly. Let’s discuss the implementation a little bit.

Coders writing for Node.js should be familiar with the module syntax ,,) shown below:

import defaultExport from './someModule';
import { otherExport } from './someModule';

const bar = 'bar';

export function foo() {
    ...
}

export default bar

Frontend development gets increasingly more complex over time. Gone are the days where all the frontend logic is expressed within one script alone. As the complexity grows, the amount of code also increases. Separating them into smaller parts eventually becomes a necessity.

So the module syntax is a welcome change, though I only knew the support was ported to the browser while I was porting grid-maker last week. All it needs is to change the tag’s type attribute to module.

<script type="module" src="./someModule.js"></script>

Alternatively, you can just put the code inline

<script type="module">
import defaultExport from './someModule`;
import { otherExport } from './someModule';

const bar = 'bar';
export function foo() {
    ...
}
export default bar
</script>

No more multiple tags just to import different libaries, we now do it with the import statements, as it also supports importing from a URL. For example, to import functions from lodash, we write:

import {
range,
reverse,
} from "https://cdn.jsdelivr.net/npm/lodash-es@4.17.21/lodash.min.js";

The intro animation script was largely inspired by the grid-maker remake. Any changes to the DOM would be initiated by event triggerings. So we are making a rather simple code rain animation in a 2D grid of monospaced characters. A “raindrop” effect is just a column of characters in the grid “activated” (fading in and out) one after another. We could chain all these activations together in a sequence of nested recursive function calls, risking blowing the stack if the number of rows increases.

function activate_rain(char_in_grid) {
  const downstair_char = find_downstair_char(char_in_grid)

  do_the_animation(char_in_grid)

  if (downstair_char) {
    activate(downstair_char)
  }
}

Alternatively, we could let each activation trigger another activation below it by dispatching an event.

function activate_rain(event) {
  const elem = $(event.target);

  do_the_animation(elem);

  find_downstair_char(elem).trigger("block:activate:rain");
}

I did this in jQuery despite last week’s article, mainly because this is not meant to be deployed in a production environment. The function activate_rain was registered as a listener to the block:activate:rain, therefore firing the same event (after a delay) for the neighbour. The function exits after the dispatching of event, removing the risk of stack overflow. In the actual implementation, I also added a delay through setTimeout to the event dispatching to adjust the downward speed of a raindrop.

setTimeout(() => find_downstair_char(elem).trigger("block:activate:rain"), 100);

The full implementation can be reviewed at my GitHub repository ..) Feel free to adapt and play with it. You may want to find a way to start a web server to serve the page to test it in your browser.

The Code Rain’s Enduring Lesson: Execute First, Then Refine

My editor insisted this is needed again here.

Initially I intended this to be a quick article on the making of the animation for the video production side-project. However the scope of the article grew when I was organizing my thoughts. For some reason it reminded me of a quick exchange on the two questions “does it exist?” and “is it good?” with my mentor not too long ago.

We live in a very short-tempered world, where we expect things out fast and good. Sometimes it gets really easy to forget the difference between the two, especially when deadlines are approaching. Mixing the two up in such cases would inevitably generate a huge amount of stress. Even I find myself caught in situations like this before.

The unexpected connection between my simplistic problem-solving view and the animation-making process was a surprising discovery. If the banning accident did not happen, I wouldn’t be able to make the connection, and we would read a very different article this week. Despite a round of revision, there are still numerous improvements I hope to achieve with it. Still, having it done checks an item of my TODO for a final video.

I will pick an older article, and produce a video out of it with the help of LLM drafting the script. As it is going to be irregular, the review will come a little bit later, perhaps until I am more comfortable with the workflow. For now stay tuned, and thanks for reading this far. I shall meet you in my writing again, next week.

While an AI editorial assistant helped refine this article’s language and structure, please know that my voice, ideas, and all code are entirely my own work. If KitFu Coda sparks your interest, feel free to reach out for job opportunities or project collaborations directly on Medium or via LinkedIn.

Coder Legion - Recent posts tagged frontenddevelopment

🔥 30 Days of Frontend — Day 5: React DevTools Profiler

1. What Is the React DevTools Profiler?

2. Understanding How React Rendering Relates to Profiling

The render phase

The commit phase

3. What Can You Learn From the Profiler?

A. Which components rendered?

B. How often did components render?

C. What caused a component to render?

4. How to Use React DevTools Profiler: A Step-by-Step Workflow

Step 1: Reproduce the actual performance problem

Step 2: Open React DevTools

Step 3: Start recording

Step 4: Inspect the recorded commits

Step 5: Make one targeted change

Step 6: Profile again

🔥 30 Days of Frontend — Day 4: Memoization in React

1. What Is Memoization?

2. useMemo: Cache an Expensive Calculation

What changed?

An important limitation

3. useCallback: Cache a Function Reference

What about dependencies?

4. React.memo: Skip Unnecessary Component Renders

A common mistake: unstable object props

5. How These Three APIs Work Together

6. When Memoization Doesn't Help

7. React Compiler Changes the Conversation

8. Final Takeaway

🔥 30 Days of Frontend — Day 2: React Reconciliation

🧠 A Simple Example

🔑 Why Do Keys Matter?

🧩 A Useful Mental Model

⚙️ Where Does Reconciliation Happen?

🎯 The Takeaway

SEO Basics Every Frontend Developer Should Know

Introduction

1. Semantic HTML (This Matters More Than You Think)

Rules to follow:

2. Meta Tags (The Basics Actually Matter)

3. Image Alt Text

4. Page Speed (A Direct Ranking Factor)

5. Mobile-Friendliness

6. Clean, Descriptive URLs

7. Internal Linking

8. Structured Data (Optional but Powerful)

Common Beginner Mistakes

Final Thoughts

No More Fake DOM: Testing Library Unit Tests in the Real Browser

Why this works at all

The setup

Two traps

Both kinds of test, one run

Where each style fits

Try it

How I Landed My First Freelance Client as a Frontend Developer

Introduction

Where I Started

What Didn't Work

What Actually Worked

1. I Stopped Applying Blind and Started Researching the Client First

2. I Led With a Live Demo, Not Just a Portfolio Link

3. I Asked for a Testimonial Immediately After Finishing

4. I Treated the First Project as a Portfolio Investment, Not Just a Paycheck

What I'd Tell Beginners Specifically

Final Thoughts

How to Build a Portfolio Website That Actually Gets You Hired

Introduction

What a Portfolio Is Actually For

The Sections That Actually Matter

1. A Clear Headline (Not Just Your Name)

2. 3-5 Real Projects (Quality Over Quantity)

3. About Section (Keep It Short and Human)

4. Clear Contact Options

What to Leave Out

Technical Details That Quietly Matter

Real Example: My Own Approach

Common Beginner Mistakes

Final Thoughts

2. `useMemo`: Cache an Expensive Calculation

3. `useCallback`: Cache a Function Reference

4. `React.memo`: Skip Unnecessary Component Renders