Build a Minimal Crypto Dashboard with CCXT, CoinGecko and React

Mon, 08 Jun 2026 00:00:00 GMT

Introduction

In this tutorial, we are going to build a small crypto dashboard that shows live coin prices in a compact table and displays a candlestick chart for the selected coin.

The idea is simple:

use CCXT as the main market data source;
use CoinGecko as a fallback when the exchange does not have a required pair;
use fetchOHLCV to load candlestick data;
use React Query to refresh prices automatically;
render candles with Lightweight Charts;
make the UI clean, compact and monochrome.

By the end, we will have a small dashboard where the table sits on the left, the chart sits on the right, and clicking a coin updates the active chart.

The complete source code for this project is available on GitHub.

Step 1: Create the Project

Start with a React + TypeScript Vite project:

npm create vite@latest crypto-dashboard -- --template react-ts
cd crypto-dashboard

Install the packages:

npm install ccxt express cors @tanstack/react-query lightweight-charts concurrently tsx
npm install -D @types/express @types/cors

We need:

ccxt for exchange market data;
express for the local API;
cors so the React app can call the API;
@tanstack/react-query for polling and caching;
lightweight-charts for the candlestick chart;
concurrently to run frontend and backend together;
tsx to run the TypeScript server directly.

Step 2: Add Scripts

Update package.json:

{
  "scripts": {
    "dev": "concurrently \"npm run dev:client\" \"npm run dev:server\"",
    "dev:client": "vite",
    "dev:server": "tsx watch server/index.ts",
    "build": "tsc -b && vite build",
    "preview": "vite preview"
  }
}

Now one command starts both the frontend and the backend:

npm run dev

Step 3: Create the Backend API

Create a new file:

server/index.ts

Add the base Express server:

import express from "express";
import cors from "cors";
import * as ccxt from "ccxt";

const app = express();

app.use(cors());

const exchange = new ccxt.bitget({
  enableRateLimit: true,
});

app.listen(4000, () => {
  console.log("API running on http://localhost:4000");
});

We are using Bitget here because it works well for public market data and does not require an API key for tickers or candles.

Step 4: Define the Watchlist

Add a small watchlist:

type WatchAsset = {
  symbol: string;
  pair: string;
  geckoId: string;
};

const watchlist: WatchAsset[] = [
  { symbol: "BTC", pair: "BTC/USDT", geckoId: "bitcoin" },
  { symbol: "ETH", pair: "ETH/USDT", geckoId: "ethereum" },
  { symbol: "SOL", pair: "SOL/USDT", geckoId: "solana" },
  { symbol: "DOGE", pair: "DOGE/USDT", geckoId: "dogecoin" },
  { symbol: "TAO", pair: "TAO/USDT", geckoId: "bittensor" }
];

Each coin has three fields:

symbol is what we show in the UI;
pair is what CCXT uses;
geckoId is what CoinGecko uses.

This small mapping is important because exchanges and CoinGecko do not use the same identifiers.

Step 5: Add CoinGecko Fallback

Sometimes a coin exists on CoinGecko but does not have a liquid pair on the exchange we use. Instead of failing, we can fallback to CoinGecko.

Add this helper:

async function getCoinGeckoPrices(ids: string[]) {
  if (ids.length === 0) return {};

  const url = new URL("https://api.coingecko.com/api/v3/simple/price");

  url.searchParams.set("ids", [...ids, "tether"].join(","));
  url.searchParams.set("vs_currencies", "usd");
  url.searchParams.set("include_24hr_change", "true");
  url.searchParams.set("include_24hr_vol", "true");

  const response = await fetch(url);

  if (!response.ok) {
    throw new Error("CoinGecko request failed");
  }

  const data = await response.json();
  const tetherUsd = data.tether?.usd ?? 1;

  return Object.fromEntries(
    Object.entries(data).map(([id, value]: any) => [
      id,
      {
        price: value.usd / tetherUsd,
        change24h: value.usd_24h_change ?? null,
        volume: value.usd_24h_vol ?? null
      }
    ])
  );
}

CoinGecko returns prices in USD. Exchange pairs usually come in USDT. For a small dashboard, USD and USDT are often close enough, but we can still normalize CoinGecko values by dividing them by the current Tether price.

Step 6: Create the Prices Endpoint

Now add /api/prices:

app.get("/api/prices", async (_req, res) => {
  try {
    await exchange.loadMarkets();

    const pairs = watchlist.map((asset) => asset.pair);
    const tickers = await exchange.fetchTickers(pairs);

    const missingGeckoIds: string[] = [];

    for (const asset of watchlist) {
      if (!tickers[asset.pair]?.last) {
        missingGeckoIds.push(asset.geckoId);
      }
    }

    const geckoPrices = await getCoinGeckoPrices(missingGeckoIds);

    const prices = watchlist.map((asset) => {
      const ticker = tickers[asset.pair];
      const gecko = geckoPrices[asset.geckoId] as any;

      return {
        symbol: asset.symbol,
        pair: asset.pair,
        source: ticker?.last ? "ccxt" : "coingecko",
        price: ticker?.last ?? gecko?.price ?? null,
        high24h: ticker?.high ?? null,
        low24h: ticker?.low ?? null,
        change24h: ticker?.percentage ?? gecko?.change24h ?? null,
        volume: ticker?.quoteVolume ?? gecko?.volume ?? null
      };
    });

    res.json(prices);
  } catch (error) {
    console.error(error);
    res.status(500).json({ error: "Failed to load prices" });
  }
});

The flow is:

Load exchange markets.
Request tickers from CCXT.
Find missing pairs.
Request missing prices from CoinGecko.
Merge both sources into one response.

The frontend does not need to know how complicated the data fetching is. It receives one clean array.

Step 7: Add Candlestick Data with `fetchOHLCV`

For the chart, add another endpoint:

app.get("/api/candles/:symbol", async (req, res) => {
  try {
    await exchange.loadMarkets();

    const coin = req.params.symbol.toUpperCase();
    const pair = `${coin}/USDT`;

    if (!exchange.markets[pair]) {
      return res.status(404).json({
        error: `No ${pair} market on Bitget`
      });
    }

    const timeframe = String(req.query.timeframe ?? "1m");
    const limit = Number(req.query.limit ?? 120);

    const candles = await exchange.fetchOHLCV(
      pair,
      timeframe,
      undefined,
      limit
    );

    const result = candles.map(([time, open, high, low, close, volume]) => ({
      time: Math.floor(time / 1000),
      open,
      high,
      low,
      close,
      volume
    }));

    res.json(result);
  } catch (error) {
    console.error(error);
    res.status(500).json({ error: "Failed to load candles" });
  }
});

fetchOHLCV returns arrays in this format:

[
  timestamp,
  open,
  high,
  low,
  close,
  volume
]

Lightweight Charts expects candle data as objects, so we convert the array into a cleaner structure.

Step 8: Create Frontend API Helpers

Howto Find the Start of a Cycle in a Linked List

Wed, 03 Jun 2026 00:00:00 GMT

Linked lists are one of the most common data structures used in coding interviews, and cycle detection is one of the most frequently asked problems.

At first glance, the challenge seems simple: determine whether a linked list contains a loop. However, many interviewers take the problem one step further and ask you to find the exact node where the cycle begins.

The naive solution is to store every visited node inside a hash set and check whether you've seen a node before. While that works, it requires additional memory.

A much more elegant solution uses Floyd’s Cycle Detection Algorithm, also known as the Tortoise and Hare Algorithm. This approach requires no extra storage and can both detect a cycle and locate its starting point.

The Problem

Given the head of a singly linked list, return the node where a cycle begins.

If no cycle exists, return null.

Example 1

Input:
3 → 2 → 0 → -4
    ↑       ↓
    └───────┘

Output:
Node with value 2

Example 2

Input:
1 → 2
↑   ↓
└───┘

Output:
Node with value 1

Example 3

Input:
1 → null

Output:
null

Why a Normal Traversal Doesn't Work

In a regular linked list, traversal eventually reaches null.

let currentNode = head;

while (currentNode) {
  currentNode = currentNode.next;
}

When a cycle exists, the traversal never terminates.

1 → 2 → 3 → 4
    ↑       ↓
    └───────┘

The pointer keeps moving forever.

This means we need a smarter approach.

Floyd's Fast and Slow Pointer Technique

The core idea is simple.

Create two pointers:

slowRunner moves one node at a time
fastRunner moves two nodes at a time

If the list contains a cycle, the faster pointer will eventually catch the slower pointer.

If the list has no cycle, the fast pointer will reach the end of the list.

Visual Example

1 → 2 → 3 → 4 → 5
        ↑       ↓
        └───────┘

Iteration 1:

slowRunner = 2
fastRunner = 3

Iteration 2:

slowRunner = 3
fastRunner = 5

Iteration 3:

slowRunner = 4
fastRunner = 4

The pointers meet.

Once they meet, we know a cycle exists.

Finding the Entry Point of the Cycle

Detecting the cycle is only half of the problem.

The next challenge is determining where the loop begins.

After the first meeting:

Leave one pointer at the meeting point.
Move another pointer back to the head.
Advance both pointers one step at a time.
The node where they meet again is the cycle entry.

Why Does This Work?

Assume:

a = distance from head to cycle entry
b = cycle length
c = distance from cycle entry to the meeting point

When the two pointers meet:

slow distance = a + c

fast distance = a + c + k × b

Because the fast pointer moves twice as quickly:

2(a+c)=a+c+kb

Rearranging gives:

a = kb - c

This means the distance from the head to the cycle entry is exactly equal to the distance from the meeting point back to the cycle entry when moving around the loop.

As a result, one pointer starting from the head and another starting from the meeting point will arrive at the cycle entry simultaneously.

JavaScript Solution

/**
 * Definition for singly linked list.
 * function ListNode(value, nextNode) {
 *   this.val = value ?? 0;
 *   this.next = nextNode ?? null;
 * }
 */

/**
 * @param {ListNode} head
 * @returns {ListNode | null}
 */
function findCycleStart(head) {
  let slowRunner = head;
  let fastRunner = head;

  while (fastRunner && fastRunner.next) {
    slowRunner = slowRunner.next;
    fastRunner = fastRunner.next.next;

    if (slowRunner === fastRunner) {
      let pointerFromHead = head;
      let pointerFromMeeting = slowRunner;

      while (pointerFromHead !== pointerFromMeeting) {
        pointerFromHead = pointerFromHead.next;
        pointerFromMeeting = pointerFromMeeting.next;
      }

      return pointerFromHead;
    }
  }

  return null;
}

Step-by-Step Walkthrough

Consider the following linked list:

3 → 2 → 0 → -4
    ↑       ↓
    └───────┘

Phase 1: Detect the Cycle

slowRunner:
3 → 2 → 0 → -4 → 2

fastRunner:
3 → 0 → 2 → -4 → 2

Eventually both pointers meet inside the loop.

Phase 2: Locate the Entry

Reset one pointer:

pointerFromHead = 3
pointerFromMeeting = meeting node

Move both one step at a time:

pointerFromHead:
3 → 2

pointerFromMeeting:
0 → -4 → 2

Both arrive at node 2.

That node is returned as the cycle entry.

Alternative Solution Using a Hash Set

Another common approach stores every visited node.

function findCycleStart(head) {
  const visitedNodes = new Set();

  let currentNode = head;

  while (currentNode) {
    if (visitedNodes.has(currentNode)) {
      return currentNode;
    }

    visitedNodes.add(currentNode);
    currentNode = currentNode.next;
  }

  return null;
}

Pros

Easy to understand
Easy to implement

Cons

Requires additional memory
Space complexity becomes O(n)

For interview settings, Floyd's algorithm is generally preferred.

Complexity Analysis

Operation	Complexity
Time Complexity	O(n)
Space Complexity	O(1)

The algorithm performs at most two traversals:

Detecting the cycle.
Finding the cycle entry.

No extra data structures are required.

Common Interview Questions

Why do the pointers always meet when a cycle exists?

Because the fast pointer gains one node on the slow pointer during each iteration inside the loop. Eventually it catches up.

Why reset one pointer to the head?

The mathematical relationship between the meeting point and cycle entry guarantees that both pointers will reach the entry node at the same time when moving at equal speed.

Can this problem be solved without Floyd's algorithm?

Yes. A hash set can track visited nodes.

However:

Hash Set:
Time  = O(n)
Space = O(n)

Floyd:
Time  = O(n)
Space = O(1)

The Floyd solution is more efficient.

What prevents the fast pointer from causing errors?

The loop condition ensures safe access:

while (fastRunner && fastRunner.next)

This guarantees that fastRunner.next.next is only accessed when valid.

Final Thoughts

Finding the start of a cycle in a linked list is one of the most important linked-list interview problems. The challenge combines pointer manipulation, algorithmic thinking, and a clever mathematical insight.

The key idea is straightforward:

Use a slow pointer moving one step at a time.
Use a fast pointer moving two steps at a time.
Detect the meeting point.
Reset one pointer to the head.
Move both pointers at the same speed.
Their next meeting point is the beginning of the cycle.

This elegant technique runs in O(n) time, uses O(1) extra space, and is considered the standard soluti…

How to Build Smooth Scrolling Interfaces with CSS Scroll Snap

Tue, 02 Jun 2026 00:00:00 GMT

Master native scroll snapping in CSS to create smooth sliders, paginated sections, and polished scrolling experiences without heavy JavaScript libraries.

Introduction

Modern interfaces rely heavily on scrolling.

Horizontal product sliders, onboarding screens, fullscreen storytelling pages, mobile galleries, and swipeable dashboards all depend on movement that feels deliberate and predictable. Users expect content to land neatly into place instead of stopping awkwardly between elements.

For years, developers solved this with JavaScript libraries, custom event listeners, and complicated calculations. That approach works, but it often creates extra maintenance, accessibility problems, and performance issues on mobile devices.

CSS Scroll Snap gives us a better option.

Instead of manually calculating scroll positions, you can define snap points directly in CSS and let the browser handle the alignment. The result is cleaner code, better performance, and a smoother user experience.

In this guide, you will learn how CSS Scroll Snap works, how to configure it properly, and how to use it in real production scenarios such as carousels, galleries, and full-page layouts.

What Is CSS Scroll Snap?

CSS Scroll Snap is a native CSS feature that controls how scrolling behaves inside a scrollable container.

You define a scrollable parent, configure the snapping behavior, and then tell child elements where they should align when scrolling stops. Once those rules are in place, the browser automatically moves the scroll position toward the closest snap point.

Think of it like invisible magnetic points attached to your layout. Instead of the scroll ending in a random position, the content lands exactly where you want it.

This is useful for interfaces where visual rhythm matters:

horizontal carousels
image galleries
onboarding screens
fullscreen page sections
mobile navigation layouts
step-based tutorials
dashboard panels

The best part is that many of these patterns can be created without a slider library.

The Basic Structure

Every CSS Scroll Snap layout has two main parts.

First, you need a scroll container. This element must have overflow enabled and a scroll-snap-type value.

Second, you need snap children. These elements usually use scroll-snap-align to define where they should lock into place.

.snap-container {
  overflow-x: auto;
  scroll-snap-type: x mandatory;
}

.snap-item {
  scroll-snap-align: center;
}

This small amount of CSS already creates a basic horizontal snapping layout.

The container says: “scroll horizontally and snap strictly.”

Each child says: “when snapping happens, align me to the center.”

Understanding `scroll-snap-type`

The most important property is scroll-snap-type.

It tells the browser two things:

which axis should snap
how strict snapping should be

The syntax looks like this:

.gallery-track {
  scroll-snap-type: x mandatory;
}

The first value controls direction.

Use x for horizontal snapping:

.product-row {
  scroll-snap-type: x mandatory;
}

Use y for vertical snapping:

.page-sections {
  scroll-snap-type: y mandatory;
}

Use both when the container can scroll in both directions:

.canvas-grid {
  scroll-snap-type: both proximity;
}

You can also use logical values such as block and inline, which follow the document writing mode. For most everyday layouts, x and y are easier to understand and maintain.

Mandatory vs Proximity Snapping

The second value controls how strongly the browser should snap.

The mandatory value forces the scroll position to land on a snap point.

.carousel {
  scroll-snap-type: x mandatory;
}

This is useful when precision matters. Carousels, onboarding screens, and page-by-page interfaces usually feel better with mandatory snapping because every movement has a clear destination.

The proximity value is softer.

.gallery {
  scroll-snap-type: x proximity;
}

With proximity snapping, the browser only snaps when the final scroll position is already close to a snap point. This feels more natural for galleries or layouts where users may want a little more freedom.

A good rule is simple: use mandatory for strict step-based interfaces and proximity for exploratory browsing.

Using `scroll-snap-align`

Once the container knows how to snap, the child elements need to define where they should align.

That is the job of scroll-snap-align.

.feature-card {
  scroll-snap-align: center;
}

Common values include:

start
center
end
none

Use start when each item should align with the beginning of the scroll container.

.chapter {
  scroll-snap-align: start;
}

This is common in full-page vertical layouts where every section should begin at the top of the viewport.

Use center when the item should land in the middle.

.showcase-slide {
  scroll-snap-align: center;
}

This works well for carousels, product cards, and image previews.

Use end less often, but it can be helpful for right-aligned panels or special reading layouts.

Building a CSS-Only Product Carousel

Let’s build a practical carousel using only HTML and CSS.

This example is intentionally simple, but the structure is close to what you might use in a real interface.

<section class="product-carousel" aria-label="Featured products">
  <article class="product-card">Mechanical Keyboard</article>
  <article class="product-card">Studio Monitor</article>
  <article class="product-card">Wireless Mouse</article>
  <article class="product-card">USB-C Dock</article>
  <article class="product-card">Laptop Stand</article>
</section>

Now add the CSS:

.product-carousel {
  display: flex;
  gap: 24px;
  overflow-x: auto;
  padding: 24px;
  scroll-snap-type: x mandatory;
  scroll-behavior: smooth;
  scrollbar-width: none;
  -webkit-overflow-scrolling: touch;
}

.product-carousel::-webkit-scrollbar {
  display: none;
}

.product-card {
  flex: 0 0 320px;
  height: 220px;
  display: grid;
  place-items: center;
  border-radius: 18px;
  color: white;
  font-size: 1.4rem;
  font-weight: 700;
  scroll-snap-align: center;
  background: linear-gradient(135deg, #2563eb, #7c3aed);
  box-shadow: 0 16px 40px rgb(15 23 42 / 18%);
}

This gives you a clean horizontal carousel.

The container uses overflow-x: auto, which creates the horizontal scrolling area. The scroll-snap-type: x mandatory rule tells the browser to snap horizontally. Each card uses scroll-snap-align: center, so cards land in the middle of the visible area.

There is no custom JavaScript and no dependency on a carousel package.

Improving the Carousel for Real Projects

A real carousel often needs better spacing on small screens. You can adjust the card width with clamp() so the layout adapts naturally.

.product-card {
  flex: 0 0 clamp(240px, 75vw, 360px);
}

This means the card …

Next.js App Router Caching: Why Your Data Stayed Stale

Mon, 01 Jun 2026 00:00:00 GMT

Caching in Next.js usually becomes confusing for the same reason: several different systems can produce almost identical behavior.

Your API already returns new data.

You refresh the page.

The UI still shows an older value.

You immediately add:

fetch(endpoint, { cache: "no-store" })

Everything starts working.

Problem solved.

Until the next question appears:

If every request bypasses caching, why does Next.js ship with an entire caching model in the first place?

The answer is simpler than it first looks.

In App Router, “caching” is not one feature.

Different layers can influence what you see:

client navigation reuse
route rendering behavior
server-side fetch caching
time-based revalidation

If you treat them as one mechanism, debugging quickly becomes frustrating.

The easiest way to understand caching is not through diagrams or definitions.

It is through observation.

Step One: Detect Whether the Server Rendered Again

Before debugging data, verify whether the page actually executed on the server.

Create a small render indicator.

// app/components/ServerRenderBadge.tsx

type ServerRenderBadgeProps = {
  name?: string;
};

export function ServerRenderBadge({
  name = "server render",
}: ServerRenderBadgeProps) {
  const serverRenderedAt = new Date().toISOString();

  return (
    <p className="text-xs text-slate-500">
      {name}: <code>{serverRenderedAt}</code>
    </p>
  );
}

This component runs on the server.

Every time the route truly renders again, the timestamp changes.

Use it inside multiple routes.

// app/catalog/page.tsx

<ServerRenderBadge name="/catalog render" />

// app/catalog/[id]/page.tsx

<ServerRenderBadge name="/catalog/[id] render" />

Now perform a simple navigation test:

Open /catalog
Visit an item page
Press Back
Open the same item again
Reload the browser tab

You will notice an important distinction.

Back navigation may preserve the same timestamp.

Reload often produces a new one.

That alone reveals something important:

seeing a page again does not automatically mean the server rendered it again.

Already, you have separated navigation behavior from rendering behavior.

Rendering Freshness and Data Freshness Are Different Signals

Knowing whether a render happened is useful.

But most debugging sessions are really about something else:

Did a fresh API response arrive?

Add a second marker inside your data layer.

Instead of exposing only JSON, return debugging metadata together with the response.

// app/lib/catalog-api.ts

const CATALOG_API_URL = "https://dummyjson.com";

type RequestDebugInfo<T> = T & {
  _debug: {
    receivedAt: string;
    cacheTtl?: number;
    validUntil?: string;
  };
};

async function requestCatalog<T>(
  path: string,
  init?: RequestInit & {
    next?: {
      revalidate?: number;
    };
  }
): Promise<RequestDebugInfo<T>> {
  const response = await fetch(
    `${CATALOG_API_URL}${path}`,
    init
  );

  if (!response.ok) {
    throw new Error(
      `Catalog request failed: ${response.status}`
    );
  }

  const receivedAt =
    response.headers.get("date") ??
    new Date().toUTCString();

  const payload = await response.json();

  return {
    ...payload,
    _debug: {
      receivedAt,
    },
  };
}

Display the metadata alongside the render marker.

<div className="space-y-2 text-sm">
  <p>
    API response received:
    <code>{item._debug.receivedAt}</code>
  </p>

  <ServerRenderBadge
    name="product page render"
  />
</div>

Now you have two independent measurements:

ServerRenderBadge → did the route render?
receivedAt → did a new network response arrive?

That distinction changes the entire debugging experience.

Because a page can absolutely render again while still serving cached data.

That is usually where the “Next.js is stuck” feeling comes from.

`force-cache`: The UI Updates, the Network Request Doesn't

Start with explicit caching.

Create a reusable cache profile helper.

// app/lib/cache-profile.ts

type CacheMode =
  | { strategy: "cached" }
  | { strategy: "live" }
  | {
      strategy: "timed";
      ttl: number;
    };

function buildFetchPolicy(
  mode: CacheMode
): RequestInit {
  switch (mode.strategy) {
    case "live":
      return { cache: "no-store" };

    case "timed":
      return {
        next: {
          revalidate: mode.ttl,
        },
      };

    default:
      return {
        cache: "force-cache",
      };
  }
}

Use it in your data loader.

// app/lib/products.ts

export async function loadProductDetails(
  productId: string
) {
  return requestCatalog(
    `/products/${encodeURIComponent(
      productId
    )}`,
    buildFetchPolicy({
      strategy: "cached",
    })
  );
}

Build the application and run production mode.

npm run build
npm start

Now reload the same page several times.

You may observe something like:

product page render:
13:42:18

API response received:
13:37:04

Reload again:

product page render:
13:42:33

API response received:
13:37:04

The render changed.

The response timestamp did not.

That tells you exactly what happened.

The route executed again.

The fetch layer reused cached data.

This is not broken behavior.

It is precisely what force-cache is designed to do.

`no-store`: When Every Request Must Be Fresh

Some pages cannot tolerate stale data.

Switch the loader to a live profile.

export async function loadProductDetails(
  productId: string
) {
  return requestCatalog(
    `/products/${productId}`,
    buildFetchPolicy({
      strategy: "live",
    })
  );
}

Test reload behavior again.

Now the signals move together.

render:
14:02:11

received:
14:02:11

Reload:

render:
14:02:19

received:
14:02:19

Every request performs a new fetch.

This is useful for:

account balances
order states
admin dashboards
user-specific operational data
real-time internal tools

But freshness comes with a cost.

More requests.

More external API pressure.

Lower reuse efficiency.

For many public pages, this is unnecessary overkill.

`revalidate`: Usually the Practical Choice

Most applications need something between permanent reuse and constant refetching.

That is where timed revalidation becomes valuable.

Extend the response metadata.

async function requestCatalog<T>(
  path: string,
  init?: RequestInit & {
    next?: {
      revalidate?: number;
    };
  }
) {
  const response = await fetch(
    `${CATALOG_API_URL}${path}`,
    init
  );

  const receivedAt =
    response.headers.get("date") ??
    new Date().toUTCString();

  const ttl =
    init?.next?.revalidate;

  const validUntil =
    typeof ttl === "number"
      ? new Date(
          Date.parse(receivedAt) +
            ttl * 1000
        ).toUTCString()
      : undefined;

  const data = await response.json();

  return {
    ...data,
    _d…

Protecting Next.js Applications in the Era of Server Actions
Thu, 28 May 2026 00:00:00 GMT
The New Frontend Security Model
Frontend security used to feel relatively straightforward.
A few years ago, the architecture looked familiar.
You had:

a SPA running in the browser
a backend API somewhere else
JWT authentication
CORS policies
REST endpoints
client-side state management

The boundary was obvious.
Frontend lived here.
Backend lived there.
Security responsibilities were reasonably separated.
Modern React applications no longer operate in that world.
The arrival of:

React Server Components
Server Actions
hybrid rendering
Next.js App Router
server-side data access

has fundamentally changed how frontend systems behave.
The application boundary has become softer.
The frontend now executes logic on the server.
The server now lives surprisingly close to the UI layer.
And with that architectural shift comes an uncomfortable reality:
many traditional frontend security assumptions are no longer sufficient.
The issue is not that Next.js is insecure.
The issue is that developers frequently apply old security mental models to a new execution model.
Why Server Actions Quietly Changed the Threat Model
Server Actions are one of the most powerful additions to modern React development.
They are also one of the easiest places to accidentally introduce vulnerabilities.
At first glance, Server Actions feel magical.
You write:
"use server";

export async function updateProfile() {
  // server logic
}

Then call it directly from a form or component.
No REST handler.
No API folder.
No explicit endpoint wiring.
Extremely convenient.
But convenience hides architecture.
Every Server Action is effectively:
a remotely callable server endpoint.
That matters.
Because many developers mentally treat Server Actions like private helper functions.
They are not.
They are part of your application's public execution surface.
The Dangerous Illusion of Hidden Server Logic
A common misunderstanding looks like this:

“Users can only trigger this action from my form.”

Not necessarily.
Attackers do not care about your component hierarchy.
They care about callable interfaces.
If an action exists and can be reached, assumptions based on UI restrictions become unreliable.
Consider this example.
"use server";

export async function promoteUser(payload: any) {
  await db.user.update({
    where: {
      id: payload.id,
    },

    data: {
      role: payload.role,
    },
  });
}

The code seems small.
Clean.
Fast to ship.
And deeply problematic.
Problems immediately appear:

any input
no session validation
no authorization
unrestricted role updates
no ownership checks

An attacker does not need your UI.
They only need a way to invoke the action.
Treat Server Actions Like Production API Endpoints
The safer mental model is simple:
every Server Action should be treated like a hardened API endpoint.
That means:

validate input
authenticate request context
authorize resource access
restrict writable fields
control returned data

A stronger implementation might look like this.
"use server";

import { z } from "zod";
import { getSession } from "@/lib/auth";

const schema = z.object({
  userId: z.string().uuid(),
  displayName: z.string().min(2).max(80),
});

export async function updateProfile(
  rawInput: unknown
) {

  const session =
    await getSession();

  if (!session) {
    throw new Error(
      "Unauthorized"
    );
  }

  const input =
    schema.parse(rawInput);

  if (
    session.user.id !==
    input.userId
  ) {

    throw new Error(
      "Forbidden"
    );
  }

  return db.user.update({

    where: {
      id: input.userId,
    },

    data: {
      displayName:
        input.displayName,
    },

    select: {
      id: true,
      displayName: true,
      avatar: true,
    },
  });
}

Several things changed.
Input became validated.
Identity became explicit.
Authorization became enforced.
Response leakage became restricted.
That difference matters far more than syntax style.
TypeScript Is Not Runtime Security
Many frontend teams heavily rely on TypeScript.
That is good.
TypeScript improves developer ergonomics dramatically.
But TypeScript alone does not secure Server Actions. Read TypeScript Is Not a Security Boundary
Because TypeScript disappears after compilation.
Production JavaScript does not preserve your compile-time guarantees.
If an attacker sends:
{
  "age": "DROP TABLE users"
}

TypeScript will not intervene.
The compiler is already gone.
This is where runtime validation becomes critical.
Defense in Depth with Zod
A stronger strategy combines:

compile-time guarantees
runtime validation
explicit business checks

Zod fits naturally into modern Next.js workflows.
Define schemas once.
Use them for validation and type inference.
Example:
import { z } from "zod";

export const accountSchema =
  z.object({

    email:
      z.email(),

    username:
      z.string()
        .min(3)
        .max(32),

    age:
      z.number()
        .int()
        .min(13)
        .optional(),
  });

type AccountInput = z.infer<typeof accountSchema>;

Now:

runtime validation exists
types remain synchronized
schemas become self-documenting

That combination creates a meaningful defense layer.
Not complete security.
But stronger guarantees.
Making Server Actions Safer with next-safe-action
Once teams begin heavily using Server Actions, repetitive validation logic starts appearing everywhere.
Typical pattern:
validate input
check session
parse schema
handle errors
return typed response

Repeated dozens of times.
This is exactly the problem next-safe-action tries to solve.
Instead of manually building wrappers for every action, you define a secure action client once.
Example:
import { createSafeActionClient } from "next-safe-action";

export const actionClient = createSafeActionClient();

Then define strongly validated actions.
import { z } from "zod";

const schema = z.object({
  id: z.string().uuid(),
  name: z.string().min(2),
});

export const renameProject = actionClient.schema(schema)
  .action(
    async ({
      parsedInput,
    }) => {
      return db.project.update({
        where: {
          id:
            parsedInput.id,
        },
        data: {
          name:
            parsedInput.name,
        },
      });
    }
  );

Now:

validation becomes standardized
parsing becomes automatic
typing stays synchronized
failure handling improves

This reduces boilerplate while preserving security boundaries.
Server Components and Accidental Data Leaks
One of the most subtle problems in modern Next.js architecture is server-to-client leakage.
Traditional SPAs had a relativ…

Howto Use Git Bisect to Find the Commit That Broke Everything
Wed, 27 May 2026 00:00:00 GMT
Every developer eventually runs into the same unpleasant scenario.
The application worked perfectly a week ago.
Now something is broken.
Tests fail.
The UI behaves strangely.
An API endpoint returns nonsense.
And during that week?
Forty commits landed from multiple developers.
Maybe eighty.
Maybe three hundred.
You could inspect commits one by one.
Open diffs.
Run builds.
Test manually.
Slowly lose your patience.
Or you could let Git do the hard work.
That’s exactly what git bisect exists for.
Instead of checking commits sequentially, Git performs a binary search through commit history.
You tell Git:

this version works

and

this version is broken

Git then jumps directly to the middle of the range and asks:

Does it work here?

After several answers, the offending commit appears.
Forty commits?
Roughly six checks.
Eight hundred commits?
Around ten.
That’s the power of binary search applied to version control.
The Core Idea: Binary Search for Broken Code
If you've ever searched through a sorted array using binary search, the logic will feel familiar.
Suppose you have twelve commits:
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11

You know:

c0 worked
c11 is broken

Instead of checking:
c1 → c2 → c3 → c4 → c5 ...

Git immediately chooses the midpoint.
Something like:
c5

You test it.
If c5 works:
the bad commit must be later.
If c5 fails:
the problem must be earlier.
Each answer cuts the search space in half.
That’s why git bisect becomes incredibly efficient on large histories.
Starting a Git Bisect Session
Begin by starting a bisect session.
git bisect start

Now tell Git:
the current state is broken.
Usually this means your current HEAD.
git bisect bad

Next, mark a known working commit.
You can use:

a commit hash
a branch reference
a tag
an older release version

Example:
git bisect good v1.2.0

At this point, Git calculates the midpoint automatically and checks out a commit somewhere between those two states.
You’ll see something like:
Bisecting: 4 revisions left to test
Checking out commit abc1234

Now your job is simple:
test the application.
Testing Each Candidate Commit
Git has moved you to a candidate commit.
Now answer one question:
does the bug exist here?
If everything works:
git bisect good

If the bug is present:
git bisect bad

Git immediately narrows the search range and jumps again.
You repeat the cycle:

test
mark good or bad
test again
mark again

Eventually Git reaches the answer.
When Git Finds the Guilty Commit
After several rounds, Git stops and reports the result.
Example:
a3f8c12 is the first bad commit

That commit introduced the problem.
You now know exactly where to investigate.
Instead of debugging forty random changes, you're examining one specific diff.
That alone can save hours.
A Practical Example
Imagine this timeline:
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11

A week ago:
c0

Everything worked.
Today:
c11

Production is broken.
Start the session:
git bisect start
git bisect bad
git bisect good c0

Git chooses the midpoint.
Example:
Checking out c5

You run the app.
Suppose:
c5 still works.
Mark it:
git bisect good

Git shrinks the search window.
Now it may jump to:
c8

You test again.
Suppose:
c8 fails.
Mark it:
git bisect bad

Search space shrinks again.
After a few iterations:
Git identifies the exact commit responsible.
You never manually walked through the entire history.
Don’t Forget to Reset Afterwards
This is easy to forget.
During a bisect session, Git repeatedly checks out temporary commits.
Once you’re finished, return to your original branch state:
git bisect reset

Without reset, you may wonder why your repository suddenly sits on some detached historical commit.
Always reset when you're done.
Automating Git Bisect with Tests
Manual testing works.
Automated testing works even better.
If you already have a command that verifies correctness and returns:
0 → success
non-zero → failure

you can automate the entire search.
Example:
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run npm test

Now Git handles everything.
For each candidate commit it will:

checkout commit
run tests
interpret result
continue searching

No manual interaction required.
This becomes incredibly powerful for:

failing unit tests
broken builds
regression bugs
CI debugging
flaky integrations

Using Custom Validation Scripts
You aren't limited to npm test.
Any script can drive bisect.
For example:
git bisect run ./check-build.sh

or
git bisect run pnpm lint

Or a custom Node validation script:
git bisect run node verify-api.js

As long as the command returns a proper exit code, Git can automate the search.
That flexibility makes git bisect useful far beyond traditional testing.
Why Developers Forget This Tool Exists
git bisect is oddly underused.
Many developers know it exists but rarely reach for it.
Instead they default to:

reading commit history manually
guessing likely changes
debugging recent merges
blaming dependencies
reopening old PRs

Sometimes that works.
Often it wastes time.
git bisect gives you something much stronger:
a systematic search strategy.
No guessing.
No intuition games.
Just elimination.
When Git Bisect Becomes Especially Valuable
This tool shines in situations like:
Regression Bugs
Something used to work.
Now it doesn't.
Classic bisect territory.
Large Teams
Many developers.
Many commits.
Unclear ownership.
Bisect dramatically reduces noise.
Old Codebases
You don't remember when the behavior changed.
The repository history does.
CI Failures
A build started failing somewhere in the last two weeks.
Nobody knows where.
Bisect knows.
Final Thoughts
git bisect is essentially binary search applied to commit history.
That simple idea makes it incredibly effective.
Instead of checking commits one after another, Git repeatedly cuts the search range in half.
Forty commits?<…

TypeScript Security From Backend to Browser
Mon, 25 May 2026 00:00:00 GMT
TypeScript Is Not a Security Boundary
TypeScript has quietly become the default language of modern JavaScript engineering.
React applications.
Next.js platforms.
NestJS APIs.
GraphQL services.
CLI tooling.
Infrastructure scripts.
Entire SaaS companies run on TypeScript stacks.
And somewhere along the way, many developers start developing a subtle — and understandable — misconception:
“We use TypeScript, so a large chunk of security problems are probably handled already.”
Not explicitly.
Not consciously.
But indirectly.
Strong types feel safe.
Strict mode feels safe.
Interfaces feel safe.
DTOs, generics, discriminated unions, branded types — they create an environment that looks disciplined.
And that discipline genuinely reduces bugs.
But security vulnerabilities live in a different universe.
A SQL injection payload is still a valid string.
An XSS payload is still a valid string.
A malicious JWT is still a valid string.
A poisoned npm dependency still compiles perfectly.
The TypeScript compiler is not failing.
It is doing exactly what it was designed to do.
This distinction matters.
Because many production incidents happen precisely at the border where developers confuse type safety with security guarantees.
In this article, we'll walk through the major security concerns affecting modern TypeScript applications:

backend attacks
database injections
SSR vulnerabilities
React and browser security
JWT mistakes
prototype pollution
GraphQL abuse
SSRF
supply-chain attacks
runtime validation
modern tooling strategies

And most importantly:
how to build a security model that works with TypeScript instead of expecting TypeScript to do security's job.
Backend Reality: HTTP Requests Arrive Before Type
TypeScript creates contracts between layers.
Controllers expect DTOs.
Services expect interfaces.
Repositories expect known shapes.
The internet ignores all of them.
Your backend does not receive:
type LoginRequest = {
  email: string;
  password: string;
}

It receives:
raw bytes

Those bytes might become JSON.
Or malformed JSON.
Or intentionally malicious JSON.
Or oversized payloads.
Or nested objects designed to break assumptions.
Before your beautiful TypeScript types even exist, untrusted data already crossed your trust boundary.
That is why runtime validation matters.
Not optional validation.
Not “we validate most routes.”
Boundary validation.
Every request.
Every external payload.
Every webhook.
Every environment variable.
Every file import.
Without this mindset, types become documentation — not protection.
SQL Injection Still Exists Inside ORM Code
Many developers associate SQL injection with early PHP tutorials.
String concatenation.
Handwritten SQL.
Obvious mistakes.
Modern ORMs supposedly solved that problem.
Mostly true.
Mostly.
Because ORMs reduce risk until developers partially bypass them.
Consider this seemingly harmless endpoint:
app.get("/users", async (req, res) => {
  const { sortColumn, order } = req.query;

  const users = await connection.query(
    `SELECT * FROM users
     ORDER BY ${sortColumn} ${order}`
  );

  res.json(users);
});

From TypeScript's perspective:
sortColumn: string
order: string

Everything typechecks.
The database sees something different.
Suppose an attacker sends:
/users?sortColumn=name&order=ASC;DROP TABLE users;--

The database does not care that your IDE showed no errors.
The query parser now receives executable SQL.
This is where many teams misunderstand what ORMs actually guarantee.
An ORM reduces accidental SQL construction.
It does not automatically sanitize arbitrary string interpolation.
Safer approach:
const allowedColumns = [
  "name",
  "email",
  "createdAt"
] as const;

const allowedDirections = [
  "ASC",
  "DESC"
] as const;

Validate.
Allowlist.
Then build controlled queries.
Or better:
use query APIs that parameterize values automatically.
The Hidden ORM Trap: QueryBuilder and Raw()
This is where real-world codebases become interesting.
Developers often say:

“We already use QueryBuilder.”

Good.
That alone changes nothing.
Unsafe QueryBuilder code still exists everywhere.
Example:
const qb = userRepository.createQueryBuilder("user");

qb.where(
  `user.role='${filter}'`
);

Looks sophisticated.
Still injection-prone.
Same vulnerability.
New abstraction layer.
TypeORM's Raw() helper is another common footgun.
Unsafe:
where: {
  name: Raw(
    alias => `${alias} LIKE '%${query}%'`
  )
}

Here, user input becomes part of executable SQL again.
Safe alternative:
where: {
  name: Raw(
    alias => `${alias} ILIKE :query`,
    {
      query: `%${query}%`
    }
  )
}

Parameterized placeholders exist for a reason.
Use them.
NoSQL Injection Is Still Injection
MongoDB developers sometimes assume they escaped SQL problems entirely.
Not quite.
You traded syntax.
Not threat models.
Classic vulnerable login handler:
app.post("/login", async (req, res) => {
    const { username,password } = req.body;
    const user =
      await User.findOne({
        username,
        password
      });
    if (user) {
      return res.sendStatus(200);
    }
    res.sendStatus(401);
});

Now imagine this payload:
{
  "username": {
    "$ne": null
  },
  "password": {
    "$ne": null
  }
}

The resulting query becomes:
{
  username: {
    $ne: null
  },

  password: {
    $ne: null
  }
}

Congratulations.
You may have just authenticated the first matching user.
The compiler did not fail.
Because objects are valid objects.
Runtime validation solves this.
Not interfaces.
Runtime.
Zod example:
const LoginSchema = z.object({
  username: z.string(),
  password: z.string(),
});

Only parsed data enters business logic.
Everything else dies at the boundary.
Runtime Validation Is Not Optional Infrastructure
This deserves its own section.
Many TypeScript codebases validate inside handlers.
After logic begins.
After database calls.
After assumptions already spread through the request pipeline.
Validation belongs at the trust boundary.
Modern stack:

Zod
class-validator
Valibot
io-ts
custom parsers

The specific library matters less than the architectural rule:
external data is untrusted until runtime validation succeeds.
This includes:

API requests
webhook payloads
Kafka events
Redis messages
JSON imports
environment variables
browser localStorage
server actions
SSR hydration data

TypeScript cannot validate any of those at runtime.
That is not a limitation.
That is literally outside its job description.

Howto Catch Risky JavaScript Bugs with eslint-plugin-security
Mon, 25 May 2026 00:00:00 GMT
Most developers already use ESLint.
You probably have rules for:

unused variables
import sorting
React hooks
formatting
TypeScript correctness

But many projects still miss an entirely different category of bugs:
security mistakes hiding inside valid JavaScript.
The code compiles.
Tests pass.
TypeScript is happy.
Production deploys successfully.
Then somebody discovers an unsafe regex freezing your API server, a dynamic require() loading unexpected modules, or a command injection vulnerability hiding inside a small utility function nobody questioned during review.
That is exactly where eslint-plugin-security becomes useful.
It does not replace penetration testing.
It does not magically secure your application.
But it can catch dangerous patterns early — directly inside your editor and CI pipeline.
In this article we'll look at:

what eslint-plugin-security actually does
how to install it
how to configure ESLint v9 Flat Config
real security problems it can detect
common false positives
how to use it in production projects

Why Normal ESLint Rules Are Not Enough
Standard ESLint focuses on code quality.
It helps prevent problems like:
const username = "Alex";

console.log(userName);

or:
const data = await fetchProfile()

without handling the Promise properly.
Useful?
Absolutely.
Security-focused?
Not really.
Security bugs usually look perfectly legal to JavaScript.
Example:
const query = req.query.script;

eval(query);

ESLint sees valid syntax.
JavaScript sees valid syntax.
Your attacker sees opportunity.
Security linting exists because many dangerous patterns are still syntactically correct code.
Installing eslint-plugin-security
Installation is straightforward.
npm install -D eslint-plugin-security

ESLint v9 Flat Config Setup
Modern ESLint projects typically use Flat Config.
Create or update:
eslint.config.js
Configuration example:
import security from "eslint-plugin-security";

export default [
  {
    plugins: {
      security,
    },

    rules: {
      ...security.configs.recommended.rules,
    },
  },
];

That is enough to enable the recommended ruleset.
You can now run:
npx eslint . --ext .js,.ts

Legacy .eslintrc Configuration
Older projects may still use .eslintrc.
Example:
{
  "plugins": ["security"],
  "extends": ["plugin:security/recommended"]
}

Simple.
Done.
Dangerous Pattern #1 — Dynamic eval()
Let's start with the obvious one.
JavaScript's infamous eval().
Bad example:
const sourceCode = req.body.expression;

const output = eval(sourceCode);

If external input reaches this function, your application can execute arbitrary JavaScript.
That is rarely what you want.
The plugin flags patterns like this immediately.
Safer alternatives often exist.
Instead of dynamic execution:
eval("5 + 10");

prefer explicit logic:
const operations = {
  add: (x: number, y: number) => x + y,
  subtract: (x: number, y: number) => x - y,
};

const result = operations.add(5, 10);

Less magical.
Much safer.
Dangerous Pattern #2 — Non-Literal require()
This rule surprises many developers.
Consider:
const packageName = req.query.library;

const dependency = require(packageName);

Looks flexible.
Also potentially dangerous.
Because attackers might control what module gets loaded.
Security plugins dislike dynamic imports for good reason.
Prefer explicit allowlists.
Example:
const allowedLibraries = {
  csv: require("./parsers/csv"),
  json: require("./parsers/json"),
};

const parser = allowedLibraries[userFormat];

Now the input selects from known modules instead of arbitrary paths.
Dangerous Pattern #3 — Unsafe Child Process Execution
Node.js applications often interact with shell commands.
Example:
import { exec } from "node:child_process";

exec(`ping ${hostname}`);

Looks innocent.
Until somebody submits:
localhost && rm -rf /
Welcome to command injection.
This is one of the oldest backend vulnerabilities.
Safer approach:
import { execFile } from "node:child_process";

execFile(
  "ping",
  [hostname],
  (error, stdout) => {
    console.log(stdout);
  }
);

Arguments stay separated from the command itself.
Much safer.
Dangerous Pattern #4 — Object Injection
One of the more controversial rules.
Example:
const fieldName = req.query.sort;

database[fieldName] = value;

Why does the plugin care?
Because user-controlled property access can sometimes lead to:

prototype pollution
unsafe mutation
unexpected behavior

Example:
payload["__proto__"] = {
  compromised: true,
};

Depending on the environment and codebase, this can become dangerous.
Safer approach:
const allowedFields = [
  "email",
  "username",
  "createdAt",
];

if (allowedFields.includes(fieldName)) {
  database[fieldName] = value;
}

Explicit validation dramatically reduces risk.
Dangerous Pattern #5 — Unsafe Regular Expressions
Regex performance issues are underrated.
A poorly designed regex can lock an application thread.
Example:
const pattern =
  /(a+)+$/;

pattern.test(userInput);

Certain inputs can trigger catastrophic backtracking.
Your server CPU spikes.
Requests hang.
Users complain.
This category is often called ReDoS — Regular Expression Denial of Service.
The security plugin warns about suspicious constructions.
Even better: test regex performance intentionally.
Example safer pattern:
const emailMatcher =
  /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

Simple patterns usually behave more predictably.
Dangerous Pattern #6 — Timing Attack Risks
Some rules target insecure comparisons.
Example:
if (
  suppliedSecret === process.env.API_SECRET
) {
  authenticate();
}

Looks harmless.
But direct string comparison may leak timing information.
In sensitive environments, use dedicated cryptographic helpers.
Node.js provides:
import crypto from "node:crypto";

const verified =
  crypto.timingSafeEqual(
    Buffer.from(inputSecret),
    Buffer.from(secretValue)
  );

Do most applications need this?
No.
Do authentication systems care?
Yes.
False Positives: When the Plugin Gets Noisy
This is important.
eslint-plugin-security is not perfect.
Some rules intentionally behave aggressively.
You may see warnings like:
config[key] = value;

even when your code is completely safe.
That does not automatically mean the plugin is wrong.
Security tooling often prefers better safe than sorry.
Still, developers need practical workflows.
You have several opt…

5 Docker Compose Settings Missing From Most Production Setups
Thu, 21 May 2026 00:00:00 GMT
You wrote a docker-compose.yml, started everything locally, and it worked perfectly.
You deployed it to a server.
Then you ran:
docker compose up -d

Everything looked fine for a week.
Then Postgres quietly consumed all available memory, Linux triggered the OOM killer, and your application died instead of the database.
Or your service crashed at 2 AM and stayed offline because Docker's default restart policy is effectively:
restart: no

Or container logs silently grew to 40 GB and filled the disk.
None of these problems are exotic. They are common production failures caused by Compose files that were written for local development and then promoted to servers without production guardrails.
The uncomfortable part is that most of these failures are fixed with a few lines of configuration.
The problem is that local development rarely forces you to care. Your laptop has enough RAM, plenty of disk space, and you are usually sitting next to the terminal when something breaks. A production server is different. It runs unattended. It accumulates logs. It handles traffic spikes. It restarts after failures. It stores data that should not disappear because someone used the wrong flag.
This article covers five Docker Compose settings that are easy to forget but painful to miss.
1. Set Memory and CPU Limits
By default, a container can use as much CPU and memory as the host allows.
That sounds convenient locally. In production, it is a risk.
Imagine a small server running three services:

your application
Postgres
Redis

Without limits, any of them can consume enough resources to destabilize the whole machine. In many real systems, the database is the first service to grow aggressively. Postgres sees available memory and uses it. Redis may do the same if its dataset grows. Your application may spike during traffic bursts, image processing, queue jobs, or bad queries.
When the host runs out of memory, Linux does not politely ask Docker which container should stop. The OOM killer chooses a process. Sometimes it kills the database. Sometimes it kills your application while it is handling hundreds of requests.
Add explicit resource boundaries:
services:
  app:
    image: myapp:latest
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
        reservations:
          memory: 256M

  postgres:
    image: postgres:16-alpine
    deploy:
      resources:
        limits:
          memory: 1G

limits are the hard ceiling. If the container exceeds the memory limit, Docker isolates the failure to that container instead of letting it consume the entire host.
reservations describe the amount of resources the service expects to have available. They are useful when Compose is used with orchestration features, but the most important part for a simple server is still the hard memory limit.
You can check whether a container was killed because of memory pressure:
docker inspect myapp --format='{{.State.OOMKilled}}'

If the result is:
true

then the container was killed after exceeding its memory allowance.
For Postgres, memory limits should also influence database configuration. If you limit the container to 1G, setting shared_buffers somewhere around 256MB is a reasonable starting point. The exact value depends on workload, but the important idea is simple: database tuning should match the container's actual memory budget, not the host's total memory.
2. Add a Restart Policy
Docker does not automatically restart failed containers unless you tell it to.
That surprises many people.
The default behavior is essentially:
restart: no

If your application crashes, it stays down.
That may be fine during development. It is not fine at 2 AM.
For long-running services, use:
services:
  app:
    image: myapp:latest
    restart: unless-stopped

unless-stopped is usually the safest default for application services.
It means Docker will restart the container after crashes, daemon restarts, and machine reboots. But if you intentionally stop the service, Docker respects that and does not immediately bring it back.
That makes it more practical than always for many small production setups. always can be annoying during maintenance because Docker may restart containers you intentionally stopped.
One-off jobs are different.
Migrations, seed scripts, and maintenance tasks should not restart forever:
services:
  migrator:
    image: myapp:latest
    command: ["python", "manage.py", "migrate"]
    restart: "no"

  app:
    image: myapp:latest
    restart: unless-stopped
    depends_on:
      migrator:
        condition: service_completed_successfully

This pattern avoids a common production mistake: starting the application before the schema is ready.
If the migration fails, the application should not boot and pretend everything is fine. It should fail early, loudly, and predictably.
3. Rotate Container Logs
Docker's default json-file logging driver writes logs to disk.
If you do not configure rotation, those files can grow without a practical limit.
A service logging every request at 100 requests per second can generate a surprising amount of data. Over weeks or months, logs can quietly consume tens of gigabytes.
When the disk fills up, the failure is ugly:

containers may stop
writes may fail
Docker itself may become unstable
recovery may require manual cleanup on the host

Add log rotation directly in Compose:
services:
  app:
    image: myapp:latest
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

This means each log file can grow to 10 MB, and Docker keeps up to three files per container.
So the container uses roughly 30 MB for logs before old files are rotated out.
For many services, that is enough for quick diagnostics. If you need more history on the host, increase the limits:
logging:
  driver: json-file
  options:
    max-size: "50m"
    max-file: "10"

That gives you up to 500 MB per container.
You can also define global defaults in /etc/docker/daemon.json:
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

After changing daemon settings, restart Docker so new containers use the configuration.
To inspect current log usage:
du -sh /var/lib/docker/containers/*/*-json.log | sort -h

If you see multi-gigabyte JSON log files, log rotation was missed.
That is not a logging strategy. It is a delayed outage.
4. Add Healthchecks
Docker knows whether a process is running.
It does not automatically know whether your application is useful.
A container can be in a running state while the actual service is broken. The process may exist, but the app may be stuck, overloaded, disconnected from the database, or unable to respond to HTTP requests.
Add a healthcheck:
services:
  app:
    image: myapp:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

The test command should check something meaningful.…

Meet Fate: Building an Astro Blog with a Modern React Data Client
Thu, 21 May 2026 00:00:00 GMT
React solved UI a long time ago.
Data, however, is still where many applications quietly accumulate complexity.
Between fetch(), useEffect(), loading states, caching layers, duplicated requests, and client synchronization, modern React applications often end up inventing their own mini data framework.
Fate takes a different approach.
It is a modern React data client built around composable data views, normalized caching, and structured client data access.
Although Fate can power much larger systems — dashboards, realtime applications, complex authenticated interfaces — this article explores it in a smaller and perhaps less expected environment:
an Astro 6 static blog with React islands.
Astro is designed around static generation. Blogs are primarily content-driven. Many projects can be built using Astro alone, without React, without a client data layer, and often without any client-side JavaScript at all.
That is true.
But modern Astro applications frequently mix static rendering with selective interactivity:

React islands
dynamic search widgets
authenticated UI sections
personalized dashboards
API-driven components
client-side stateful interfaces

Once React islands enter the picture, questions about data access eventually follow.
Instead of building an abstract enterprise dashboard, we will explore Fate through something smaller, concrete, and easier to reason about.
By the end of this article, we will build a modern Astro 6 blog featuring:

MDX content collections
dynamic blog routes
React islands
Tailwind v4 styling
client-side search
dark mode
tag pages
API routes
a minimal working Fate integration

Along the way, we will also answer a more practical question:
Do you actually need Fate for an Astro blog?
Usually, no.
But understanding where it fits can tell us a lot about modern React data architecture.
What Is Fate?
Before touching Astro, it is worth understanding what Fate actually is.
Fate is not a state manager.
It is not another useState() replacement.
It is not React Query with slightly different naming.
Instead, Fate positions itself as a modern React data client.
Its API revolves around concepts like views, requests, transports, and structured client data access.
One of the most recognizable pieces of the API is view():
import { view } from "react-fate";

type Post = {
  id: string;
  title: string;
  description: string;
};

const PostView = view<Post>()({
  id: true,
  title: true,
  description: true,
});

Instead of thinking primarily in terms of raw network requests, Fate encourages components to declare which pieces of data they actually care about.
If this feels somewhat familiar to GraphQL fragments, Relay, or normalized client architectures, that is not accidental.
The idea is not simply "fetch some JSON".
The idea is structured client-side data composition.
That distinction becomes much more interesting once applications begin growing beyond a few isolated components.
Why Use Fate in an Astro Project?
At this point, a reasonable question appears.
Why Astro? And why Fate inside Astro?
After all, Astro was built around a static-first philosophy.
A typical Astro blog can happily exist without React, without client-side state, and without a dedicated data layer.
In many cases, that is exactly what makes Astro attractive.
You write content.
Astro generates HTML.
The browser receives mostly static pages.
Everything stays fast.
A minimal blog can often be implemented using:

Markdown or MDX content
static routes
server-side content collections
zero client JavaScript

For a large percentage of publishing websites, this is already enough.
So introducing React — and especially a specialized React data client — might initially sound like unnecessary complexity.
That concern is fair.
However, modern Astro projects frequently extend beyond purely static pages.
Consider a few examples.
An otherwise static blog might eventually gain:

client-side search
bookmarks
reading history
personalized recommendations
authenticated dashboards
realtime counters
notification panels
interactive filtering systems

This is where Astro islands architecture becomes interesting.
Astro allows us to selectively introduce interactivity only where it is needed.
Instead of hydrating an entire application, we can hydrate isolated components.
A search widget can become interactive.
A theme toggle can manage client state.
A live dashboard card can fetch dynamic data.
Everything else remains static.
That balance is one of Astro's strongest design choices.
For example, a React search component can be hydrated independently:
<BlogSearch
  posts={searchPosts}
  client:load
/>

Only this island becomes interactive.
The rest of the page remains static HTML.
This approach gives us a useful playground for exploring Fate.
We do not need a massive enterprise application to understand a data client.
We simply need a project where static content and client-side interactivity coexist.
An Astro blog happens to be a surprisingly practical environment for exactly that.
Creating the Project
We will begin with a minimal Astro 6 setup.
Create a new project:
npm create astro@latest fate-blog

Choose the following options during initialization:
Template: Empty
TypeScript: Yes
Install dependencies: Yes
Initialize Git: Yes

Move into the project directory:
cd fate-blog

Then add the pieces we will use throughout the article.
React integration:
npx astro add react

MDX support:
npx astro add mdx

Tailwind v4:
npx astro add tailwind

And finally, install Fate:
npm install react-fate

Our dependency list will look roughly like this:
"dependencies": {
  "@astrojs/mdx": "^5.0.6",
  "@astrojs/react": "^5.0.5",
  "@tailwindcss/vite": "^4.3.0",
  "@types/react": "^19.2.15",
  "@types/react-dom": "^19.2.3",
  "astro": "^6.3.6",
  "react": "^19.2.6",
  "react-dom": "^19.2.6",
  "react-fate": "^1.0.3",
  "tailwindcss": "^4.3.0"
}

Configuring Content Collections in Astro 6
Astro 6 uses the newer content loader approach.
Create:
src/content.config.ts

Add the following configuration:
import { defineCollection, z } from "astro:content";
import { glob } from "astro/loaders";

const posts = defineCollection({
  loader: glob({
    pattern: "**/*.{md,mdx}",
    base: "./src/content/posts",
  }),

  schema: z.object({
    title: z.string(),
    description: z.string(),
    date: z.coerce.date(),
    category: z.string(),
    tags: z.array(z.string()).default([]),
  }),
});

export const collections = {
  posts,
};

This configuration defines a typed content collection named posts.
Every post must now provide:

title
description
publication date
cat…

Friday Links #38 — JavaScript Trends, AI Dev Tools & Releases
Thu, 21 May 2026 00:00:00 GMT

Another busy week in the JavaScript world.
Framework releases kept shipping, browser vendors continued experimenting, AI development tools evolved at an uncomfortable speed, and open-source maintainers somehow still found time to launch new libraries, runtimes, and developer utilities.
This edition collects the updates, experiments, technical discussions, and releases worth paying attention to — from frontend frameworks and tooling changes to AI coding workflows, browser platform news, and interesting projects from across the developer ecosystem.
Whether you are following React, TypeScript, Bun, Node.js, AI-assisted development, or simply looking for useful tools to explore, here are the links that stood out this week.
📢 Special partner message
🗓️ React Norway — Oslo, June 5 🇳🇴
Join 350+ React and full-stack developers for a unique single-track conference with a strong “Rock & React” vibe, great talks, community energy, and modern web engineering discussions.
🎟️ Use code TWIR for 10% off your ticket.
🧠 Language & Runtime Updates
TypeScript 6.0 Is Official — And It’s Preparing the Road to TypeScript 7
One of the biggest ecosystem updates remains TypeScript 6.0.
This release is not just another incremental version bump. It acts as a transition layer between the current JavaScript-based compiler and the upcoming native TypeScript 7 compiler. According to the TypeScript team, 6.0 is effectively the bridge release that prepares projects for the future architecture.
Some notable changes include:

alignment with future TS 7 behavior
deprecations aimed at modern ESM workflows
simplified DOM library behavior
stricter compiler rules
migration tooling for upcoming changes

The broader direction is clear: TypeScript is increasingly optimizing for modern evergreen runtimes, ESM tooling, and native performance improvements.
Bun’s Rust Rewrite Has Been Merged
The Bun story continues.
One of the more talked-about updates recently: Bun’s experimental Rust rewrite effort has now been merged, generating substantial discussion across developer communities. Questions quickly emerged around maintainability, AI-assisted code generation quality, and long-term runtime strategy.
At the same time, Bun keeps strengthening its position inside the TypeScript ecosystem.
Developers increasingly evaluate Bun not just as a runtime, but as a broader replacement for parts of the traditional Node toolchain:

package manager
bundler
test runner
TypeScript execution environment
server runtime

The “Should new TypeScript projects start with Bun?” conversation is becoming more common.
Deno 2.8 ships this week with a focus on improving the developer experience around TypeScript, ESM, and modern JavaScript features.
📜 Articles & Tutorials
Install web apps with the new HTML install element
Prompts are advisory. Structure is binding.
An Excruciatingly Detailed Guide To SSH
How To Make Your Text Look Futuristic
MASTER THE NODE.JS INTERNALS
Let’s Use the Nonexistent ::nth-letter Selector Now
Hardening TanStack After the npm Compromise
Using safe-area-inset to build mobile-safe layouts
What's new in Node.js 26
Fixing JavaScript observability, one library at a time
Your Recursion Is Lying to You
HTTP/3 Over QUIC in Node.js
Async React: Building Non-Blocking UIs with useTransition and useActionState
Better fluid sizing with round()
Moving away from Tailwind, and learning to structure my CSS
600+ million people write right-to-left: 2 fixes your app needs
Gap decorations: Now available in Chromium
A few ways of specifying per-theme colours in only CSS
When to use (and not use) CSS shorthand properties
How to Make The Fluffiest Grass With Three.js
⚒️ Tools
Open-source Discord alternative GoofCord has been released, promising a faster, cleaner, and far more customizable experience than the official client.
According to the project, GoofCord:

runs noticeably faster than the standard Discord client, with fewer slowdowns and UI hiccups;
blocks built-in telemetry and user data collection;
supports password-encrypted conversations;
allows screen sharing at any resolution and frame rate;
lets users choose which application audio gets streamed;
automatically updates your status based on games, music, or videos;
supports Vencord, Equicord, and Shelter customization plugins out of the box;
includes global hotkeys that keep working even when the app is minimized;
supports audio streaming on Linux, while also running on Windows and macOS.

Awesome CUDA Books is a new curated list of resources for learning CUDA programming, covering everything from beginner-friendly introductions to advanced optimization techniques.
An open-source project called tokenspeed (including an online version) has been released to make LLM token throughput easier to understand visually.
Most local LLM benchmarks report raw generation speed:

47 tokens/sec on an M3
180 tokens/sec on an RTX 4090
500 tokens/sec on Groq

But unless you've actually watched tokens stream at those speeds, those numbers can feel pretty abstract.
tokenspeed solves that problem.
It’s a terminal utility that simulates token streaming at any speed you choose, allowing you to see what different throughput numbers actu…

How JavaScript call, apply, and bind Actually Work
Wed, 20 May 2026 00:00:00 GMT
JavaScript gives functions a strange amount of power.

A function can be called directly. It can be stored in a variable. It can be passed into another function. It can become a method of an object. It can be used as a constructor. It can even be executed with a completely different this value from the one you expected.
That flexibility is one of the reasons JavaScript is so expressive. It is also one of the reasons this has confused developers for decades.
The methods call, apply, and bind sit right in the middle of that confusion. Most developers know their surface-level syntax:
functionName.call(context, arg1, arg2)
functionName.apply(context, [arg1, arg2])
const boundFunction = functionName.bind(context, arg1)

But syntax is not understanding.
Real understanding starts when you can explain why these APIs exist, what invocation rules they rely on, how to implement simplified versions yourself, and where the edge cases begin.
This article takes a deep look at call, apply, bind, and arguments from the perspective of JavaScript language mechanics. The goal is not to memorize another interview trick. The goal is to understand what actually happens when a function is invoked.
Why These APIs Exist
The main problem solved by call, apply, and bind is context control.
In JavaScript, this is not determined only by where a function is written. For regular functions, this is mainly determined by how the function is called.
That is the part many developers miss.
Consider this function:
function showCurrentUser() {
  console.log(this.username)
}

There is no permanent this value inside this function. The value depends on the invocation pattern.
Call it directly:
showCurrentUser()

In non-strict browser code, this may point to window. In strict mode, this will be undefined.
Call it as an object method:
const account = {
  username: 'Maya',
  showCurrentUser,
}

account.showCurrentUser()

Now this points to account.
Call it with call:
showCurrentUser.call({ username: 'Nina' })

Now this points to the object passed into call.
Same function. Different result. Different invocation.
That is why the best mental model is this:

Most this bugs are invocation bugs.

Not declaration bugs. Not class bugs. Not file structure bugs. Invocation bugs.
The Binding Rules Behind this
Before implementing call, apply, or bind, we need to understand the binding rules they interact with.
JavaScript has several important ways to determine this.
Default Binding
Default binding happens when a regular function is called without an owning object.
function printContext() {
  console.log(this)
}

printContext()

In strict mode, this is undefined.
'use strict'

function printContext() {
  console.log(this)
}

printContext() // undefined

In older non-strict browser code, this can fall back to the global object.
Modern code should avoid relying on this behavior. It is fragile and often different between environments.
Implicit Binding
Implicit binding happens when a function is called as a property of an object.
const dashboard = {
  title: 'Admin Panel',
  printTitle() {
    console.log(this.title)
  },
}

dashboard.printTitle()

The call expression is:
dashboard.printTitle()

Because the function is called through dashboard, JavaScript binds this to dashboard.
This rule is extremely important because a simplified implementation of call can exploit it.
Explicit Binding
Explicit binding happens when you use call, apply, or bind.
function printRole() {
  console.log(this.role)
}

printRole.call({ role: 'editor' })

Here, the function is not called as a method of the object. We explicitly provide the object that should become this.
That is the purpose of call and apply: execute a function immediately with a chosen this value.
bind also chooses a this value, but it does not execute immediately. It returns a new function that remembers the chosen context.
Constructor Binding
Constructor binding happens when a function is called with new.
function Product(name) {
  this.name = name
}

const book = new Product('JavaScript Guide')

When new Product(...) runs, JavaScript creates a new object and binds this to that new object during the constructor call.
This matters because constructor binding has higher priority than a simple bound context. A complete bind polyfill must handle this case. Many simplified examples do not.
The Basic Difference Between call, apply, and bind
At a high level, the three APIs differ in two ways:

Whether the function executes immediately.
How arguments are passed.

fn.call(context, arg1, arg2, arg3)
fn.apply(context, [arg1, arg2, arg3])
const later = fn.bind(context, arg1, arg2)

call executes immediately and receives arguments one by one.
apply executes immediately and receives arguments as an array-like list.
bind does not execute immediately. It returns a new function with a fixed context and optional preset arguments.
That sounds simple, but the real mechanics are more interesting.
Implementing a Simple call
Let us start from scratch.
All functions inherit from Function.prototype, so we can add our own method there for educational purposes.
Do not patch built-in prototypes in production code. This is only for learning.
Function.prototype.runNow = function () {
  console.log('custom method executed')
}

function calculateTotal() {
  console.log('original function executed')
}

calculateTotal.runNow()

This prints:
custom method executed

But it does not execute calculateTotal itself.
Inside runNow, what does this refer to?
Function.prototype.runNow = function () {
  console.log(this)
}

calculateTotal.runNow()

The value of this is the function that called runNow. In this case, calculateTotal.
That means we can execute it:
Function.prototype.runNow = function () {
  const targetFunction = this
  return targetFunction()
}

Now:
function sayHello() {
  return 'Hello'
}

console.log(sayHello.runNow())

Output:
Hello

We have recreated the first part of call: invoking the function through a prototype method.
Now we need to control this.
How call Changes this
Suppose we want this behavior:
function printUser() {
  console.log(this.n…

Howto Master the Blob for File Handling and Memory Optimization
Tue, 19 May 2026 00:00:00 GMT
Modern frontend applications deal with files all the time.
Users upload avatars, drop videos into dashboards, export CSV reports, preview PDFs, download generated configuration files, and work with media directly in the browser. At first, these features look simple. A file input, a preview element, maybe a download button, and the job seems done.
Then the real problems appear.
Large files freeze the tab. Image uploads are too slow. Data URLs become huge. Browser memory keeps growing. Previews work for one file type but not another. A dashboard that looked fine during testing becomes unstable after a user processes dozens of images in a single session.
This is where the Blob API becomes important.
A Blob is not just a small browser feature for downloads. It is one of the core building blocks behind file handling in modern JavaScript. Once you understand how Blob objects work, you can build cleaner upload flows, safer previews, better export tools, and more memory-efficient interfaces.
This article walks through practical Blob usage in real frontend work: creating Blob objects, processing large files in chunks, compressing images, building previews, generating downloads, and avoiding memory leaks caused by forgotten object URLs.
What Is a Blob?
A Blob is an immutable object that represents raw data.
That data can be text, JSON, CSV, an image, a video, a PDF, or any other binary content the browser can hold. The word “Blob” stands for Binary Large Object, but in frontend development you can think of it as a file-like container created or handled inside the browser.
A minimal Blob looks like this:
const textBlob = new Blob(['Hello from the Blob API'], {
  type: 'text/plain',
});

The first argument is an array of data parts. The second argument describes the Blob. Most of the time, the most important option is type, which stores the MIME type.
Examples of common MIME types:
text/plain
application/json
text/csv
image/png
image/jpeg
application/pdf

The MIME type helps the browser understand how to treat the data. A JSON Blob, an image Blob, and a PDF Blob may all be Blob objects, but the browser can preview, download, or send them differently depending on the type.
Why Blob Is Better Than Large Data URLs
A common beginner approach for generating files is to create a data: URL manually:
const hugeText = 'Some large content...'.repeat(100_000);

const url =
  'data:text/plain;charset=utf-8,' +
  encodeURIComponent(hugeText);

This works for small examples, but it scales badly. Large data URLs can consume more memory than expected, become difficult for the browser to handle, and fail when the generated URL becomes too long.
Blob is usually the better option:
const hugeText = 'Some large content...'.repeat(100_000);

const blob = new Blob([hugeText], {
  type: 'text/plain',
});

const url = URL.createObjectURL(blob);

Instead of encoding everything into a giant string URL, the browser creates an object URL that points to the Blob data internally. That is cleaner, more memory-friendly, and more reliable for larger content.
Creating Blob Objects Properly
Blob creation is simple, but in real projects it is worth wrapping it in small utilities so your code stays consistent.
type BlobOptionsInput = {
  mimeType?: string;
};

function createFileBlob(
  parts: BlobPart[],
  options: BlobOptionsInput = {}
) {
  return new Blob(parts, {
    type: options.mimeType ?? 'text/plain',
  });
}

Now you can create different file-like objects with explicit MIME types.
Text Blob
const readmeBlob = createFileBlob(
  ['This file was generated in the browser.'],
  { mimeType: 'text/plain' }
);

JSON Blob
const userSettings = {
  theme: 'dark',
  compactMode: true,
  language: 'en',
};

const settingsBlob = createFileBlob(
  [JSON.stringify(userSettings, null, 2)],
  { mimeType: 'application/json' }
);

HTML Blob
const htmlDocument = `
  <!doctype html>
  <html>
    <body>
      <h1>Generated HTML</h1>
    </body>
  </html>
`;

const htmlBlob = createFileBlob(
  [htmlDocument],
  { mimeType: 'text/html' }
);

The main rule is simple: always set the correct MIME type when you know what kind of data you are creating.
Downloading Generated Files in the Browser
One of the most common Blob use cases is generating downloadable files without asking the server to create them.
For example, a settings page may allow users to export their configuration as JSON:
function downloadJsonFile(
  data: unknown,
  filename = 'settings.json'
) {
  const json = JSON.stringify(data, null, 2);

  const blob = new Blob([json], {
    type: 'application/json',
  });

  const url = URL.createObjectURL(blob);

  const link = document.createElement('a');
  link.href = url;
  link.download = filename;
  link.style.display = 'none';

  document.body.appendChild(link);
  link.click();
  document.body.removeChild(link);

  URL.revokeObjectURL(url);
}

Usage:
downloadJsonFile(
  {
    editor: 'VS Code',
    theme: 'dark',
    autosave: true,
  },
  'developer-settings.json'
);

This pattern is useful for:

exporting user settings
downloading generated reports
creating local backups
exporting analytics data
generating JSON, CSV, or text files from client-side state

The important part is cleanup:
URL.revokeObjectURL(url);

Whenever you create an object URL, you should also decide when to revoke it.
Processing Large Files in Chunks
Reading a large file all at once can hurt performance.
This looks harmless:
const reader = new FileReader();

reader.onload = () => {
  const content = reader.result;
  console.log(content);
};

reader.readAsText(file);

For small files, this is fine. For large files, it can freeze the page or consume too much memory.
The safer pattern is chunked processing.
A File is a kind of Blob, so it supports the slice() method. This allows you to read a file piece by piece.
async function processFileInChunks(
  file: File,
  chunkSize = 1024 * 1024
) {
  const totalChunks = Math.ceil(file.size / chunkSize);

  for (let chunkIndex = 0; chunkIndex < totalChunks; chunkIndex++) {
    const start = chunkIndex * chunkSize;
    const end = Math.min(start + chunkSize, file.size);

    const chunk = file.slice(start, end);

    await processChunk(chunk, chunkIndex, totalChunks);
  }
}

A simple chunk reader can look like this:
function readBlobAsText(blob: Blob): Promise<string> {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();

    reader.onload = () => {
      resolve(String(reader.result ?? ''));
    };

    reader.onerror = () => {
      reject(reader.error);
    };

    reader.readAsText(blob);
  });
}

async function processChunk(
  chunk: Blob,
  index: number,
  total: number
) {
  const text = await readBlobAsText(chunk);

  console.log({
    index,
    total,
    size: chunk.size,
    preview: text.slice(0, 80),
  });
}

This approach gives you more control over memory usage and makes it easier to show progress.
async function processFileWithProgress(
  file: File,
  onProgress: (percentage: number) => void
) {
  const chunkSize = 1024 * 1024;
  const totalChunks = Math.ceil(file.size / chunkSize);

  for (let index =…

Howto Undo Git Commits Without Breaking Your History
Tue, 19 May 2026 00:00:00 GMT
Almost every Git user eventually runs into the same problem.
A commit was created.
Then regret arrived.
Maybe the commit contains broken code. Maybe the wrong file slipped in. Maybe the commit message is terrible. Or maybe the commit was already pushed before anyone noticed the mistake.
At that point, people usually search:

How do I undo a Git commit?

Then the confusion begins.
Some tutorials recommend git reset.
Others say git revert.
Someone suggests checkout.
Then suddenly restore, amend, reflog, HEAD~1, force push, and several unfamiliar Git concepts appear all at once.
The frustrating part is that most of those answers are technically correct.
The real problem is simpler:
“Undoing a commit” can mean several completely different things.
You might want to:

remove the latest commit
remove a commit but keep your changes
undo something already pushed
restore a file
rewrite the previous commit
recover deleted history

Git provides different tools for each situation.
Once you understand that distinction, the command overload becomes much easier to understand.
What a Commit Actually Is
A Git commit is simply a saved snapshot of your project at a specific point in time.
If you've played video games, think about save points.
You reach a stable point, save progress, and continue experimenting.
Git works in a similar way.
A commit stores:

project state
file changes
author information
timestamp
commit message

Commits are then connected together into a history graph.
Why “Undo Commit” Causes So Much Confusion
This phrase sounds simple, but it hides several very different intentions.
Sometimes you want to remove the commit without touching your code.
Sometimes you want to remove both the commit and the changes.
Sometimes you should not remove anything at all — you only need to create a new commit that cancels an earlier one.
Different problem.
Different command.
That is why Git offers multiple approaches instead of a single universal "undo" button.
The Fast Cheat Sheet
If you want the shortest possible version:

Goal
Command

Remove local commit
git reset

Undo pushed commit safely
git revert

Restore file
git restore

Fix last commit
git commit --amend

Recover deleted history
git reflog

Now let’s break down what each command actually does.
Remove the Last Local Commit with git reset
Suppose you just created a commit:
git add .
git commit -m "Temporary experiment"

A few seconds later you realize:

That commit should not exist.

Use:
git reset HEAD~1

This removes the commit from history but keeps your file changes.
By default, Git also unstages your files.
Understanding HEAD~1
HEAD means:

the commit you are currently on

HEAD~1 means:

one commit earlier

Examples:
HEAD~1
HEAD~2
HEAD~3

move backward through history.
Soft Reset
If you want to remove the commit but keep staging intact:
git reset --soft HEAD~1

This keeps:

file changes
staged files

Useful when you only want to rewrite the commit message or slightly reorganize the commit.
Hard Reset
The dangerous version:
git reset --hard HEAD~1

This removes:

the commit
working directory changes
staged files

Your repository becomes identical to the previous commit.
Use this command carefully.
Undo a Pushed Commit with git revert
Once code has already been pushed, reset becomes risky.
History rewriting can break collaborators.
That is why Git provides:
git revert <commit-hash>

Instead of deleting history, Git creates a new commit that reverses the previous changes.
Example:
Before:
A → B → C

After:
git revert C

Result:
A → B → C → D

Where D cancels the changes introduced by C.
This makes revert the safest option for shared repositories.
Restore a Single File with git restore
Sometimes the entire commit is fine.
Only one file is wrong.
Imagine you broke:
config.js

Restore it:
git restore config.js

Git replaces the file with the version from the latest commit.
You can also restore from a specific commit:
git restore --source=HEAD~1 config.js

or:
git restore --source=a1b2c3d config.js

This is extremely useful when recovering earlier implementations.
Fix the Last Commit with git commit --amend
Sometimes the commit is mostly correct.
You simply forgot something.
Common cases:

missing file
bad commit message
small bug fix
forgotten config change

Use:
git commit --amend

Git opens the commit editor.
Update the message.
Save.
Done.
If you forgot a file:
git add missing-file.ts
git commit --amend

Git rebuilds the previous commit as if it had originally been created correctly.
Important Warning
amend rewrites history.
If the commit was already pushed, you may need:
git push --force

Use force push carefully.
Recover Deleted Work with git reflog
This command rescues many Git disasters.
Especially after accidental:
git reset --hard

Run:
git reflog

Example:
7f2a3c1 HEAD@{0}: reset: moving to HEAD~1
3b9d221 HEAD@{1}: commit: Add payment logic

Notice something important.
Your "deleted" commit is usually still recoverable.
Grab the hash:
git reset --hard 3b9d221

Repository restored.
Panic avoided.
Undo git add
Technically not a commit operation.
Still useful.
If you staged the wrong file:
git add .

Unstage it:
git restore --staged package.json

The file remains modified.
Git simply removes it from staging.
Which Command Should You Use?
Use:
git reset

when removing local commits.
Use:
git revert

when undoing pushed commits.
Use:
git restore

for recovering files.
Use:
git commit --amend

for repairing recent commits.
Use:
git…

GPT Shortcuts That Actually Work
Mon, 18 May 2026 00:00:00 GMT
TikTok, YouTube, Reddit, and Telegram are full of so-called “secret GPT commands.”
People constantly share prompts like:
IQ200
/UNFILTER
X10THINK
/RAW

usually claiming they unlock hidden reasoning modes, bypass restrictions, or somehow make the model dramatically smarter.
Most of these claims are exaggerated or completely false.
There is no hidden “superintelligence mode.” No secret admin console. No magical phrase that suddenly transforms a language model into something fundamentally different.
At the same time, some GPT shortcuts really are useful. Not because they unlock hidden systems, but because they communicate intent more clearly and efficiently.
That distinction matters.
This article breaks common GPT shortcuts into three groups:

shortcuts that genuinely help
shortcuts that work inconsistently
shortcuts that are basically internet mythology

The goal is not reverse engineering AI models. It is understanding which prompt patterns actually improve day-to-day work with language models.
Why GPT Shortcuts Sometimes Work
One of the biggest misconceptions about ChatGPT is the idea that it behaves like a terminal or command interpreter.
It does not.
When someone writes:
/REDTEAM

the model is not switching into a hidden mode.
Instead, it recognizes a familiar pattern from its training data and continues the conversation in a style associated with that pattern.
That is an important difference.
GPT shortcuts are essentially compact prompt instructions.
Some work well because they clearly describe the desired tone, structure, or behavior in a very short format.
Others fail because they are vague internet myths with no meaningful instruction behind them.
Another important detail is that model behavior is probabilistic.
A shortcut might work perfectly ten times in a row and then suddenly get ignored on the next attempt.
That inconsistency is normal.
EL5 Is Still One of the Most Useful Shortcuts
The classic:
EL5

stands for:
Explain Like I'm 5

This remains one of the most reliable shortcuts because it strongly influences how the model structures information.
Responses usually become:

simpler
shorter
more conversational
example-driven
less technical

For example:
EL5: Explain Docker containers

will usually produce analogies and simplified explanations instead of implementation details and infrastructure terminology.
For onboarding, teaching, and documentation, this shortcut is genuinely useful.
EL10 and EL15 Are Less Predictable
Variants like:
EL10
EL15

try to simulate different levels of understanding.
Sometimes they work reasonably well.
Sometimes they barely change the output.
The problem is that language models do not maintain a strict internal “age scale” for explanations.
If the goal is more advanced output, direct instructions are usually more effective.
For example:
Explain this like you're speaking to a senior backend engineer.

is typically more reliable than:
EL20

which often changes very little.
/STEP-BY-STEP Is Genuinely Helpful
One of the most practical shortcuts is:
/STEP-BY-STEP

This encourages the model to break problems into stages instead of jumping directly to conclusions.
It works especially well for:

programming
debugging
mathematics
architecture discussions
learning workflows

For example:
/STEP-BY-STEP Debug this React hydration error

usually produces a much clearer and more structured response than a generic debugging request.
This shortcut often improves reasoning visibility significantly.
/REDTEAM Produces Better Criticism
Another genuinely useful shortcut is:
/REDTEAM

This shifts the model toward critique instead of agreement.
The response becomes more skeptical, risk-focused, and analytical.
Useful scenarios include:

API security reviews
architecture analysis
business risks
performance bottlenecks
edge-case evaluation

Example:
/REDTEAM Analyze security problems in this authentication flow

In many cases, this produces much more valuable feedback than standard prompting.
/HUMAN Can Improve Tone
One of the most common complaints about AI-generated writing is that it sounds robotic.
The shortcut:
/HUMAN

sometimes helps reduce that problem.
It tends to push responses toward:

more conversational language
shorter sentences
softer transitions
less corporate phrasing

It does not magically produce perfect human writing, but it can noticeably improve tone in casual content.
Formatting Shortcuts Are Usually Reliable
Formatting commands tend to work better than abstract “thinking mode” prompts because they clearly define the expected output structure.
Examples include:
/BULLET
/TABLE
/CONCISE
/DETAIL

These shortcuts are practical because they solve real formatting problems.
For example:
/TABLE Compare React, Vue, and Svelte

usually generates a clean comparison table immediately.
Similarly:
/CONCISE

often reduces filler and shortens explanations.
While:
/DETAIL

typically increases elaboration and context depth.
These are among the most useful prompt shortcuts for everyday work.
/CODE Is Useful for Development Work
Another practical shortcut is:
/CODE python

or:
/CODE js

This usually shifts the response toward:

more implementation
less explanation
cleaner code-focused output

It is especially useful for:

prototyping
boilerplate generation
quick scripting
debugging snippets

Most “Thinking Mode” Commands Are Overhyped
This is where things become much less impressive.
Commands like:
X10THINK
X5THINK
IQ200
IQ150

are mostly placebo.
People often believe these prompts activate hidden reasoning systems or force the model to “think harder.”
That is not really what happens.
In practice, the model usually just:

writes longer responses
uses more complicated language
sounds more dramatic

There is no hidden intelligence switch.
Typing:
IQ200

does not suddenly make the model more intelligent.
The output may sound more sophisticated, but sounding smarter and reasoning better are not the same thing.
/UNFILTER Is Mostly Internet Mythology
Probably the most famous fake shortcut is:
/UNFILTER

People constantly claim it disables moderation systems or removes model restrictions.
It does not.
Modern language models do not expose a secret “disable safety” switch through prompts.
At best, the model may slightly change tone or formatting.
In most cases, nothing meaningful happens.
The same applies to:
/RAW

which supposedly reveals hidden prompts, internal state, o…

Best React Libraries and Tools in 2026
Tue, 12 May 2026 00:00:00 GMT
The Modern React Stack Explained for 2026
The React ecosystem changes faster than almost any other frontend ecosystem.
A few years ago, most projects looked nearly identical:

Create React App
Redux
Material UI
Formik
styled-components
webpack

Today, very few new React applications are built that way.
Modern React development in 2026 is shaped by several major shifts:

server-first rendering,
TypeScript-first APIs,
edge-ready runtimes,
monorepo tooling,
async React architecture,
AI-assisted workflows,
and significantly better developer experience.

Starting a new React project today can feel overwhelming because there are now dozens of excellent options in almost every category.
Should you use:

Next.js or TanStack Start?
Zustand or Jotai?
React Hook Form or TanStack Form?
shadcn/ui or Mantine?
Tailwind CSS or Panda CSS?
Vitest or Jest?
Better Auth or Auth.js?

The answer depends heavily on what kind of product you are building.
A SaaS dashboard has completely different requirements than:

a marketing site,
a collaborative editor,
an e-commerce storefront,
a browser-based design tool,
or a real-time analytics application.

This guide breaks down the modern React stack category by category and explains:

which tools became the new defaults,
which libraries are losing momentum,
which alternatives still make sense,
and what tradeoffs come with every major decision.

The goal is not to create a universal ranking.
Instead, the goal is to help developers understand how the React ecosystem actually looks in 2026.

React Ecosystem Trends in 2026
Before comparing libraries individually, it is important to understand the larger architectural trends shaping React development.
The React ecosystem in 2026 is no longer centered around building purely client-side applications.
Modern React applications increasingly focus on:

server-first rendering,
streaming interfaces,
async workflows,
edge execution,
AI-assisted experiences,
and shared type-safe contracts.

Several ecosystem-wide changes influenced nearly every major library:

Trend
Impact on the Ecosystem

React Server Components
Reduced client bundle sizes and moved data fetching closer to the server

TypeScript Everywhere
Libraries increasingly design APIs around type inference

AI-Assisted Development
Tooling shifted toward faster iteration and code generation workflows

Edge Deployment
Frameworks optimized for distributed execution

Monorepo Growth
Shared packages and workspace tooling became standard

Utility-First Styling
Tailwind and token-based systems became dominant

Async UI Patterns
Streaming and optimistic interfaces became common

These shifts explain why many older React patterns no longer feel modern.
For example:

heavy Redux architectures became less common,
large runtime CSS-in-JS systems lost momentum,
and traditional REST-heavy frontend architectures increasingly moved toward server actions and typed APIs.

Understanding these broader shifts makes it much easier to choose tools intentionally instead of simply following trends.

Visual Overview of a Modern React Stack
┌────────────────────────────────────────────┐
│                 Frontend                   │
├────────────────────────────────────────────┤
│ Next.js / TanStack Start / Remix           │
│ Tailwind CSS / shadcn/ui                   │
│ React Hook Form / TanStack Form            │
│ Zustand / Jotai                            │
│ TanStack Query                             │
└────────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────────┐
│              Shared Contracts              │
├────────────────────────────────────────────┤
│ TypeScript Types                           │
│ Zod Schemas                                │
│ API Contracts                              │
└────────────────────────────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────────┐
│                 Backend                    │
├────────────────────────────────────────────┤
│ Node.js / NestJS / Hono                    │
│ Drizzle ORM / Prisma                       │
│ PostgreSQL                                 │
│ Better Auth                                │
└────────────────────────────────────────────┘

This architecture became extremely common because it balances:

developer experience,
scalability,
maintainability,
and type safety.

Frameworks and Meta Frameworks
Next.js
Next.js is still the dominant React framework in 2026.
Its biggest advantage is ecosystem gravity.
You get:

React Server Components,
streaming,
route handlers,
server actions,
edge support,
image optimization,
metadata handling,
and deployment integration.

The App Router has matured significantly compared to the early React 18 transition period.
Modern Next.js applications usually combine:

server components for data-heavy pages,
client components only where interactivity is needed,
and server actions for mutations.

A typical modern Next.js stack often includes:
export default async function DashboardPage() {
  const projects = await getProjects();

  return (
    <DashboardLayout>
      <ProjectList projects={projects} />
    </DashboardLayout>
  );
}

Next.js is usually the safest choice for:

SaaS products,
content platforms,
dashboards,
e-commerce,
and hybrid server/client applications.

TanStack Start
TanStack Start became one of the most interesting alternatives to Next.js.
Instead of focusing heavily on conventions, it focuses on:

type safety,
route-based data loading,
modern caching,
and a highly composable architecture.

Developers who already use:

TanStack Router,
TanStack Query,
TanStack Form,
or TanStack Table

usually feel very comfortable inside the TanStack ecosystem.
TanStack Start especially shines in applications that require:

advanced client-side routing,
granular data fetching control,
optimistic updates,
and complex dashboard workflows.

Remix
Remix still has one of the cleanest mental models for full-stack React.

Friday Links #37 — JavaScript Trends & Tools
Fri, 01 May 2026 00:00:00 GMT

The JavaScript ecosystem doesn’t slow down—it evolves weekly. Friday Links #37 distills the most important updates across libraries, runtimes, tooling, and AI-driven development. From new releases pushing performance boundaries to emerging tools that simplify workflows, this issue highlights what’s worth your attention. Whether you’re building production systems or exploring new stacks, these curated picks help you stay informed without the noise.
🧠 Language & Runtime Updates
Node.js 26 (Current) — almost here
The upcoming release of Node.js 26 is expected to ship with V8 14.6 and enable the Temporal API by default—a major step toward handling dates natively without relying on third-party libraries.
JavaScript (ES2025 → ES2026)
The language continues evolving toward ES2026, with ongoing improvements to the standard library and deeper integration with AI-driven tooling and workflows.
🍋 Fresh 2.3 — the Deno-native full-stack framework — introduces first-class WebSocket support, eliminates unnecessary JavaScript for pages that don’t need it, and makes the View Transitions API effortless with a single attribute in your views.
📜 Articles & Tutorials
The end of responsive images
<dialog> and popover: Baseline layered UI patterns
Scroll-Driven Animations
How to Use Lazy Loading Without Hurting Web Performance
Compositing & Blending
Looking at New CSS Multi-Column Layout Wrapping Features
Recreating Apple’s Vision Pro Animation in CSS
Constructable Stylesheets and adoptedStyleSheets: One Parse, Every Shadow Root
CSS Recently In All Browsers
Session Timeouts: The Overlooked Accessibility Barrier In Authentication Design
The React Compiler at Eighteen Months: The Arc, the Debates, and What's Next
Migrating from Radix UI to Base UI: Step-by-Step Guide
font-family Doesn’t Fall Back the Way You Think
A Guide to React Compiler Rendering
⚒️ Tools
TypeScript 7.0 Beta — gaining traction
TypeScript 7 is generating significant discussion. It introduces a native compiler written in Go, promising substantial performance gains and a redesigned architecture for large-scale projects.
TypeScript 6 — a transitional release
TypeScript 6.0 acts as a bridge toward TS 7, bringing:
Deprecation of legacy APIs
Updated DOM typings
Adoption of modern import attributes (with)

Perry is a cross-platform TypeScript compiler that compiles code directly into native executables, offering an alternative to traditional JavaScript runtimes.
OpenWarp - Bring any AI model into your terminal
View Transitions Mock — a non-visual polyfill for the View Transitions API — provides a JavaScript implementation of same-document transitions without the visual layer. You can write a single code path for all browsers: supported ones render transitions, while others fall back to a DOM swap, with the same promises and API behavior.
DESIGN.md is a proposed format for describing a product’s visual identity—colors, typography, spacing, and UI rules—in a structured, machine-readable way. It’s designed for AI agents and tooling, enabling them to generate consistent interfaces, designs, or code based on a single source of truth.
Formisch — a schema-based, headless form library for JavaScript frameworks that handles form state and validation. It’s type-safe, fast by default, and keeps bundle size small thanks to its modular design.
Datatype is a variable font that turns text into charts, providing a unique way to visualize data.
Boneyard — generates pixel-perfect skeleton loading screens directly from your real UI, with no manual measurements or placeholder tuning.
Works across frameworks including React, Preact, Vue, Svelte 5, Angular, and React Native.
crashcat — a JavaScript physics engine built for games, simulations, and creative web projects. It includes rigid body simulation, support for multiple shape types, continuous collision detection, and more for building dynamic, interactive experiences.
officeParser — a robust, strictly typed library for Node.js and the browser that parses office documents into a clean, hierarchical AST. It preserves rich metadata, text formatting, and supports embedded attachments.
Bifrost — a high-performance AI gateway that unifies access to 15+ providers (including OpenAI, Anthropic, Amazon Web Services, and Google) through a single OpenAI-compatible API.
📚 Libs
Portless lets you replace port-based URLs with clean, stable local domains—so instead of http://localhost:3000, you can use something like https://myapp.localhost. It’s built on Node.js and now adds new features for Tailscale users.
Honker brings PostgreSQL-style NOTIFY/LISTEN semantics to SQLite—no daemon required. The honker-node package adds support for Node.js, making it easy to integrate event-driven messaging into your apps.
whatsapp-api-js — a lightweight, dependency-free library for interacting with the WhatsApp Cloud API, built for efficiency and full TypeScript support.
⌚ Releases
pnpm 11.0 Released
AVA 8.0 — the popular Node.js test runner is now fully ESM and introduces two new test modifiers: test.skipIf() and test.runIf().
BWIP-JS 4.10 — a pure JavaScript port of the origina…

Howto Use IMask.js for Input Masking in JavaScript Forms
Tue, 17 Mar 2026 00:00:00 GMT
Introduction
Form handling is one of the most underestimated parts of frontend development.
It looks simple: just a few inputs, maybe a submit button. But in reality, forms are where most user frustration happens. Incorrect formats, unclear validation rules, and inconsistent input behavior all lead to errors, abandoned flows, and bad data.
Input masking solves this at the source.
Instead of reacting to bad input after submission, you guide the user while they type.
In this article, we’ll go deep into IMask.js — a lightweight, flexible library that allows you to control input formatting in real time. This is not just a basic tutorial. You’ll learn patterns, edge cases, and production-ready practices.

Why Input Masking Is a Core UX Layer
Without masking:

users guess formats
validation fails often
error messages increase friction
backend receives inconsistent data

With masking:

input is guided instantly
errors are prevented early
formatting becomes predictable
UX feels faster and more professional

Masking is not just visual formatting — it's a data normalization layer at the UI level.

What Makes IMask.js Different
IMask.js stands out because it combines flexibility with performance.
Key characteristics:

no dependencies
small bundle (~15kb gzipped)
works with plain JS and frameworks
supports multiple mask types
allows custom logic via functions
handles mobile input well

Unlike many libraries, IMask doesn’t lock you into one approach. It gives you primitives to build your own behavior.

Installation
pnpm add imask

import MaskCore from "imask"

Mental Model of IMask
Before writing code, understand how IMask works internally.
There are three key concepts:

Input Element – the DOM node
Mask Configuration – rules defining formatting
Mask Instance – runtime controller

const inputNode = document.querySelector("#phone")

const maskController = MaskCore(inputNode, {
  mask: "+{1} (000) 000-0000"
})

The instance acts as a bridge between raw input and formatted output.

Basic Example: Phone Input
<input id="contact-phone" placeholder="+1 (___) ___-____" />

const phoneNode = document.querySelector("#contact-phone")

const phoneController = MaskCore(phoneNode, {
  mask: "+{1} (000) 000-0000"
})

As the user types, formatting is applied automatically.

Static Masks (Fixed Structure)
Use static masks when format is strictly defined.
const cardNode = document.querySelector("#card")

const cardController = MaskCore(cardNode, {
  mask: "0000 0000 0000 0000"
})

Best for:

credit cards
IDs
formatted codes

Dynamic Masks (Multiple Formats)
const phoneDynamic = MaskCore(document.querySelector("#phone"), {
  mask: [
    { mask: "+{1} (000) 000-0000" },
    { mask: "+{44} 0000 000000" }
  ]
})

IMask automatically selects the correct pattern based on input.

Number Mask (Currency & Prices)
const amountNode = document.querySelector("#amount")

const currencyController = MaskCore(amountNode, {
  mask: Number,
  min: 0,
  max: 1000000,
  thousandsSeparator: ",",
  radix: ".",
  precision: 2,
  prefix: "$ "
})

This handles:

formatting
decimal precision
limits
separators

Date Mask
const dateNode = document.querySelector("#date")

const dateController = MaskCore(dateNode, {
  mask: Date,
  pattern: "yyyy-mm-dd",
  lazy: false
})

This prevents invalid formats like 2026-99-99.

Regex Mask
const emailNode = document.querySelector("#email")

const emailController = MaskCore(emailNode, {
  mask: /^\S+@\S+\.\S+$/
})

Good for:

simple validation rules
constrained input

Function Mask (Full Control)
const evenNode = document.querySelector("#even")

const evenController = MaskCore(evenNode, {
  mask: (value) => {
    const parsed = Number(value)
    return parsed % 2 === 0 ? value : value.slice(0, -1)
  }
})

This approach is powerful but should be used carefully.

Real-World Example: Credit Card Detection
const ccNode = document.querySelector("#cc")

const ccController = MaskCore(ccNode, {
  mask: "0000 0000 0000 0000"
})

ccController.on("accept", () => {
  const raw = ccController.unmaskedValue

  let type = "unknown"

  if (/^4/.test(raw)) type = "visa"
  else if (/^5[1-5]/.test(raw)) type = "mastercard"
  else if (/^3[47]/.test(raw)) type = "amex"

  console.log(type)
})

Events System
IMask exposes lifecycle hooks:
maskController.on("accept", () => {
  console.log(maskController.value)
})

maskController.on("complete", () => {
  console.log("complete")
})

maskController.on("reject", (input) => {
  console.log("rejected", input)
})

These allow integration with UI state, validation, and analytics.

Advanced Configuration
MaskCore(inputNode, {
  mask: "0000-00-00",
  lazy: true,
  nullable: false,
  unmask: true,
  placeholderChar: "_",
  prepare: (val) => val.toUpperCase(),
  validate: (val) => val.length === 10
})

Important options:

lazy → allow partial input
unmask → return raw value
prepare → transform input
validate → enforce rules

React Integration
import { useEffect, useRef } from "react"
import MaskCore from "imask"

export function MaskedInput() {
  const nodeRef = useRef(null)

  useEffect(() => {
    const instance = MaskCore(nodeRef.current, {
      mask: "+{1} (000) 000-0000"
    })

    return () => instance.destroy()
  }, [])

  return <input ref={nodeRef} />
}

Common Pitfalls
1. Changing Value Directly
Wrong:
inputNode.value = "123"

Correct:
maskController.value = "123"

2. Autofill Conflicts
<input autocomplete="off" />

Or sync manually:
inputNode.addEventListener("change", () => {
  maskController.updateValue()
})

3. Mobile Input Issues
Use:
lazy: true

to reduce input jitter.

Best Practices

keep masks readable
avoid over-engineering regex
always use unmaskedValue for backend
keep commits atomic (if integrating with forms logic)
test on mobile devices

When NOT to Use Masking
Avoid masking when:

input is free text
validation is business-driven (not format-driven)
accessibility would suffer

Conclusion
IMask.js is not just a utility — it's a UX upgrade.
It allows you to:

enforce structure at input level
reduce validation complexity
improve perceived performance
create predictable user flows

Once integrated properly, your forms stop being fragile.
They become reliable systems.
And in modern frontend development, that’s a huge advantage.

Git for Beginners: Branches, Commits, and Your First Pull Request
Mon, 16 Mar 2026 00:00:00 GMT
Git is one of the most important tools in modern software development. Nearly every team relies on it to manage source code, collaborate, and track project history.
Yet for beginners, Git often feels intimidating.
Developers create branches with names like test123 or asd. Commits say things like “update”, “fix”, or even “...”. Pull requests contain dozens of unrelated files, temporary changes, and sometimes even accidental edits.
And the worst part? Many developers don’t realize this is a problem.
In a real team environment, sloppy Git usage quickly turns into chaos. Imagine trying to find the commit that broke the build when the history looks like this:
fix
update
changes
fix again

Good luck.
Git is not just a storage system for code.
It is a communication tool between developers.
In this guide, you'll learn how Git actually works and how to use it in a way that makes collaboration smooth and professional.
Git Is Not Magic — It’s Just a Graph
Before learning commands, it's important to understand what Git really stores.
Git keeps project history as a graph of commits.
Each commit represents a snapshot of the project at a specific moment in time.
A commit contains:

file changes
author information
timestamp
a unique hash
a commit message

A branch is simply a pointer to a commit.
When you create a new commit, the branch pointer moves forward.
A simplified commit graph might look like this:
A --- B --- C (main)
       \
        D --- E (feature/auth)

In this example:

main contains the stable project history
feature/auth is a separate branch for developing a new feature
once the feature is complete, it gets merged back into main

This isolation is what allows teams to work safely without interfering with each other.
Types of Git Branches
For small projects, teams often only use one main branch and a few temporary branches.
But larger projects usually follow a structured workflow. One popular example is Git Flow.
Git Flow defines several types of branches.
Main branches
main
The production-ready branch.
Everything here should be stable and deployable.
develop
The integration branch where new features are combined before release.
Temporary branches
feature/*
Branches used to develop new functionality.
Example:
feature/user-authentication

release/*
Used to prepare a new release.
Tasks may include:

bug fixes
documentation updates
version bumps

hotfix/*
Urgent fixes applied directly to production code.
Example:
hotfix/security-patch

A simpler workflow for beginners
Most teams teaching Git to newcomers use a simpler model:
main
  ├─ feature/add-login
  ├─ feature/create-api
  └─ fix/email-validation

Each task gets its own branch.
When the task is done, the branch is merged and deleted.
Creating Your First Branch
git clone https://github.com/example/project.git

Move into the project directory:
cd project

Make sure your main branch is up to date:
git switch main
git pull origin main

Now create a new branch for your task:
git switch -c feature/add-user-model

This command:

creates a new branch
switches to it immediately

Older Git versions used:
git checkout -b feature/add-user-model

Both commands do the same thing.
Naming Branches Correctly
Branch naming conventions matter more than beginners think.
Bad example:
branch1
new-feature
test

Good examples:
feature/add-user-service
bugfix/login-error
hotfix/token-expiration

General rules:

use lowercase
avoid spaces
use hyphens or slashes
avoid non-ASCII characters

Clear names help the entire team understand what the branch contains.
Making Meaningful Commits
After writing some code, the next step is creating commits.
Imagine we add a simple JavaScript class:
class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

Before committing, Git needs to know which files to include.
Add the file to the staging area:
git add src/main/project/User.js

You can also add all changes:
git add .

But this is risky — temporary files might accidentally be committed.
It is usually safer to add files explicitly.
Creating the commit
git commit -m "Add User class"

This works, but the message could be better.
A good commit message answers two questions:

What changed?
Why did it change?

Writing Good Commit Messages
A commonly used structure is:
Short summary (max ~50 characters)

Detailed explanation of why the change was needed.
Explain important technical details if necessary.

Example:
Add User class for authentication module
Stores name and email fields used in login flow.
Email must be unique and will be validated by database
constraints in the next task.

Good commit messages help future developers understand the reasoning behind code changes.
And often that future developer is you six months later.
Conventional Commits
Many teams use the Conventional Commits standard.
It adds a prefix describing the type of change.
Examples:
feat: add password reset endpoint
fix: prevent crash on empty email
docs: update installation guide
refactor: move validation logic to service
test: add login unit tests
chore: update dependencies

Common prefixes:

Prefix
Meaning

feat
new feature

fix
bug fix

docs
documentation changes

style
formatting only

refactor
code improvements without behavior change

test
new or updated tests

chore
tooling or configuration changes

Example commit history:
feat: add User entity
fix: validate email format
refactor: extract email validation utility
test: add negative login tests

This makes the project history easy to understand.
It also enables tools that automatically generate changelogs.
Sending Code to GitHub
Once your work is committed, push it to the remote repository.
git push origin feature/add-user-model

If the branch doesn't exist on the server yet, Git will create it.
After pushing, go to GitHub (or GitLab) and you'll see a button:
Create Pull Request
What Is a Pull Request?
A Pull Request (PR) is a request to merge your changes into another branch.
Usually:
feature branch → main

Pull requests allow teammates to:

review code
suggest improvements
detect bugs early

This …

Meet Effect TS: A New Way to Structure TypeScript Apps
Fri, 13 Mar 2026 00:00:00 GMT
The JavaScript ecosystem evolves extremely fast. New frameworks appear
constantly, each promising better performance, better developer
experience, or a simpler programming model.
Effect TS is different.
It is not primarily a UI framework. It is not a backend framework in the
traditional sense either. Instead, Effect is an attempt to solve
something deeper: how complex TypeScript applications should be
structured.
Most real-world applications suffer from the same problems:

asynchronous code becomes messy
errors are unpredictable
dependency injection becomes fragile
background tasks are hard to manage
libraries do not compose well together

Effect TS approaches these problems from a new angle. Instead of solving
them separately, it introduces a unified programming model where
errors, dependencies, concurrency, and resources are all part of the
type system.
At first glance this model may look unusual. But once developers start
building real systems with it, many realize that it solves issues they
previously handled with dozens of separate libraries.
This article introduces the core ideas behind Effect and explains why
more developers are experimenting with it in their TypeScript projects.

Why Developers Are Trying Effect
Effect has been gaining attention because it combines several powerful
ideas into a single framework.
Below are ten practical reasons why developers start exploring it.
1. Errors Become Part of the Type System
Traditional JavaScript error handling is chaotic. A function can throw
anything: an Error instance, a string, or even an arbitrary object.
In many projects this leads to code where the real failure scenarios are
not clearly defined.
Effect changes this by making errors explicit.
Instead of writing:
async function getUser(id: string): Promise<User>

you describe both success and failure:
Effect<User, UserNotFoundError | NetworkError>

Now the compiler knows exactly which errors are possible. When those
errors are handled later, the type system verifies that no cases were
forgotten.
This makes applications far more predictable.

2. Dependency Injection Without Magic
Many backend frameworks use dependency injection containers based on
decorators or runtime reflection.
While these systems work, they also hide dependencies behind runtime
behavior.
Effect takes a different approach.
Dependencies are represented directly in types. If a function requires a
service, the type signature reflects that requirement. The compiler
ensures the dependency is provided before the program runs.
This eliminates an entire category of runtime errors.

3. Testing Becomes Much Simpler
Because dependencies are explicit, testing becomes easier.
Instead of mocking modules globally or configuring complicated
containers, you can simply replace a service implementation with a test
version.
This leads to tests that are:

easier to understand
easier to maintain
less dependent on internal implementation details

For large systems this improvement alone can be extremely valuable.

4. Everything Is Designed to Compose
Effect encourages a compositional style of programming.
Instead of deeply nested async code, logic is built as small pieces that
combine through pipelines.
For example:
pipe(
  fetchUsers(),
  Effect.map(filterActiveUsers),
  Effect.tap(logUserCount),
  Effect.flatMap(saveUsers)
)

Each step transforms the previous result.
This approach keeps complex workflows readable and easy to refactor.

5. Gradual Adoption Is Possible
One of the biggest advantages of Effect is that it does not require
rewriting an entire application.
Existing Promise-based code can be wrapped using helper utilities.
Effects can also be executed as regular Promises.
This means teams can adopt Effect incrementally. A project might start
with a few critical services and expand from there.

6. Concurrency Is Built Into the Model
JavaScript applications often require complex asynchronous workflows.
Typical solutions involve combining:

Promise.all
retry libraries
AbortController
custom scheduling logic

Effect replaces this with a unified concurrency model.
The framework provides tools for:

parallel execution
task cancellation
retries with backoff
scheduling
background tasks

All using the same abstractions.

7. A Rich Built-In Toolkit
Effect is not just a runtime. It also includes a large ecosystem of
utilities.
Examples include:

Streams
Queues
PubSub channels
Schedulers
Date/time helpers
transactional memory
schema validation

Instead of installing many unrelated libraries, developers often rely on
the tools provided by Effect itself.
This reduces fragmentation in large codebases.

8. Observability Is Built In
Modern applications require visibility into their behavior.
Logging, metrics, and tracing are essential for debugging and monitoring
production systems.
Effect integrates observability directly into the framework and supports
standards such as OpenTelemetry.
This makes it easier to instrument applications without complex
integrations.

9. A Growing Ecosystem
The core Effect team maintains several official packages that extend the
framework.
Some examples include:

@effect/platform -- platform utilities like HTTP and filesystem
@effect/sql -- typed database access
@effect/cli -- command‑line application framework
@effect/rpc -- typed remote procedure calls
@effect/cluster -- primitives for distributed systems
@effect/ai -- abstractions for language model integrations

Because these packages follow the same design philosophy, they integrate
smoothly with each other.

10. Strong Type Feedback Helps AI Tools
AI‑assisted development tools rely heavily on compiler feedback.
Effect's strong typing provides extremely clear signals when generated
code is incorrect.
This often leads to faster corrections and fewer runtime bugs when using
AI coding assistants.

The Core Idea: Effects
At the heart of the framework lies a single abstraction:
Effect<A, E, R>

This type represents a computation.
The three parameters describe:
A --- the successful result

E --- the error type

R --- required dependencies
Compared to a Promise, which only represents success, Effect provides a
complete description of a computation.
This allows the compiler to reason about behavior that would otherwise
only appear at runtime.

Creating Effects
The framework provides several helpers for constructing effects.
For example:
const value = Effect.succeed(42)

Creating a failure:
const error = Effect.fail("Unexpected error")

Wrapping synchronous logic:
const random = Effect.sync(() => Math.random())

These operations describe work rather than executing it immediatel…

Howto Deploy OpenClaw and Build Your Personal AI Second Brain
Fri, 13 Mar 2026 00:00:00 GMT
Most AI assistants today are little more than chat interfaces. They
answer questions but cannot access your tools, remember your
preferences, or perform real work. OpenClaw takes a different approach.
Instead of functioning purely as a chatbot, OpenClaw acts as a
programmable cognitive partner. It can:

remember long‑term context
connect to external tools
automate workflows
run entirely on infrastructure you control

This guide explains how to deploy OpenClaw from scratch and configure it
on Windows, macOS, or Linux.
By the end of this tutorial you will have a working OpenClaw instance
running locally.

Why Use OpenClaw
Private Deployment
All conversations and memory stay on your own machine or server.
Tool Integration
OpenClaw can interact with tools such as:

GitHub
calendars
APIs
automation workflows

Persistent Memory
OpenClaw includes both short‑term and long‑term memory, allowing it
to remember:

user preferences
project details
conversation context

Open Source
OpenClaw is released under the MIT license, meaning the entire system is
fully auditable and customizable.

System Requirements
Minimum environment:
Node.js 18+
npm or pnpm
8 GB RAM recommended
2 GB disk space

Supported platforms:

macOS
Linux
Windows (PowerShell or WSL2)

Verify Your Environment
macOS / Linux
node --version
npm --version

If Node is missing, install it from:
Node.js

Installation Method 1: One‑Step Installer
macOS / Linux
curl -fsSL https://docs.openclaw.ai/install.sh | bash
After installation open:
http://localhost:18789
Windows (PowerShell)
Clone the repository and start the gateway manually:
git clone https://github.com/openclawai/openclaw.git
cd openclaw
npm install
npm run start:gateway

Windows with WSL2 (Recommended)
Install WSL:
wsl --install
Then inside WSL:
curl -fsSL https://docs.openclaw.ai/install.sh | bash
Access the interface via:
http://localhost:18789

Installation Method 2: Manual Installation
Clone Repository
git clone https://github.com/openclawai/openclaw.git
cd openclaw

Install Dependencies
npm install -g pnpm
pnpm install

or
npm install
Configure Workspace
macOS / Linux
export OPENCLAW_WORKSPACE=~/.openclaw/workspace
mkdir -p $OPENCLAW_WORKSPACE

Windows PowerShell
setx OPENCLAW_WORKSPACE "%USERPROFILE%\.openclaw\workspace"
mkdir %USERPROFILE%\.openclaw\workspace

Copy Configuration
cp config.example.yaml config.yaml
Windows
copy config.example.yaml config.yaml
Start Gateway
pnpm start:gateway

Docker Deployment
Create docker-compose.yml
    version: "3.8"

    services:
      openclaw:
        image: ghcr.io/openclaw/openclaw:latest
        container_name: openclaw
        ports:
          - "18789:18789"
          - "18792:18792"
        environment:
          - OPENCLAW_WORKSPACE=/workspace
          - NODE_ENV=production
        volumes:
          - ./workspace:/workspace
          - ./config.yaml:/app/config.yaml
          - ./logs:/var/log/openclaw
        restart: unless-stopped

Start the container:
docker-compose up -d
View logs:
docker-compose logs -f

Configuring AI Models
Example configuration in config.yaml:
    agents:
      defaults:
        model: "siliconflow/deepseek-ai/DeepSeek-V3.2"

Alternative models:
openai/gpt-4
anthropic/claude-3-opus
google/gemini-2.0

Enabling Skills
Skills allow OpenClaw to interact with external services.
Example configuration:
    skills:
      enabled:
        - github
        - weather

Install additional skills:
openclaw skills install github

Creating Your First Custom Skill
Create directory:
mkdir ~/.openclaw/workspace/skills/my-skill
Create SKILL.md:
## Custom Skill

### Description
Automation skill for internal APIs.

### Usage
/my-skill [arguments]

### Capabilities
- API access
- file reading
- workflow automation

Troubleshooting
Port Already In Use
macOS / Linux
lsof -i :18789
Windows
netstat -ano | findstr 18789
Kill process:
Linux/macOS
pkill -f openclaw
Windows
taskkill /PID <pid> /F

Conclusion
OpenClaw is more than a chatbot. It is a programmable AI platform
capable of integrating with real workflows, remembering context, and
evolving through custom skills.
Once deployed, it can become a powerful personal AI infrastructure
layer that helps automate tasks, analyze code, and manage complex
workflows.
For developers interested in building their own AI ecosystem, OpenClaw
provides a strong foundation for creating a true digital second
brain.

Friday Links #36 — JavaScript Ecosystem Weekly
Fri, 13 Mar 2026 00:00:00 GMT

The JavaScript ecosystem never slows down.

Over the past two weeks we’ve seen major updates across runtimes, frameworks, tooling, and security.
In this issue of Friday Links, we highlight the most interesting developments across the JavaScript world — from infrastructure changes and new tools to security research and ecosystem trends.
🧠 Ecosystem Highlights
TypeScript 6 Prepares the Path to TS7
The TypeScript team released an early preview of TypeScript 6.
This release is mainly about internal changes preparing for the future Go-based compiler planned for TypeScript 7.
Key goals:

faster compilation
reduced memory usage
better incremental builds
improved large project performance

Large monorepos could see dramatic speed improvements once the Go compiler lands.
Deno 2.7 Improves Node Compatibility
The latest Deno runtime release continues improving Node compatibility.
Highlights:

improved npm integration
Node API compatibility
Temporal API stabilization

Example:
const now = Temporal.Now.instant()
console.log(now.toString())

📜 Articles & Tutorials
Under the hood: Security architecture of GitHub Agentic Workflows
Beating JavaScript Performance Limits With Rust and N-API: Building a Faster Image Diff Tool
The Different Ways to Select <html> in CSS
The Big Gotcha of Anchor Positioning
How to steal npm publish tokens by opening GitHub issues
How to Decode a VIN in JavaScript
Making a Flappy Bird clone using pure HTML and CSS, no JavaScript
How to build a pnpm monorepo, the right way
React is changing the game for streaming apps with the Activity component
Using CSS animations as state machines to remember focus and hover states with CSS only
You Don’t Know HTML Tables
5 React Hooks Techniques to Improve Component Performance
⚒️ Tools
Repomix — Turn Any Repo Into a Single AI-Readable File

Repomix packs an entire repository into a single AI-friendly document.
Cursor Cloud Telegram Connector
npmx is an experimental tool designed to improve npm package exploration.
Wely — Lightweight Web Component Framework
Ink allows developers to build CLI tools using React components.
Cron Expression Generator
📚 Libs
Node File Trace - determines exactly which files a Node application needs to run.
JavaScript Minification Benchmarks: SWC Still Leads
RevoGrid - High-Performance Data Grid Component
VMPrint - A pure-JS, tiny typesetting engine with bit-perfect PDF output on everything—from Cloudflare Workers to the browser.
markdown-to-jsx -  A very fast and versatile markdown toolchain. Output to AST, React, React Native, SolidJS, Vue, HTML, and more!
clipboardy -  Access the system clipboard (copy/paste)
⌚ Releases
Solid v2.0.0 Beta: The <Suspense> Era Comes to an End
After a long experimental phase, Solid 2.0 has released its first beta, introducing native asynchronous reactivity as a core feature of the framework.
In this new model, reactive computations can directly return Promises or async iterables, and Solid’s reactive graph will automatically suspend and resume around those async operations. This removes much of the complexity developers previously had to manage when dealing with asynchronous state.
One notable change is that <Suspense> has been retired. For initial renders, it is now replaced by a simpler component called <Loading>.
Astro 6 is here!
Node.js 25.8.0 (Current)
ESLint v10.0.3 released
Ember 6.11 Released
Ionic Framework 8.8
React Native 0.85 RC.0, pnpm 10.32, Jest 30.3, Recharts 3.8,
OpenPlayer.js 3.0.2, Prisma 7.5, SQLite JS 1.3, React Helmet Async 3.0, Preact 10.29.0
📺 Videos
Build Your Own Video Sharing App – Loom Clone with Next.js and Mux JavaScript Tutorial
You Can Just Ship Agents: Architecting for the Agentic Era | Dom Sipowicz, Vercel
The Future of TypeScript
Build Your Own Video Sharing App – Loom Clone with Next.js and Mux JavaScript Tutorial
Cloudflare just slop forked Next.js…
7 new open source AI tools you need right now…
Zod
Valibot

Zod has been the standard for years. Valibot, however, is a newer library designed with a different philosophy: smaller bundles and faster validation.

Why Validation Libraries Matter
TypeScript provides compile‑time guarantees, but it cannot guarantee runtime correctness.
Example:
const response = await fetch("/api/user/1")
const user = await response.json()

Runtime data might not match expectations.
Validation libraries ensure data integrity before it reaches business logic.

Validating API Responses with Valibot
import * as v from "valibot"

const ProductSchema = v.object({
  id: v.number(),
  title: v.string(),
  price: v.number(),
  rating: v.number(),
  images: v.array(v.string())
})

type Product = v.InferOutput<typeof ProductSchema>

export async function loadProduct(id:number):Promise<Product>{

  const res = await fetch(`https://dummyjson.com/products/${id}`)
  const data = await res.json()

  try{
    return v.parse(ProductSchema,data)
  }
  catch(error){
    console.error("Invalid API response",error)
    throw new Error("Product validation failed")
  }

}

Validating Form Input
import * as v from "valibot"

const RegistrationSchema = v.object({

  username:v.pipe(
    v.string(),
    v.minLength(3)
  ),

  email:v.pipe(
    v.string(),
    v.email()
  ),

  age:v.pipe(
    v.string(),
    v.digits(),
    v.transform(Number)
  ),

  password:v.pipe(
    v.string(),
    v.minLength(6)
  )

})

type RegistrationData = v.InferOutput<typeof RegistrationSchema>

Cross‑Field Validation
const RegistrationSchema = v.pipe(

  v.object({

    email:v.pipe(
      v.string("Email must be text"),
      v.email("Enter a valid email")
    ),

    age:v.pipe(
      v.string(),
      v.digits("Age must contain digits"),
      v.transform(Number),
      v.minValue(18,"You must be at least 18")
    ),

    password:v.pipe(
      v.string(),
      v.minLength(6,"Password must contain at least 6 characters")
    ),

    confirmPassword:v.string()

  }),

  v.forward(
    v.partialCheck(
      [["password"],["confirmPassword"]],
      ({password,confirmPassword}) => password === confirmPassword,
      "Passwords do not match"
    ),
    ["confirmPassword"]
  )

)

Code Comparison
Valibot
import * as v from "valibot"

const BookSchema = v.object({
  title:v.string(),
  price:v.number()
})

v.parse(BookSchema,{title:"JavaScript Guide",price:30})

Zod
import {z} from "zod"

const BookSchema = z.object({
  title:z.string(),
  price:z.number()
})

BookSchema.parse({title:"JavaScript Guide",price:30})

Benchmark Scripts
Valibot
import * as v from "valibot"

const schema = v.object({
 id:v.number(),
 name:v.string(),
 price:v.number(),
 rating:v.number(),
 tags:v.array(v.string())
})

const sample = {
 id:1,
 name:"Laptop",
 price:1500,
 rating:4.8,
 tags:["tech","computer"]
}

function benchmarkValibot(iterations:number){

 const start = performance.now()

 for(let i=0;i<iterations;i++){
  v.parse(schema,sample)
 }

 return performance.now() - start

}

console.log("Valibot:",benchmarkValibot(10000),"ms")

Zod
import {z} from "zod"

const schema = z.object({
 id:z.number(),
 name:z.string(),
 price:z.number(),
 rating:z.number(),
 tags:z.array(z.string())
})

const sample = {
 id:1,
 name:"Laptop",
 price:1500,
 rating:4.8,
 tags:["tech","computer"]
}

function benchmarkZod(iterations:number){

 const start = performance.now()

 for(let i=0;i<iterations;i++){
  schema.parse(sample)
 }

 return performance.now() - start

}

console.log("Zod:",benchmarkZod(10000),"ms")

Benchmark Results
Valid data

Library
min (ms)
max (ms)

Valibot
26.58
27.31

Zod
67.02
70.25

Invalid data

Library
min (ms)
max (ms)

Valibot
48.63
54.70

Zod
143.63
147.79

Bundle Size
Replacing Zod with Valibot reduced bundle size by ~11.4 KB (gzip) in a medium project.

Popularity

Library
Weekly downloads

Valibot
~1.2M

Zod
~89.5M

Conclusion
Validation libraries protect applications from unreliable external data.
Valibot proves that validation can be fast, lightweight, and developer‑friendly.
For new projects, Valibot is definitely worth considering.

Why Blindly Using JSON.parse() Can Be Dangerous
Fri, 06 Mar 2026 00:00:00 GMT
If you write JavaScript for long enough—whether in the browser or on a Node.js server—you’ll almost certainly use JSON.parse() countless times.
It’s one of the most common APIs in the ecosystem.
Developers rely on it for everything from reading configuration files to handling API requests:
const user = JSON.parse(localStorage.getItem("user"))

const payload = JSON.parse(req.body.payload)

const config = JSON.parse(fs.readFileSync("config.json", "utf-8"))

It’s simple, fast, and built directly into the language.
But here’s the problem:

Many developers treat JSON.parse() as a harmless utility, when in reality it can become a security risk if used carelessly.

The function itself isn’t dangerous—but blindly parsing untrusted input can expose your application to attacks such as:

Prototype pollution
Denial of Service (DoS)
Data injection attacks
Unexpected runtime crashes

In this article, we’ll explore why this happens and how to implement secure JSON parsing strategies in modern JavaScript applications.
Understanding What JSON.parse() Actually Does
JSON.parse() converts a JSON string into a JavaScript object.
Example:
const json = '{"name": "Alice", "role": "admin"}'

const user = JSON.parse(json)

console.log(user.name)
// Alice

The function faithfully reconstructs the entire object structure contained in the JSON string.
That includes every property name provided by the input.
And that’s where the problems start.
Security Risk #1: Prototype Pollution
One of the most common vulnerabilities related to unsafe JSON handling is prototype pollution.
Prototype pollution occurs when attackers manipulate an object's prototype to inject properties into every object in the application.
If your code merges or copies parsed objects without validation, an attacker can inject special keys like:
__proto__
constructor
prototype

These keys can modify global object behavior.
Example of a Prototype Pollution Payload
const payload = '{"__proto__": {"isAdmin": true}}'

Now imagine parsing it and merging the object into your system:
const data = JSON.parse(payload)

Object.assign({}, data)

console.log({}.isAdmin)
// true

Suddenly every object in your application has a new property.
This can lead to severe consequences:

Authentication bypass
Privilege escalation
Corrupted application logic
Security policy violations

Many well-known vulnerabilities in JavaScript ecosystems have involved prototype pollution through unvalidated input.
Why This Happens
JavaScript objects inherit from Object.prototype.
If attackers manage to inject properties into the prototype chain, the impact becomes global.
For example:
console.log({}.toString)

This works because every object inherits from Object.prototype.
If attackers add properties there, every object in your system changes behavior.
Security Risk #2: Denial of Service (DoS)
Another common attack vector is resource exhaustion.
Attackers can send extremely large or deeply nested JSON strings that consume huge amounts of CPU or memory during parsing.
Example: Deep Nesting Attack
const evil = '{"a":{"a":{"a":{"a":{"a":{"a":{}}}}}}}'

Even small nested objects can cause heavy recursion.
With enough depth, parsing can freeze the event loop.
Example: Huge Array Attack
const payload = `[${"1,".repeat(10000000)}1]`

A JSON string representing ten million elements can:

Allocate gigabytes of memory
Freeze Node.js for seconds
Crash the process with an Out Of Memory error

For public APIs, this effectively becomes a remote kill switch.
Secure JSON Parsing Strategy
The safest approach combines three defensive layers:

Input size limits
Key filtering
Schema validation

Let’s look at each one.
Step 1: Limit Input Size
Before parsing JSON, always check the size of the input.
function safeParse(jsonString, maxSize = 100 * 1024) {
  if (typeof jsonString !== "string") {
    throw new Error("Invalid input type")
  }

  if (jsonString.length > maxSize) {
    throw new Error("JSON payload too large")
  }

  return JSON.parse(jsonString)
}

This prevents attackers from sending extremely large payloads.
In production APIs, limits are often set between 50KB and 1MB, depending on use case.
Step 2: Block Dangerous Keys
JavaScript allows a reviver function when parsing JSON.
This lets you inspect every property during parsing.
You can use it to reject suspicious keys.
function secureParse(jsonString) {
  return JSON.parse(jsonString, (key, value) => {
    if (key === "__proto__" || key === "constructor" || key === "prototype") {
      throw new Error("Forbidden key detected")
    }

    return value
  })
}

This simple check prevents prototype pollution payloads.
Step 3 (Best Practice): Runtime Schema Validation
Modern JavaScript applications rarely trust raw data.
Instead, they validate data structures using schema validation libraries like:

Zod
Joi
Yup
Ajv

These tools ensure the parsed data matches an expected structure.
Example Using Zod
import { z } from "zod"

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().email(),
  isAdmin: z.boolean().optional()
})

function parseUser(json) {
  const parsed = secureParse(json)

  return UserSchema.parse(parsed)
}

Benefits:

Automatic runtime validation
Clear error messages
Type inference for TypeScript
Protection against unexpected fields

Schema validation is considered modern best practice in production systems.
Additional Risks in Node.js
Server environments are especially vulnerable because JSON often comes from external sources.
Common risky inputs include:
HTTP Requests
req.body

Uploaded Configuration Files
Users may upload JSON configuration files.
If parsed blindly, they can trigger crashes.
Database Data
Stored JSON may contain unexpected fields or corrupted structures.
Third-Party Webhooks
External services send JSON payloads that should never be trusted blindly.
Recommended Defensive Checklist
Before parsing JSON in production systems, verify:

The data source is trusted
The payload size is limited
Dangerous keys are filtered
The structure matches a schema

This layered approach dramatically reduces attack surfaces.
Is JSON.parse() Actually Unsafe?
Not exactly.
JSON.parse() itself does not execute JavaScript code.
Unlike eval(), it only reconstructs objects.
However:

Using it without validating input is equivalent to trusting user data blindly.

And trusting user input is one of the most common sources of security vulnerabilities.
Final Thoughts
JSON.parse() is not a bad API.
But using it without safeguards is like handling a powerful tool without protective equipm…

Tailwind CSS v4 vs MUI, Ant Design & Styled Components
Fri, 06 Mar 2026 00:00:00 GMT
In 2026, picking a styling approach is less about taste and more about architecture.
Teams don’t just “choose CSS.” They choose:

how design decisions are encoded and shared,
how fast UI can change without regressions,
how much runtime work happens on every render,
how quickly a codebase accumulates styling debt,
and how portable the solution is across frameworks and products.

This article compares four popular directions:

Tailwind CSS v4 (utility-first styling engine)
MUI and Ant Design (component libraries with strong opinions)
Styled Components (CSS-in-JS)

The goal isn’t to crown a universal winner. It’s to help you pick the right tool for your system’s constraints.
1. These tools are different “layers” of the stack
The biggest mistake is to compare them as if they are interchangeable.
MUI and Ant Design: component systems (not just styling)

MUI and Ant Design are ready-made UI component ecosystems. You’re not just getting colors and spacing. You’re getting:

behavior,
accessibility (A11Y) defaults,
keyboard navigation,
focus management in modals,
edge-case handling that took years to harden.

If you need to ship an internal admin tool quickly, this matters.
But you pay for it in other ways:

They impose a DOM structure (wrappers, internal elements, slots).
They impose an opinionated design language (Material for MUI, Ant’s system for Ant).
Customization often becomes an ongoing negotiation between your design system and theirs.

If your product design is “close enough” to their defaults, you move fast.
If your goal is “pixel-perfect Figma that looks like none of the defaults,” you can end up fighting the library.
Tailwind v4: styling engine (not a component library)

Tailwind doesn’t know what a Date Picker is. It doesn’t ship one. It gives you low-level primitives to build your own.
Tailwind’s advantage is control:

you decide markup structure,
you decide constraints,
you can match a custom design system without constantly overriding component internals.

Tailwind v4 also reduced setup friction: you can start with a single CSS import (@import "tailwindcss";) instead of the older directive-heavy setup.
Styled Components: component-local styling with runtime generation
Styled Components sits between the two extremes:

not a component library,
but tightly binds CSS to components.

This is productive—until the project grows and you start asking:

Which styles are still used?
Which are dead?
What’s the real cost of style generation during renders?
How do we maintain consistent tokens without duplicating logic across many components?

Tailwind and CSS-in-JS solve different problems. If you treat them as the same category, you’ll make architectural tradeoffs accidentall
2. Performance: static CSS vs runtime style generation
Performance isn’t just about “Tailwind is fast.” It’s about where work happens.
Runtime overhead (especially visible at scale)
CSS-in-JS solutions and some UI libraries generate and manage styles at runtime. That means:

extra JavaScript execution,
extra style insertion/management,
more work during render-heavy scenarios (large tables, infinite lists, fast state updates).

Tailwind’s output is static CSS. The browser receives it once and applies it like normal styles.
That’s not automatically “always faster,” but it changes the performance profile in a way that becomes very noticeable in high-frequency UI updates.
Build performance in Tailwind v4
Tailwind v4 shipped with a “ground-up” performance rewrite and a faster build engine—reported as up to ~5× faster full builds and 100× faster incremental builds in the official announcements and coverage.
That matters in real teams because build speed directly affects:

iteration loops,
design token tweaking,
refactoring velocity,
developer experience.

3. “Self-cleaning CSS”: why dead styles don’t stick around (as much)
Large projects die by a thousand cuts—most of them are “small”:

unused classes,
abandoned component variants,
theme overrides nobody remembers,
CSS specificity battles that accumulate over years.

The typical CSS-in-JS failure mode
CSS-in-JS keeps styles “close” to components, which is great for local reasoning.
But when components get removed or rewritten, styles can still remain in the bundle depending on usage patterns, exports, barrel files, and how build tooling marks code as reachable.
Teams end up with a question they can’t easily answer:

“Is this style still used anywhere?”

Tailwind’s approach: generate only what’s referenced
Tailwind’s workflow is built around scanning your source for class usage and generating the necessary CSS for those classes. That “only what you used” approach is central to Tailwind’s output model.
So when you delete a component, the classes that disappear from your markup will stop being included in the compiled CSS.
This is one reason Tailwind projects often avoid the classic “CSS landfill” problem.
What about helpers like tailwind-variants?
Utilities like tailwind-variants (or any class-composition helper) don’t change the fundamental logic: Tailwind still cares about class strings it can discover. The important architectural point is that Tailwind’s output is driven by class usage, not “a stylesheet someone forgot to delete.”
4. Design tokens: from Figma to code without losing alignment
Modern UI teams don’t want “colors in CSS.” They want tokens:

--color-brand
--spacing-section
--radius-card
--font-sans

Tailwind v4’s CSS-first theming
Tailwind v4 introduced a CSS-first workflow where theme variables are defined using the @theme directive. Tailwind describes these as special CSS variables that influence which utilities exist.
Example:
@import "tailwindcss";

@theme {
  --color-brand: oklch(0.55 0.22 260);
  --color-brand-hover: oklch(0.45 0.22 260);
  --font-sans: "Inter", system-ui;
  --spacing-section: 4rem;
}

Once defined, Tailwind can expose utilities based on those variables (for example, color-related tokens become usable via utility classes). The docs describe how theme variables map into usable styling in your project.
Then UI usage becomes simple and consistent:
export function BrandButton() {
  return (
    <button className="bg-brand hover:bg-brand-hover text-white px-4 py-2 rounded">
      Button
    </button>
  );
}

This token-driven flow aligns well with Figma Variables / token pipelines because it creates a single “source of truth” layer that can be shared across apps.
How this compares to MUI / Styled Components theming
MUI theming is powerful, but it typically lives in JavaScript objects and flows through providers and library AP…

JavaScript Note: ToggleEvent.source and dialog.closedBy
Fri, 06 Mar 2026 00:00:00 GMT
The modern web platform continues evolving with small but powerful
improvements. Two recent additions --- ToggleEvent.source and the
closedby attribute for <dialog> --- make working with dialogs
and popovers significantly easier.
ToggleEvent.source allows developers to determine which element
triggered a popover or dialog visibility change, while closedby
allows you to declare how a dialog can be closed without writing
extra JavaScript.
These additions move the web platform further toward declarative UI
behavior.

ToggleEvent.source
The source property of the ToggleEvent interface is a
read‑only reference to the element that triggered the toggle event.
In simple terms, it tells you:

Which element opened or closed a popover or dialog.

The property returns an instance of Element.
If the visibility change was triggered programmatically, the value
will be null.
Browser support
Most modern browsers already support the property. Safari currently
exposes it behind an experimental flag.

Elements that can trigger popovers
A popover can be triggered by:

<button commandfor="..."> commandfor attribute
<button popovertarget="..."> popovertarget attribute
<input type="button" popovertarget="...">

Elements that can behave as popovers

<dialog>
Any element with the popover attribute

Example
Consider a dialog with multiple buttons that close it.
We want to determine which button closed the dialog and display the
result.
<div>
  <button commandfor="my-dialog" command="show-modal">
    Show modal dialog
  </button>

  <dialog id="my-dialog">
    <h3>Do you like modern Web APIs?</h3>

    <div style="display:flex; gap:10px">
      <button commandfor="my-dialog" command="close" data-answer="yes">
        Yes
      </button>

      <button commandfor="my-dialog" command="close" data-answer="sure">
        Sure
      </button>
    </div>
  </dialog>

  <p>No answer yet</p>
</div>

Now we listen for the toggle event.
const paragraph = document.querySelector("p");

document.querySelector("dialog").addEventListener("toggle", (event) => {

  if (!(event.source instanceof HTMLButtonElement)) return;

  const { answer } = event.source.dataset;

  if (answer) {
    paragraph.textContent = `Answer: ${answer}`;
  }

});

With ToggleEvent.source, determining the trigger element becomes
trivial.
<Codepen id="019cbfd7-7afe-776d-afbe-461c3c60fb50" />
HTMLDialogElement.closedBy
The closedby attribute defines which user actions are allowed to
close a dialog.
Previously, developers often needed custom JavaScript logic to control
this behavior. Now it can be defined directly in HTML.
This attribute is supported by all major browsers (Safari currently ships it behind an experimental flag).

Supported closing actions
Dialogs can be closed by:

Clicking outside the dialog on the overlay (light dismiss).
Platform actions such as pressing Esc.
A developer-defined action such as a button calling
dialog.close().

Attribute values
any
The dialog can be closed using all methods above.
closerequest
The dialog can be closed by:

pressing Esc
developer-defined logic

none
The dialog can only be closed programmatically or by explicit UI
controls.

Default behavior
The default value depends on how the dialog is opened.
If opened using: showModal(), the default becomes: closerequest.
Otherwise the default is: none
Why this matters
Before closedby, implementing overlay click closing required JavaScript logic, such as custom hooks (useClickOutside in React).
Now this behavior can be defined purely declaratively.

Example with multiple dialogs
<div class="demo">
  <button class="open" commandfor="dlg-any" command="show-modal">
    Open dialog (closedby="any")
  </button>

  <!-- 1) closedby="any" -->
  <dialog id="dlg-any" closedby="any">
    <div class="dialog">
      <header class="header">
        <h3>Dialog A — closedby="any"</h3>
        <button class="icon" commandfor="dlg-any" command="close" aria-label="Close">
          &times;
        </button>
      </header>

      <p>
        This dialog can be closed by clicking the backdrop, pressing Esc, or using a Close button.
      </p>

      <footer class="footer">
        <button class="cancel" commandfor="dlg-any" command="close">Close</button>

        <button class="confirm" commandfor="dlg-closerequest" command="show-modal">
          Open dialog B
        </button>
      </footer>
    </div>
  </dialog>

  <!-- 2) closedby="closerequest" -->
  <dialog id="dlg-closerequest" closedby="closerequest">
    <div class="dialog">
      <header class="header">
        <h3>Dialog B — closedby="closerequest"</h3>
        <button class="icon" commandfor="dlg-closerequest" command="close" aria-label="Close">
          &times;
        </button>
      </header>

      <p>
        This dialog closes via Esc or explicit controls. Clicking the backdrop should NOT close it.
      </p>

      <footer class="footer">
        <button class="cancel" commandfor="dlg-closerequest" command="close">Close</button>

        <button class="confirm" commandfor="dlg-none" command="show-modal">
          Open dialog C
        </button>
      </footer>
    </div>
  </dialog>

  <!-- 3) closedby="none" -->
  <dialog id="dlg-none" closedby="none">
    <div class="dialog">
…

How to Build an LRU Cache from Scratch in JavaScript
Fri, 06 Mar 2026 00:00:00 GMT
Caching is a fundamental optimization technique used across nearly every modern software system. Whether you're building a web API, a database engine, or a frontend application, caching can dramatically improve performance by storing frequently accessed data in memory.
One of the most common cache eviction strategies is LRU (Least Recently Used). You’ll encounter it in systems like Redis, operating systems, browser caches, and backend frameworks. It also appears frequently in technical interviews because implementing it correctly requires understanding both data structures and time complexity.
Many developers initially find LRU confusing, especially because interview questions usually require O(1) time complexity for both retrieval and insertion operations. However, once you understand the right combination of data structures, the implementation becomes surprisingly elegant.
In this guide, we’ll build an LRU cache from scratch, following a clear progression:

Understanding what LRU actually means
Defining the required operations
Choosing the right data structures
Implementing the cache step by step
Testing the implementation
Avoiding common mistakes

By the end, you'll have a production-ready LRU cache implementation in JavaScript.
What Is an LRU Cache?
LRU stands for Least Recently Used.
The idea is simple:

When the cache reaches its capacity, remove the item that hasn't been used for the longest time.

Every time an item is accessed or inserted, it becomes the most recently used entry.
A Simple Real-World Analogy
Imagine a small bookshelf that can only hold three books.
Capacity = 3
Step 1
Add Algorithms

Step 2
Add Java
[Algorithms, Java]

Step 3
Add Python
[Algorithms, Java, Python]

The shelf is now full.
Step 4 – Access "Algorithms"
Because you used it recently, it moves to the end:
[Java, Python, Algorithms]

Step 5 – Add "JavaScript"
Since the shelf is full, remove the least recently used item (Java):
[Python, Algorithms, JavaScript]

This behavior is exactly how an LRU cache works.
Core Requirements of an LRU Cache
In most implementations (and interviews), the cache supports two operations.

Operation
Description
Required Complexity

get(key)
Return the value associated with the key, or -1 if not found. Also mark it as recently used.
O(1)

put(key, value)
Insert or update a value. If capacity is exceeded, remove the least recently used item.
O(1)

The O(1) requirement is critical.
If operations become O(n), the implementation is no longer optimal.
Why Arrays Won’t Work
A naive solution might store items in an array.
But arrays cause problems:
Finding an item
Requires scanning → O(n)
Moving an item
Requires shifting elements → O(n)
Removing the least used item
Also O(n)
This violates the O(1) requirement.
So we need a better approach.
The Key Insight: Combine Two Data Structures
To achieve constant time operations, we combine:
1. Hash Map (Map)
Provides:
key → node

Benefits:

Instant lookup
O(1) access

But a Map cannot track usage order.
2. Doubly Linked List
Maintains item order:
Least used  ←→  Most used

Benefits:

Fast removal
Fast insertion
Fast reordering

Operations on linked lists can be O(1) if you already have the node reference.
Final Architecture
We combine both structures:
Map:
key → linked list node

Doubly Linked List:
[Least Recently Used ... Most Recently Used]

Rules

Head = least recently used
Tail = most recently used

Step 1: Create a Linked List Node
Each node stores:

key
value
previous pointer
next pointer

class CacheNode {
  constructor(key, value) {
    this.key = key
    this.value = value
    this.prev = null
    this.next = null
  }
}

Important detail:
We store the key inside the node so we can remove it from the Map during eviction.
Step 2: Implement a Doubly Linked List
We’ll use sentinel (dummy) nodes for easier boundary handling.
class DoublyLinkedList {
  constructor() {
    this.head = new CacheNode(null, null)
    this.tail = new CacheNode(null, null)

    this.head.next = this.tail
    this.tail.prev = this.head

    this.length = 0
  }

  remove(node) {
    node.prev.next = node.next
    node.next.prev = node.prev

    node.prev = null
    node.next = null

    this.length--
  }

  addToEnd(node) {
    const prevLast = this.tail.prev

    prevLast.next = node
    node.prev = prevLast
    node.next = this.tail
    this.tail.prev = node

    this.length++
  }

  removeFirst() {
    if (this.length === 0) return null

    const first = this.head.next
    this.remove(first)

    return first
  }

  size() {
    return this.length
  }
}

Step 3: Build the LRU Cache
Now we combine the Map and linked list.
class LRUCache {
  constructor(capacity) {
    if (capacity <= 0) {
      throw new Error("Capacity must be greater than zero")
    }

    this.capacity = capacity
    this.cache = new Map()
    this.list = new DoublyLinkedList()
  }

  get(key) {
    if (!this.cache.has(key)) {
      return -1
    }

    const node = this.cache.get(key)

    this.list.remove(node)
    this.list.addToEnd(node)

    return node.value
  }

  put(key, value) {
    if (this.cache.has(key)) {
      const node = this.cache.get(key)

      node.value = value

      this.list.remove(node)
      this.list.addToEnd(node)

      return
    }

    if (this.list.size() === this.capacity) {
      const removed = this.list.removeFirst()

      if (removed) {
        this.cache.delete(removed.key)
      }
    }

    const newNode = new CacheNode(key, value)

    this.list.addToEnd(newNode)
    this.cache.set(key, newNode)
  }
}

Testing the Implementation
Let's verify the behavior.
function testLRUCache() {
  const cache = new LRUCache(3)

  cache.put("Algorithms", 1)
  cache.put("Java", 2)
  cache.put("Python", 3)

  console.log(cache.get("Algorithms"))
  // 1

  cache.put("JavaScript", 4)

  console.log(cache.get("Java"))
  // -1 (evicted)

  console.log(cache.get("JavaScript"))
  // 4

  cache.put("Python", 33)

  console.log(cache.get("Python"))
  // 33
}

testLRUCache()

If the output matches expectations, the cache works correctly.
Common Mistakes Developers Make
1. Forgetting to store the key in nodes
Without the key, eviction cannot remove the Map entry.
2. Using a singly linked list
Deleting nodes becomes O(n) because the previous node must be searched.
3. Not using sentinel nodes
This causes many edge cases when inserting or deleting.
4. Forgetting to update the size counter
This breaks capacity checks.
5. Updating value without updating position
Accessing an item sho…

How to Build a Safe JSON Parser for Node.js APIs
Fri, 06 Mar 2026 00:00:00 GMT
Parsing JSON in Node.js looks trivial at first glance.
Most developers start with something like this:
const data = JSON.parse(rawBody)

And for a while, that feels good enough.
Then real traffic arrives.
A client sends malformed JSON. A webhook includes fields you did not expect. A bot posts a giant payload. A malicious user tries to poison object prototypes. Suddenly, one innocent-looking JSON.parse() call turns into a source of crashes, broken validation, or security issues.
That is why production APIs should not parse JSON blindly.
A safer approach is to build a JSON parser wrapper that handles the boring but critical work for you:

reject oversized payloads
block dangerous keys
validate structure at runtime
return consistent errors
integrate cleanly with Express, Fastify, Hono, or custom Node.js servers

In this article, we will build a reusable safe JSON parser wrapper for Node.js APIs, explain the design decisions behind it, and finish with production-ready examples you can adapt to your own backend.
Why a Wrapper Is Better Than Plain JSON.parse()
JSON.parse() is not bad. It is fast, built-in, and perfectly fine when the input is trusted.
The real problem is this:

In APIs, input is often untrusted.

That includes:

request bodies
webhooks
uploaded JSON files
queue messages
Redis payloads
database JSON blobs
third-party callbacks

When raw input comes from outside your system, parsing should do more than just convert a string into an object.
A proper parser layer should answer these questions:

Is the payload too large?
Is the JSON valid?
Does it contain suspicious keys?
Does it match the shape the API expects?
Can the application return a clean error instead of crashing?

That is exactly what a wrapper solves.
What a Safe JSON Parser Should Do
A strong implementation should provide five protections.
1. Type checks
Only strings or buffers should be accepted as raw JSON input.
2. Payload size limits
This helps reduce DoS risk and prevents huge request bodies from consuming memory.
3. Dangerous key filtering
Keys like __proto__, constructor, and prototype can become a problem in unsafe merge flows.
4. Runtime validation
Even valid JSON is not necessarily valid application data.
5. Consistent error handling
The API should return predictable, human-readable errors instead of generic crashes.
The Core Design
We will build the wrapper in layers.
First, a small custom error class.
Then a secure parser with size checks and key filtering.
Then a schema-aware parser using Zod.
Finally, an Express middleware example.
This approach keeps the code modular and easy to test.
Step 1: Create Custom Error Types
A parser wrapper becomes much easier to integrate when it throws structured errors instead of generic Error objects.
export class JsonParseError extends Error {
  public readonly statusCode: number
  public readonly code: string
  public readonly details?: unknown

  constructor(message: string, options?: {
    statusCode?: number
    code?: string
    details?: unknown
  }) {
    super(message)
    this.name = "JsonParseError"
    this.statusCode = options?.statusCode ?? 400
    this.code = options?.code ?? "INVALID_JSON"
    this.details = options?.details
  }
}

This gives the rest of the application useful metadata:

statusCode for HTTP responses
code for machine-readable error handling
details for debugging or validation reports

Step 2: Define Safe Defaults
Now define the parser configuration.
export type SafeJsonParserOptions = {
  maxBytes?: number
  forbiddenKeys?: string[]
}

const DEFAULT_FORBIDDEN_KEYS = ["__proto__", "constructor", "prototype"]

const DEFAULT_OPTIONS: Required<SafeJsonParserOptions> = {
  maxBytes: 100 * 1024,
  forbiddenKeys: DEFAULT_FORBIDDEN_KEYS,
}

These defaults are intentionally conservative.
A 100KB default is reasonable for many APIs, but you can raise or lower it depending on your use case.
For example:

small JSON commands: 10KB
standard API forms: 50KB to 200KB
large content payloads: 500KB to 1MB
file uploads: do not parse with raw JSON.parse() at all

Step 3: Normalize Raw Input
In Node.js, raw request data may arrive as a string or a buffer.
A wrapper should handle both cleanly.
function normalizeInput(raw: string | Buffer): string {
  if (typeof raw === "string") {
    return raw
  }

  if (Buffer.isBuffer(raw)) {
    return raw.toString("utf8")
  }

  throw new JsonParseError("Unsupported input type", {
    code: "INVALID_INPUT_TYPE",
  })
}

This prevents accidental misuse and keeps the main parser logic simpler.
Step 4: Enforce a Payload Size Limit
Before calling JSON.parse(), check size first.
This is one of the easiest and most effective hardening steps.
function assertPayloadSize(raw: string, maxBytes: number): void {
  const byteLength = Buffer.byteLength(raw, "utf8")

  if (byteLength > maxBytes) {
    throw new JsonParseError(
      `JSON payload exceeds the ${maxBytes} byte limit`,
      {
        statusCode: 413,
        code: "PAYLOAD_TOO_LARGE",
        details: { maxBytes, actualBytes: byteLength },
      }
    )
  }
}

Why check bytes instead of string.length?
Because network payloads are measured in bytes, not characters. UTF-8 characters can take more than one byte, so Buffer.byteLength() is the safer choice.
Step 5: Reject Dangerous Keys During Parsing
The reviver argument of JSON.parse() lets you inspect every key-value pair during parsing.
That makes it a good place to block suspicious keys.
function createSecureReviver(forbiddenKeys: string[]) {
  const blocked = new Set(forbiddenKeys)

  return function secureReviver(key: string, value: unknown) {
    if (blocked.has(key)) {
      throw new JsonParseError(`Forbidden key found in JSON: ${key}`, {
        code: "FORBIDDEN_JSON_KEY",
        details: { key },
      })
    }

    return value
  }
}

This does not magically solve all object safety issues across your application, but it reduces risk significantly when dealing with untrusted payloads.
Step 6: Build the Base Safe Parser
Now combine the pieces into one reusable function.
import { JsonParseError } from "./json-parse-error"

export type SafeJsonParserOptions = {
  maxBytes?: number
  forbiddenKeys?: string[]
}

const DEFAULT_FORBIDDEN_KEYS = ["__proto__", "constructor", "prototype"]

const DEFAULT_OPTIONS: Required<SafeJsonParserOptions> = {
  maxBytes: 100 * 1024,
  forbiddenKeys: DEFAULT_FORBIDDEN_KEYS,
}

function normalizeInput(raw: string | Buffer): string {
  if (typeof raw === "string") {
    return raw
  }

  if (Buffer.isBuffer(raw)) {
    return raw.toString("utf8")
  }

  throw new JsonParseError("Unsupported input type", {
    code: "INVALID_INPUT_TYPE",
  })
}

function assertPayloadSize(raw: string, maxBytes: number): void {
  const byteLength = Buffer.byteLength(raw, "utf8")

  if (byteLength > maxBytes) {
    throw new JsonParseError(
      `JSON payload exceeds the ${maxBytes} byte limit`,
      {
     …

Friday Links #35: Dev Tools, AI & JS Ecosystem Updates
Fri, 27 Feb 2026 00:00:00 GMT

Another week, another wave of interesting releases across the JavaScript ecosystem. From emerging developer tools and AI-powered workflows to framework updates and experimental projects, the pace of innovation keeps accelerating.
In Friday Links #35, we’ve gathered the most notable discoveries worth a developer’s attention — tools that improve productivity, libraries pushing frontend boundaries, and projects that might quietly become tomorrow’s standards.
Whether you're building production apps, experimenting with AI tooling, or just staying current with modern web development, this week’s picks have something valuable to explore.
📜 Articles & Tutorials
Building Next.js for an agentic future
Yes, Learning to Code Is Still Valuable
Potentially Coming to a Browser :near() You 
Death to Scroll Fade!
6 React Server Component performance pitfalls in Next.js
Virtual Scrolling for Billions of Rows — Techniques from HighTable
Getting Started with the Vercel AI SDK in Node.js
Loop Performance Anti-Patterns: A 40-Repository Scan and Six-Module Benchmark Study
Reduce the JS Workload with no- or lo-JS options
Tips on How to Pick the Right Icons for Your Website
AGENTS.md outperforms skills in our agent evals
border-shape: the future of the non-rectangular web
An in-depth guide to customising lists with CSS
Loading Smarter: SVG vs. Raster Loaders in Modern Web Design
⚒️ Tools
React Doctor - is an open-source CLI tool created by the Million.js (millionco) team that scans React codebases and automatically detects common issues: anti-patterns, performance bottlenecks, accessibility gaps, architectural flaws, and even critical security vulnerabilities that can quietly slip into production.
SVAR React Gantt - is a modern, high-performance Gantt chart component designed specifically for React applications.
LLM Timeline
The JavaScript Oxidation Compiler
Blop - A typed language for the web that compiles to Virtual DOM. Blop uses real control flow statements — for loops, if/else — directly in templates, without JSX constraints.
Sciter – Embeddable HTML/CSS/JavaScript Engine for modern UI development
BullMQ - Message Queue and Batch processing for NodeJS, Python, Elixir and PHP based on Redis
TanStack Hotkeys -  Type-Safe keyboard shortcuts library with awesome devtools
Mina Rich Editor - A powerful, elegant rich text editor built with Shadcn UI. Experience unparalleled customization, beautiful design, and seamless integration. Built with React, TypeScript, and meticulous attention to detail.

Temporal Playground — an interactive online environment for experimenting with the JavaScript Temporal API, allowing developers to run real code and explore modern date and time handling directly in the browser.
Zerobyte - Powerful backup automation for your remote storage
📚 Libs
voxcss -  A CSS voxel engine. A 3D grid for the DOM. Renders HTML cuboids by stacking grid layers and applying transforms.
portless - Replace port numbers with stable, named .localhost URLs. For humans and agents.
react-split-pane -  React split-pane component
Basic FTP -  FTP client for Node.js, supports FTPS over TLS, passive mode over IPv6, async/await, and Typescript.
Lume.js - Minimal reactive state management using only standard JavaScript and HTML. No custom syntax, no build step required, no framework lock-in.
fp-pack -  A functional toolkit focused on type-safe pipelines, not FP dogma, for JavaScript and TypeScript.
tambo -  Generative UI SDK for React
⌚ Releases
Biome v2.4—Embedded Snippets, HTML Accessibility, and Better Framework Support
Prsma 7.4.0 Released
Phaser Editor v5 Beta now available
Emscripten 5.0.2 — the well-established LLVM-to-WebAssembly compiler that enables running native low-level code in Node.js without native bindings — receives internal cleanups, removing legacy Node-specific workarounds that are no longer required.
Hono 4.12 — a lightweight, multi-runtime web framework built around Web Standards, designed to run seamlessly across Node.js, Bun, Deno, Cloudflare Workers, and other edge environments.
Orange ORM 5.2 — a powerful and modern ORM designed for efficient database interaction, offering type-safe queries, clean abstractions, and strong performance across modern JavaScript runtimes.
ESLint 10.0.2 Released
📺 Videos
TanStack Router - How to Become a Routing God in React
Build Your Own Claude Code with Mastra Workspaces
Build & Deploy AI Agent Workflow Builder using NextJs, Mongodb, React, Prisma, Upstash
How One Engineer and AI Crashed IBM's Stock Price
The wild rise of OpenClaw...
My Multi-Agent Team with OpenClaw
Understanding SOLID Principles

Why SOLID Still Matters in React
SOLID principles were originally introduced for object-oriented programming by Robert C. Martin.
React is not object-oriented in the classical sense.
Yet modern React applications map surprisingly well to SOLID ideas:

OOP Concept
React Equivalent

Class
Component

Method
Hook / handler

Dependency
Service / API

Composition
Component composition

Abstraction
Hook interface

React didn’t remove architecture problems.
It simply changed where they appear.
Let’s explore the three SOLID principles that have the biggest real-world impact in React systems.

Single Responsibility Principle (SRP) in React
Software architecture often sounds abstract until a project starts
growing. Messy components, duplicated logic, and unpredictable bugs
begin to appear.
The Single Responsibility Principle states:

A module should have only one reason to change.

In React, responsibilities usually split into:

data logic
rendering
composition

SRP does not mean:

one function
small component
minimal lines of code

Instead, it means:
A module should change for one category of reason.
Bad Example
export function AccountProfile() {
  const [profile, setProfile] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("/api/profile")
      .then(res => res.json())
      .then(data => {
        setProfile(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <p>Loading...</p>;

  return (
    <section>
      <h2>{profile.name}</h2>
      <p>{profile.email}</p>
    </section>
  );
}

Component responsibilities:

fetching data
managing state
rendering UI

Multiple reasons to change.
Correct SRP Architecture
A scalable React architecture separates logic from presentation.
Data Hook
export function useProfileData() {
  const [profile, setProfile] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("/api/profile")
      .then(res => res.json())
      .then(setProfile)
      .finally(() => setLoading(false));
  }, []);

  return { profile, loading };
}

This hook answers one question:
How do we obtain data?
Nothing else.
View Component
export function ProfileView({ profile, loading }) {
  if (loading) return <p>Loading...</p>;

  return (
    <section>
      <h2>{profile.name}</h2>
      <p>{profile.email}</p>
    </section>
  );
}

Pure UI.
No knowledge about APIs or storage.
Container
export function ProfileContainer() {
  const state = useProfileData();
  return <ProfileView {...state} />;
}

Now each part has one responsibility.
Changing backend logic never affects rendering.

Real SRP Benefit
SRP enables:

safer refactoring
reusable UI components
independent testing
predictable scaling

Large React applications survive long-term mainly because of this separation.
Open Closed Principle (OCP) in React
The Open Closed Principle states:

Software entities should be open for extension but closed for
modification.

You should add new behavior without rewriting existing components.
Typical Violation
export function ActionButton({ type, onClick }) {
  if (type === "primary") {
    return <button className="primary" onClick={onClick}>Primary</button>;
  }

  if (type === "danger") {
    return <button className="danger" onClick={onClick}>Danger</button>;
  }

  if (type === "success") {
    return <button className="success" onClick={onClick}>Success</button>;
  }

  return null;
}

Every new variation requires modifying the component.
Over time this becomes fragile and error-prone.
OCP-Friendly Approach
const buttonVariants = {
  primary: "primary",
  danger: "danger",
  success: "success",
};

export function ActionButton({ variant, onClick, children }) {
  return (
    <button
      className={buttonVariants[variant]}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

Adding new behavior:
buttonVariants.warning = "warning";

No component modification required.
Composition-Based Extension
Modern React strongly favors composition.
export function Button({ className, ...props }) {
  return <button className={className} {...props} />;
}

export function DangerButton(props) {
  return <Button className="danger" {...props} />;
}

export function PrimaryButton(props) {
  return <Button className="primary" {...props} />;
}

The base abstraction remains stable while functionality grows externally.
This is OCP applied naturally.

Dependency Inversion Principle (DIP)
This principle separates scalable architecture from tightly coupled applications.
Definition:

High-level modules should not depend on low-level modules.

Translated to React:
UI should not depend directly on infrastructure.
Hidden Dependency Problem
export function OrdersPage() {
  const [orders, setOrders] = useState([]);

  useEffect(() => {
    fetch("/api/orders")
      .then(r => r.json())
      .then(setOrders);
  }, []);
}

This component depends directly on:

transport layer
backend structure
API implementation

Backend change → UI rewrite.
Introducing Abstraction
Provider Interface
export interface OrdersProvider {
  getOrders(): Promise<any[]>;
}

Concrete Implementation
export class ApiOrdersProvider implements OrdersProvider {
  async getOrders() {
    const res = await fetch("/api/orders");
    return res.json();
  }
}

Hook Depends on Abstraction
export function useOrders(provider: OrdersProvider) {
  const [orders, setOrders] = useState([]);

  useEffect(() => {
    provider.getOrders().then(setOrders);
  }, [provider]);

  return orders;
}

SQL Crash Course: JOINs, CTEs, and Window Functions
Mon, 23 Feb 2026 00:00:00 GMT
SQL is one of the very few technologies in software engineering that
does not fade with trends.
Frameworks change every few years. Backend stacks rotate. Frontend
ecosystems reinvent themselves. But SQL stays.
That is not nostalgia. That is infrastructure.
SQL became the universal language of data. Whether a team uses
PostgreSQL, MySQL, ClickHouse, Snowflake, or something distributed and
exotic --- chances are, they still speak SQL.
Understanding SQL today is not optional for serious developers.
Backend engineers need it to avoid pushing database logic into
application code. Analysts rely on it daily. QA engineers use it to
validate system state. Product managers use it to inspect metrics
without waiting for analytics pipelines.
This article walks through SQL step by step --- from simple SELECT
queries to advanced window functions --- using practical examples and a
PostgreSQL‑friendly syntax.

1. Database Anatomy: What We Actually Work With
Before writing queries, it helps to understand what the database really is.
A relational database is simply structured tables connected by rules. Think of it as Excel with strict discipline — no messy types, no broken references, no silent mistakes.
Each table contains:

Columns (structure)
Rows (actual data)

The power comes from constraints and relationships.
Unlike spreadsheets, relational databases enforce:
. Strong typing
. Explicit relationships
Primary Keys and Foreign Keys
Primary Key (PK) --- unique row identifier.
Foreign Key (FK) --- reference to another table's primary key.
Example:

users(id, name)
orders(id, user_id, total)

orders.user_id references users.id.
This guarantees consistency: the database will reject an order for a
non‑existent user.
Common Data Types
Most projects rely on a core set:

INT / BIGINT --- numeric identifiers and counters
TEXT / VARCHAR --- strings
TIMESTAMPTZ --- date-time stored in UTC
JSONB (PostgreSQL) --- flexible semi‑structured data

Always store timestamps in UTC. Convert on the client side.

2. Reading Data: SELECT
The most common SQL operation is reading.
Basic query:
SELECT name, price
FROM products;

Avoid:
SELECT *
FROM products;

Why? Because production systems scale. Fetching unnecessary columns wastes bandwidth, memory, and sometimes performance advantages from indexes.
Aliases
SELECT
  name AS product_name,
  price AS product_price
FROM products;

This is especially helpful in complex JOIN queries.
DISTINCT
Use DISTINCT when you care about unique values, not raw rows.
SELECT DISTINCT category
FROM products;

Pagination
SELECT id, name
FROM products
ORDER BY id
LIMIT 10 OFFSET 20;

Large OFFSET values are inefficient. Prefer keyset pagination in
high‑load systems:
SELECT id, name
FROM products
WHERE id > 1000
ORDER BY id
LIMIT 10;

OFFSET works for small pages. For large datasets, keyset pagination is more efficient.

3. Filtering and Sorting
Filtering uses WHERE.
Filtering narrows data down to what actually matters.
Instead of loading everything and filtering in application code, push logic into the database — it is optimized for this.
SELECT name, price
FROM products
WHERE category = 'phones'
  AND price > 50000;

IN
Cleaner than multiple OR statements.
WHERE category IN ('phones', 'laptops')

BETWEEN
Readable range filter.
WHERE price BETWEEN 30000 AND 60000

LIKE / ILIKE
Pattern matching for text.
WHERE name LIKE 'iPhone%'

Postgres case-insensitive:
WHERE name ILIKE 'iphone%'

NULL Handling
NULL means “unknown”, not empty.
Incorrect:
WHERE description = NULL

Correct:
WHERE description IS NULL

ORDER BY
Sorting is expensive on large datasets — especially without indexes.
SELECT name, price
FROM products
ORDER BY price DESC, name ASC;

Sorting large datasets without indexes is expensive.

4. Aggregation and GROUP BY
Aggregation turns raw data into insight.
Instead of looking at thousands of rows, we compute metrics.

Aggregate functions:

COUNT
SUM
AVG
MIN
MAX

Example:
SELECT
  MAX(price) AS max_price,
  AVG(price) AS avg_price,
  COUNT(*) AS total_products
FROM products;

GROUP BY
Grouping splits rows into logical buckets before aggregation.
SELECT
  category,
  COUNT(*) AS product_count,
  AVG(price) AS avg_price
FROM products
GROUP BY category;

Rule:
Every non-aggregated column in SELECT must appear in GROUP BY.
HAVING
HAVING filters groups after aggregation — unlike WHERE.
Incorrect:
SELECT category, COUNT(*)
FROM products
WHERE COUNT(*) > 10
GROUP BY category;

Correct:
SELECT category, COUNT(*)
FROM products
GROUP BY category
HAVING COUNT(*) > 10;

5. JOINs
Real SQL begins with JOINs.

JOINs connect tables. This is where relational databases shine.
Instead of duplicating data, we combine normalized structures dynamically.
INNER JOIN
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id;

Only matching rows are returned.
LEFT JOIN
SELECT u.name, o.total
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

All users appear. Missing matches become NULL.
Find users without orders:
SELECT u.name
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE o.id IS NULL;

SELF JOIN
Used when a table references itself (hierarchies, managers, categories).
SELECT e.name AS employee,
       m.name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;

6. Data Modification (DML)
These queries change actual data.
Use carefully.

INSERT
INSERT INTO users (name, email)
VALUES ('Alex', 'alex@example.com');

Always list columns.
UPDATE
UPDATE products
SET price = 65000
WHERE id = 42;

Never run UPDATE without WHERE unless intentional.
DELETE
DELETE FROM users
WHERE last_login < '2020-01-01';

TRUNCATE
TRUNCATE TABLE logs;

Instantly removes all rows.

7. Schema Changes (DDL)
DDL modifies structure, not data.
Think of it as plumbing — not water.
CREATE TABLE
Defines structure and constraints.
CREATE TABLE orders (
  id BIGSERIAL PRIMARY KEY,
  user_id BIGINT NOT NULL,
  total NUMERIC(10,2) DEFAULT 0,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

ALTER TABLE
Adds or modifies columns safely.
ALTER TABLE orders
ADD COLUMN promo_code TEXT;

DROP TABLE
DROP TABLE orders;

<…

Polymorphic Decorators in React: HOCs on Steroids
Sun, 22 Feb 2026 00:00:00 GMT
Modern React applications rarely fail because of rendering complexity.
They fail because logic spreads across components in unpredictable ways.
Analytics. Routing. Permissions. Feature flags. Loading states. A/B
testing. Logging.
All of these are cross-cutting concerns. When they are implemented
directly inside JSX trees, components become deeply nested, hard to
maintain, and almost impossible to scale in large teams.
This article explores a production-grade architectural approach:
Polymorphic decorators implemented as strongly typed Higher-Order
Components (HOCs).
The objectives:

Separate logic from rendering
Preserve strict TypeScript safety
Enable reusable composition
Avoid JSX nesting hell
Scale across large React applications

This is not theory. Everything Here is practical and
production-oriented.

The Core Problem: JSX Nesting Explosion
Imagine a simple requirement.
A button must:
. Generate an href from /product/:id
. Inject route parameters
. Send analytics on click
. Stay polymorphic
. Remain fully type-safe
The typical JSX composition quickly becomes unreadable:
<TrackClick
  as={(props) => (
    <ResolveRoute
      as={PrimaryButton}
      template="/product/:id"
      params={{ id: "42" }}
      {...props}
    />
  )}
  elementKey="hero-btn"
  eventLabel="hero_click"
/>

Or using asChild-style composition:
<ResolveRoute template="/product/:id" params={{ id: "42" }} asChild>
  <TrackClick elementKey="hero-btn" eventLabel="hero_click" asChild>
    <PrimaryButton variant="solid">
      Buy Now
    </PrimaryButton>
  </TrackClick>
</ResolveRoute>

Even though it works, readability suffers.
Now compare with:
const SmartButton = withRouteResolver(
  withAnalyticsTracking(PrimaryButton)
)

<SmartButton
  template="/product/:id"
  params={{ id: "42" }}
  elementKey="hero-btn"
  eventLabel="hero_click"
  variant="solid"
/>

Flat. Predictable. Maintainable.

Turning Polymorphic Components into Decorators
Classic polymorphic component:
import {
  ElementType,
  createElement,
  MouseEventHandler,
} from "react"

type MergeProps<Base, Extra> =
  Omit<Base, keyof Extra> & Extra

type PropsOf<T extends ElementType> =
  React.ComponentPropsWithoutRef<T>

function WithSideEffect<
  TComponent extends ElementType<{ onClick?: MouseEventHandler }>
>({
  as,
  onClick,
  sideEffect,
  ...rest
}: MergeProps<
  PropsOf<TComponent>,
  {
    as: TComponent
    sideEffect?: MouseEventHandler
    onClick?: MouseEventHandler
  }
>) {
  const handleClick: MouseEventHandler = (event) => {
    onClick?.(event)
    sideEffect?.(event)
  }

  return createElement(as, {
    ...rest,
    onClick: handleClick,
  })
}

The transformation is simple:
Remove as from props and accept the component as a function parameter.
That converts polymorphic behavior into a reusable decorator.

Analytics Decorator (Production-Ready)
import { ComponentType, MouseEventHandler } from "react"

type AnalyticsProps = {
  elementKey: string
  eventLabel?: string
}

export function withAnalyticsTracking<
  TBase extends {
    onClick?: MouseEventHandler
    label?: string
  }
>(BaseComponent: ComponentType<TBase>) {
  return function AnalyticsWrapped(
    props: TBase & AnalyticsProps
  ) {
    const {
      elementKey,
      eventLabel,
      onClick,
      ...rest
    } = props

    const handleClick: MouseEventHandler = (event) => {
      console.log("Tracking event:", {
        elementKey,
        label: eventLabel ?? props.label ?? elementKey,
      })

      onClick?.(event)
    }

    return (
      <BaseComponent
        {...(rest as TBase)}
        onClick={handleClick}
      />
    )
  }
}

This decorator:

Preserves original props
Injects analytics
Keeps type inference intact
Works with any compatible component

Route Resolver Decorator
Centralized routing logic prevents chaos.
type RouteProps<T extends string> = {
  template: T
  params: Record<string, string>
}

export function withRouteResolver<
  TBase extends { href?: string }
>(BaseComponent: ComponentType<TBase>) {
  return function RouteWrapped<
    TTemplate extends string
  >(props: TBase & RouteProps<TTemplate>) {
    const { template, params, ...rest } = props

    const resolvedHref = Object.entries(params).reduce(
      (url, [key, value]) =>
        url.replace(`:${key}`, value),
      template
    )

    return (
      <BaseComponent
        {...(rest as TBase)}
        href={resolvedHref}
      />
    )
  }
}

This enables:

Template validation
Central formatting
Localization integration
Analytics chaining
Strict parameter control

Composing Decorators Safely
const EnhancedButton = withRouteResolver(
  withAnalyticsTracking(PrimaryButton)
)

Composition remains predictable because:

Each decorator isolates logic
Rendering remains untouched
TypeScript enforces compatibility

Building a Decoratable Card System
Base card:
type CardBaseProps = {
  className?: string
  style?: React.CSSProperties
  children?: React.ReactNode
}

export function CardBase({
  className,
  style,
  children,
}: CardBaseProps) {
  return (
    <div
      className={`rounded-lg p-4 shadow ${className ?? ""}`}
      style={style}
    >
      {children}
    </div>
  )
}

Loading decorator:
export function withLoadingState<
  T extends { children?: React.ReactNode }
>(BaseComponent: ComponentType<T>) {
  return function LoadingWrapped(
    props: T & { isLoading?: boolean }
  ) {
    const { isLoading, children, ...rest } = props

    return (
      <BaseComponent {...(rest as T)}>
        {isLoading ? <div>Loading...</div> : children}
      </BaseComponent>
    )
  }
}

Compose utility:
function compose(
  ...decorators: Array<
    (component: ComponentType<any>) => ComponentType<any>
  >
) {
  return (base: ComponentType<any>) =>
    decorators.reduceRight(
      (acc, decorator) => decorator(acc),
      base
    )
}

Final card:
export const Card = compose(
  withLoadingState
)(CardBase)

TypeScript Limitation: Generic Collisions
Decorators work perfectly --- until multiple introduce computed
generics.
Example:
return function WithRoute<TTemplate extends string>(
  props: ExtractProps<TBase> & LinkProps<TTemplate>
)

Stacking several generic-heavy decorators may:

Collapse inference
Override template literal types
Reduce safety guarantees

Practical rule:
Use only one computed-generic decorator per chain.

Where This Pattern Excels
Ideal for:

Analytics
Logging
Permission layers
Feature flags
Centralized routing
Business rule injection
UI library extensions

Less ideal for:

Highly dynamic render patterns (FACC is stronger there)

Architectural Impact
In large React + TypeScript applications:

Components are not always under your cont…

Nexus State: A Modern Atomic State Manager for JavaScript
Fri, 20 Feb 2026 00:00:00 GMT
State management remains one of the most complex areas in frontend engineering. Over the years, we’ve seen Redux, MobX, Zustand, and Jotai attempt to balance structure, performance, and developer experience.
Nexus State introduces an atomic model built around simplicity while still offering powerful capabilities such as:

Built-in DevTools
Time Travel debugging
Async state primitives
Persistence plugins
Middleware system
Multi-framework support

This article explores its architecture, core patterns, and practical usage.

Core Concept: Atoms
Atoms are minimal, isolated pieces of state.
import { atom, createStore } from '@nexus-state/core'

const sessionCounter = atom(0, 'sessionCounter')

const multipliedValue = atom((read) => read(sessionCounter) * 5, 'multipliedValue')

const mainStore = createStore()

mainStore.set(sessionCounter, 4)
console.log(mainStore.get(multipliedValue)) // 20

Derived atoms recompute automatically when dependencies change.

Store & Subscriptions
const unsubscribeHandler = mainStore.subscribe(sessionCounter, (value) => {
  console.log('Updated:', value)
})

mainStore.set(sessionCounter, 12)
unsubscribeHandler()

The store handles dependency tracking and batched updates.

React Example
import { useAtom } from '@nexus-state/react'

const progressAtom = atom(0, 'progress')
const percentAtom = atom((read) => read(progressAtom) * 10, 'percent')

export function ProgressPanel() {
  const [progress, updateProgress] = useAtom(progressAtom)
  const [percent] = useAtom(percentAtom)

  return (
    <div>
      <h2>Progress: {progress}</h2>
      <p>Percentage: {percent}%</p>
      <button onClick={() => updateProgress(prev => prev + 1)}>
        Increase
      </button>
    </div>
  )
}

Only components depending on changed atoms re-render.

Async Atoms
import { asyncAtom } from '@nexus-state/async'

const [accountAtom, fetchAccount] = asyncAtom({
  fetchFn: async () => {
    const response = await fetch('/api/account')
    return response.json()
  }
})

Async atoms encapsulate loading, error, and resolved states.

Persistence Example
import { persist, localStorageStorage } from '@nexus-state/persist'

persist(progressAtom, {
  key: 'app_progress',
  storage: localStorageStorage
})(mainStore)

State is automatically restored on reload.

Middleware Example
import { middleware } from '@nexus-state/middleware'

const auditMiddleware = middleware(progressAtom, {
  beforeSet: (_, next) => {
    console.log('Before:', next)
    return next
  },
  afterSet: (_, next) => {
    console.log('After:', next)
  }
})

Performance Characteristics
Nexus State optimizes:

Selective component updates
Batched state mutations
Lazy evaluation of derived atoms
Zero DevTools overhead in production builds

Comparison Snapshot
Compared to Redux:

Less boilerplate
No action types
Native async support
Smaller bundle

Compared to Zustand:

Built-in Time Travel
Multi-framework support

Compared to MobX:

Explicit dependency graph
Smaller runtime size

Compared to Jotai:

Store instance isolation
Built-in persistence

When Nexus State Makes Sense
Use it when:

You want atomic isolation
You need computed state out of the box
Debugging tools matter
You work across multiple frameworks
You build micro-frontends

Resources
Documentation: nexus-state.website.yandexcloud.net
Source Code: sourcecraft.dev/astashkin-a/nexus-state
Demo Applications: codesandbox.io/p/sandbox/nryqsj
Related articles

Understanding Big O Notation with JavaScript
Mastering Web Animations with Anime.js
Optimizing await fetch(): Why It Slows Down and How to Speed It Up

How to Fix Circular Imports in a React/TypeScript Application
Fri, 20 Feb 2026 00:00:00 GMT
Circular (recursive) imports are one of those issues that look small at first — until they start breaking runtime behavior, tests, hot reload, or production builds.
They rarely appear as a single obvious mistake. More often, they are a symptom of deeper architectural problems: unclear module boundaries, excessive barrel files, and uncontrolled cross-feature dependencies.
In this guide, we’ll walk through a practical approach to:

Detect circular imports
Understand why they happen
Refactor the structure safely
Prevent them from coming back

A Real Module Structure Example
modules/
  client/
    index.ts              # Public API of the module
    redux/
      actions.ts
      reducer.ts
      types.ts
      index.ts
    ui/
      ClientComponent.tsx
    service.ts
    types.ts

This is a common structure:

redux/ contains state logic
ui/ contains components
service.ts contains business logic
index.ts exposes the public API

Nothing looks wrong at first glance. But this structure can easily create circular dependencies if not handled carefully.

Barrel Files: The Hidden Source of Cycles
Barrel files (index.ts) are useful — but dangerous when overused.
The Common Mistake
modules/index.ts
export * from "./client";
export * from "./order";

This expands your dependency graph and increases the risk of circular imports.
Instead of importing specific modules, developers start importing from @modules, which forces evaluation of everything.

Correct vs Incorrect Imports
Correct
import { clientActions } from "@modules/client";

Incorrect
import { clientActions } from "@modules";

The second option hides the dependency path and makes cycles easier to create accidentally.

Internal Module Imports: Always Use Relative Paths
Incorrect
import { clientActions } from ".";

Correct
import { clientActions } from "./redux/actions";
import { clientTypes } from "./types";

Always use direct relative imports inside the same module.

High Cohesion: Export Only What Is Public
Incorrect
export { clientActions, clientReducer } from "./redux";
export { ClientComponent } from "./ui";
export { clientTypes } from "./types";

This exposes internal implementation details.
Correct
export { ClientService } from "./service";
export type { Client } from "./types";

Only export what external modules truly need.

Understanding Dependency Graphs
utils/                   ← leaf node
 ├─ index.ts
 ├─ format.ts
 └─ validate.ts

modules/
 ├─ client/              ← depends on utils
 │   └─ index.ts
 └─ order/               ← depends on client and utils
     └─ index.ts

Safe dependency direction:
utils → client → order

No back-references. No cycles.

Example of a Circular Dependency
Before
client/service.ts
import { orderService } from "@modules/order";

order/service.ts
import { clientService } from "@modules/client";

Dependency graph:
client → order → client

How to Fix It
Option 1: Extract Shared Logic
@modules/shared/types.ts
export type { Client, Order };

Now both modules depend on shared:
client → shared
order  → shared

Option 2: Split Large Modules
Break a feature into:

client-core (business logic)
client-ui (UI components)

Then:
import { clientCoreService } from "@modules/client-core";

Smaller modules reduce coupling.

Detecting Circular Imports
Recommended tools:

madge
dependency-cruiser
eslint-plugin-import

Final Thoughts
Circular imports are not just annoying errors — they are architectural feedback.
A clean dependency graph:

Improves maintainability
Makes testing easier
Reduces unpredictable runtime behavior
Keeps teams aligned

The real goal isn’t just “no circular imports”.
It’s a clean, predictable module architecture.
Related articles

Validate ENV Variables in TypeScript with Zod
Resolving Missing flat, flatMap, and Flatten on any[] in TypeScript
Declaring and Managing Global Variables in TypeScript

Friday Links #34: Modern JavaScript Picks & Highlights
Fri, 13 Feb 2026 00:00:00 GMT

Friday Links #33 brings together a fresh set of modern JavaScript highlights — from new tools and framework updates to useful libraries and developer resources. This edition focuses on practical discoveries you can try immediately, plus a few notable releases that may shape upcoming workflows. If you like staying current without scrolling through endless feeds, this digest is for you.
Pinterest processes more searches than ChatGPT

According to Pinterest CEO Bill Ready, who made the comparison while discussing the company’s latest quarterly results. He positioned Pinterest as a major standalone search and discovery entry point, especially for commercial intent.
According to third-party estimates, ChatGPT handles around 75B searches per month, while Pinterest sees roughly 80B, generating about 1.7B monthly clicks. Ready noted that more than half of Pinterest searches are commercial in nature, versus roughly 2% for ChatGPT (by his estimate).
The quarter itself came in slightly below expectations:
— revenue: $1.32B vs $1.33B expected
— EPS: $0.67 vs $0.69 expected
— Q1 2026 outlook: $951–971M vs $980M expected
Pinterest attributed the softness to reduced advertiser budgets (especially in Europe) and new tariffs affecting home and furniture categories. Despite this, user growth beat forecasts, reaching 619M monthly active users (+12% YoY). Shares dropped about 20% in after-hours trading.
The company says it’s doubling down on visual search, recommendations, personalization, and tighter e-commerce integrations (including Amazon partnerships) to capture buying intent earlier in the discovery journey.
📜 Articles & Tutorials
Gemini 3 Deep Think: Advancing science, research and engineering
Email RFC Protocol Support - Complete Standards & Specifications Guide
CSS in 2026: The new features reshaping frontend development
Greedy Rectangle Merging: Turning Binary Grids into Simple Geometry – JavaScript example
You probably don’t need useCallback here
agent-browser -  Browser automation CLI for AI agents
syntux -  Generative UIs for the web.
JavaScript Frameworks - Heading into 2026
The Browser Hates Surprises
A new meta tag for respecting text scaling on mobile
Measuring SVG rendering time
The logo soup problem (and how to solve it)
Debugging with AI: Can It Replace an Experienced Developer?
⚒️ Tools
npmx — A Faster, More Informative npm Registry Browser — A new high-performance interface for exploring packages from the official npm registry. Search is quick and accurate, and package pages (for example, axios) surface richer metadata and insights at a glance. It’s not meant to replace the official registry, but it makes the default npmjs.com browsing experience feel dated. The built-in package comparison feature is especially useful.
Rari – Rust-powered React framework
almostnode — Run a Node.js Environment in the Browser — An experimental project that brings a Node.js (v20) runtime directly into the browser, including basic npm package support. It’s still early and not production-ready, but the concept is intriguing and the live demo on the homepage shows promising potential.
Everything Claude Code - The complete collection of Claude Code configs from an Anthropic hackathon winner.
Atlas - Network Infrastructure Visualizer -  Open-source tool for network discovery, visualization, and monitoring. Built with Go, FastAPI, and React, supports Docker host scanning.
Awilix -  Extremely powerful Inversion of Control (IoC) container for Node.JS
Aedes -  Barebone MQTT broker that can run on any stream server, the node way
broz -  A simple, frameless browser for screenshots
Shaka Player -  JavaScript player library / DASH & HLS client / MSE-EME player
SVG Studio — A Browser-Based SVG Editing Tool
Baseline Status for Video - An Easy Way to Show Baseline Support in Videos. A small, practical utility for quickly displaying Baseline support status in video content. It helps creators visually communicate browser feature support and compatibility without building custom overlays or graphics.
Promptefy - Prompt-Driven Video Generator with Gemini
📚 Libs
Fireshare -  Self host your media and share with unique links
Fleetbase -  Modular logistics and supply chain operating system (LSOS)
Peek -  Light Weight "Headroom Style" scroll intent library that hides the site header on scroll down and shows on scroll up
ChatKit — A Framework for Building AI Chat Experiences — A developer framework for adding polished, AI-powered chat interfaces to applications with minimal setup. It provides ready-made building blocks for conversational features and orchestration, helping teams ship advanced chat functionality quickly without rebuilding common patterns from scratch.
image-js -  Image processing and manipulation in JavaScript
⌚ Releases
TypeScript 6.0 has entered beta. This release isn’t about flashy new features — it focuses on simplifying and cleaning up tsconfig settings. Think of it as a transitional version designed to smooth the path toward the future Go-based “native” TypeScript 7 compiler.

Improved type inference for functions without this: TypeScript now treats functions that don’t actually use this as less context-sensitive, improving inference in more cases.
Support for subpath imports starting with #/: You can now use imports like import x from "#/module" in supported environments, simplifying internal package aliasing.
New --stableTypeOrdering flag:…

Choosing the Right State Strategy in React
Mon, 19 Jan 2026 00:00:00 GMT
State management in React is both a superpower and a recurring source of complexity. As applications grow, state stops being “just some useState hooks” and turns into a mix of:

local UI state (inputs, dialogs, tabs),
shared UI state (layout, theme, auth),
server state (queries, caches, background refresh),
domain state (entities, workflows, lifecycles),
and performance constraints (minimizing wasted renders).

There is no single perfect tool that solves every case. Instead, each approach makes different trade‑offs around subscriptions, granularity, debuggability, and team workflow.
This article walks through several state management strategies that React developers actually use in production today. Instead of yet another todo list, we will use more realistic examples: a market dashboard, trade lifecycle, user preferences, and reactive UIs.
We will look at:

When local state is enough.
When Context helps, and when it hurts.
How Redux Toolkit enables event logs and workflows.
How Zustand provides simple global stores with selectors.
How Jotai models state as small atoms.
How MobX and Valtio embrace reactive, mutable models.
How to decide which tool to use for which problem.

The Two Fundamental Problems of React State
Every state management discussion eventually runs into two opposite pain points:

Data changes, but the UI does not update.

This is a data flow problem: React does not know what changed, or the change happened outside its subscription graph.

UI updates even though the relevant data did not change.

This is a subscriptions problem: components subscribed to too much state or subscribe in a way that always returns new values.

Every library in the React ecosystem is, in one way or another, an attempt to make these two problems manageable.

Approach 1: Local State with useState and useReducer
The simplest and often the most reliable approach is to keep state local to the component that needs it.
Local state is a great fit for:

widget‑level interactions (modals, dropdowns, accordions);
form inputs and validation inside a single screen;
transient data that does not need to be shared.

Consider a small sparkline chart that visualizes the last 50 price ticks of a stock. This is pure UI state; nothing else needs to know about it.
import { useReducer, useEffect } from "react";

interface Candle {
  t: number;
  p: number;
}

type Action = { type: "tick"; price: number };

function chartReducer(state: Candle[], action: Action): Candle[] {
  switch (action.type) {
    case "tick":
      return [...state.slice(-49), { t: Date.now(), p: action.price }];
    default:
      return state;
  }
}

export function Sparkline({ feed }: { feed: () => number }) {
  const [candles, dispatch] = useReducer(chartReducer, []);

  useEffect(() => {
    const id = setInterval(() => {
      dispatch({ type: "tick", price: feed() });
    }, 500);
    return () => clearInterval(id);
  }, [feed]);

  return (
    <pre style={{ fontSize: 12 }}>
      {JSON.stringify(candles.slice(-5), null, 2)}
    </pre>
  );
}

React does not need a state library to manage this. The logic is:

encapsulated,
easy to test,
and easy to throw away if the component is refactored.

When local state is ideal

The data does not need to be shared across distant components.
The component can own the entire lifecycle of that state.
Performance characteristics are simple and local.

When local state becomes a problem

Many siblings need the same state and start lifting it up repeatedly.
Different screens must coordinate around shared entities or workflows.
Debugging requires inspecting the evolution of state over time.

As soon as state needs to be shared or observed by many components, we usually escalate beyond pure useState/useReducer.

Approach 2: React Context for Shared UI State
React Context solves a specific problem: prop drilling. Instead of passing props through multiple levels, a Provider at the top of a subtree can expose state and APIs to any descendant.
Context is a great fit for:

theme,
locale,
the current authenticated user,
feature flags,
routing metadata,
“ambient” UI state that rarely changes.

However, Context has a sharp edge: when the Provider value reference changes, all consumers re‑render. Memoization is critical.
Example: Shared Watchlist with Context
Imagine a market dashboard where multiple components show and modify a user’s stock watchlist.
import {
  createContext,
  useContext,
  useCallback,
  useMemo,
  useState,
  ReactNode,
} from "react";

interface WatchlistContextShape {
  symbols: string[];
  add: (symbol: string) => void;
  remove: (symbol: string) => void;
}

const WatchlistContext = createContext<WatchlistContextShape | null>(null);

export function WatchlistProvider({ children }: { children: ReactNode }) {
  const [symbols, setSymbols] = useState<string[]>(["AAPL", "MSFT"]);

  const add = useCallback(
    (sym: string) =>
      setSymbols(prev => (prev.includes(sym) ? prev : [...prev, sym])),
    [],
  );

  const remove = useCallback(
    (sym: string) => setSymbols(prev => prev.filter(s => s !== sym)),
    [],
  );

  const value = useMemo(
    () => ({ symbols, add, remove }),
    [symbols, add, remove],
  );

  return (
    <WatchlistContext.Provider value={value}>
      {children}
    </WatchlistContext.Provider>
  );
}

export function useWatchlist() {
  const ctx = useContext(WatchlistContext);
  if (!ctx) throw new Error("WatchlistProvider is missing");
  return ctx;
}

Any descendant can call useWatchlist() to read or update the watchlist. For state that changes rarely, this works very well.
Pros of Context

No external dependencies.
Perfect for ambient state (theme, locale, auth, feature flags).
Natural lifetime scoping: unmounting a Provider resets state.

Cons of Context

All consumers re‑render whenever value changes (unless you split Providers).
No built‑in selectors or fine‑grained subscriptions.
No action log, no time travel, and limited debugging visibility.

Context is powerful but should not be the default for high‑frequency or large shared state. For those cases, other tools are better suited.

Approach 3: Redux Toolkit for Workflow‑Oriented State
Redux was designed around a very specific philosophy:

State follows actions. Every change is an event in a log.

In its modern form (Redux Toolkit + React‑Redux), Redux is best used when:

there are clear business events with semantic meaning,
debugging requires inspecting how and when state changed,
multiple teams need a shared, predictable architecture,
reproducibility and time‑travel debugging are important.

Think of a trade order lifecycle in a trading system:

draft → submit…

How to Add Months to a Date in JavaScript
Tue, 13 Jan 2026 00:00:00 GMT
Working with dates in JavaScript looks simple until you need real calendar arithmetic. Adding months is a subtle operation because month lengths vary, timezones affect results, and end-of-month behavior is not always obvious.
Before diving in, if you also work with timezones, you may benefit from this related article:
Previous related guide (timezone handling):

Timezone-Safe Development with date-fns and date-fns-tz

Why Adding Months Is Not Just Adding 30 Days
Some developers assume that one month equals 30 days:
const date = new Date("2024-01-31");
const result = new Date(date.getTime() + 30 * 24 * 60 * 60 * 1000);
console.log(result.toISOString());

This does not guarantee an accurate month shift. For January 31, this often produces a date in early March instead of the end of February.
Adding Months Using Native JavaScript
The native approach uses setMonth:
const date = new Date("2024-01-31");
const result = new Date(date);
result.setMonth(result.getMonth() + 1);
console.log(result.toISOString());

However, this may result in an overflow. January 31 plus one month produces a date in March because February has fewer days.
Fixing End-of-Month Behavior
If your domain needs end-of-month semantics (billing, subscriptions), you can enforce it:
function addMonthsEndSafe(date, months) {
  const d = new Date(date);
  const day = d.getDate();
  d.setMonth(d.getMonth() + months);
  if (d.getDate() < day) {
    d.setDate(0);
  }
  return d;
}

console.log(addMonthsEndSafe(new Date("2024-01-31"), 1));

This correctly yields 2024-02-29 when applicable.
Adding Months Using date-fns
The date-fns library provides addMonths for clean edge-case handling:
import { addMonths } from "date-fns";

console.log(addMonths(new Date("2024-01-31"), 1));
// → 2024-02-29

Subtracting months:
import { subMonths } from "date-fns";

console.log(subMonths(new Date("2024-05-20"), 3));
// → 2024-02-20

Handling Timezones
If your application involves user timezones, use date-fns-tz for formatting:
import { addMonths } from "date-fns";
import { utcToZonedTime, format } from "date-fns-tz";

const utc = addMonths(new Date("2026-01-12T15:00:00.000Z"), 1);
const zone = "America/New_York";
const local = utcToZonedTime(utc, zone);

console.log(format(local, "yyyy-MM-dd HH:mmXXX"));

This helps avoid DST-related formatting issues.
Comparison Summary

Method
End-of-month safe
DST aware
Recommended

+30 days
No
No
Never

setMonth
Partial
Yes
Good

Custom safe function
Yes
Yes
Billing scenarios

date-fns addMonths
Yes
Yes
Most applications

Choosing the Right Strategy

Use Case
Approach

Billing
custom EOM logic

UI calendars
date-fns addMonths

Internal UTC timestamps
native setMonth

Finance
custom logic + UTC

Summary
Adding months is not just arithmetic. Calendar correctness requires accounting for month length differences, handling overflows safely, respecting user timezones when needed, and choosing the right approach for the domain.
date-fns simplifies most real-world scenarios, while custom logic may be necessary for financial systems and subscription billing.
Related articles

Mastering Array Flattening in JavaScript
Mastering Advanced Binary Operations in JavaScript
Mastering Early and Late Binding in TypeScript & JavaScript

How to Convert a String to a Date in JavaScript
Tue, 13 Jan 2026 00:00:00 GMT
Parsing dates from strings in JavaScript can be tricky due to locale differences, ambiguous formats, and browser inconsistencies. For example:

"01/02/2026" could mean January 2nd or February 1st depending on locale,
"2026-01-12" parses reliably but may be interpreted in local timezone,
"2026-01-12 10:00" is parsed differently by different engines,
new Date(string) handles formats inconsistently.

To avoid these pitfalls, developers should take control over parsing rules rather than relying on automatic behavior.
Before moving on, if timezones are also part of your workflow, this related article might be useful:
Related guide (timezone handling):
Timezone-Safe Development with date-fns and date-fns-tz
Built‑in Parsing: Pitfalls
Avoid relying on native parsing for non-ISO strings:
new Date("2026-01-12 10:00"); // ambiguous, local parsing rules
new Date("01/12/2026");      // locale-dependent

Better:
new Date("2026-01-12T10:00:00Z"); // explicit UTC

Or using a parsing library like date-fns to enforce expected formats.
Using date-fns for Safe Parsing
date-fns enables explicit parsing patterns:
import { parse, isValid } from "date-fns";

const input = "12.01.2026";
const pattern = "dd.MM.yyyy";
const reference = new Date();

const result = parse(input, pattern, reference);

if (isValid(result)) {
  console.log(result.toISOString());
}

This prevents locale ambiguity and ensures reproducibility.
React Form Parsing Demo (Practical Example)
For more advanced form handling patterns, see

React Form Primitives:
The following example demonstrates how to parse a date string entered by a user inside a React controlled form, validate it, and show a formatted output.
import React, { useState } from "react";
import { parse, isValid, format } from "date-fns";

type SupportedFormat = "yyyy-MM-dd" | "dd.MM.yyyy" | "MM/dd/yyyy";

const formatExamples: Record<SupportedFormat, string> = {
  "yyyy-MM-dd": "2026-01-12",
  "dd.MM.yyyy": "12.01.2026",
  "MM/dd/yyyy": "01/12/2026",
};

export function DateStringForm() {
  const [raw, setRaw] = useState("");
  const [pattern, setPattern] = useState<SupportedFormat>("yyyy-MM-dd");
  const [parsed, setParsed] = useState<Date | null>(null);
  const [error, setError] = useState<string | null>(null);

  const handleSubmit: React.FormEventHandler = (e) => {
    e.preventDefault();
    const trimmed = raw.trim();
    if (!trimmed) {
      setParsed(null);
      setError("Please enter a date string.");
      return;
    }
    const reference = new Date();
    const result = parse(trimmed, pattern, reference);
    if (!isValid(result)) {
      setParsed(null);
      setError(
        \`Cannot parse "\${trimmed}" as \${pattern}. Example: \${formatExamples[pattern]}\`
      );
      return;
    }
    setParsed(result);
    setError(null);
  };

  return (
    <div style={{ maxWidth: 480, margin: "2rem auto", fontFamily: "system-ui" }}>
      <h2>String to Date parsing demo</h2>
      <p style={{ marginBottom: "1rem" }}>
        This example shows how to convert a date string into a JavaScript{" "}
        <code>Date</code> object using controlled form inputs and{" "}
        <code>date-fns</code>. For more advanced form patterns, see{" "}
        <a
          href="https://jsdev.space/react-form-primitives/"
          target="_blank"
          rel="noreferrer"
        >
          React Form Primitives
        </a>
        .
      </p>

      <form onSubmit={handleSubmit} style={{ display: "grid", gap: "0.75rem" }}>
        <label style={{ display: "grid", gap: "0.25rem" }}>
          <span>Date string</span>
          <input
            type="text"
            value={raw}
            onChange={(e) => setRaw(e.target.value)}
            placeholder={formatExamples[pattern]}
            style={{
              padding: "0.5rem 0.75rem",
              borderRadius: 6,
              border: "1px solid #ccc",
              fontFamily: "inherit",
            }}
          />
        </label>

        <label style={{ display: "grid", gap: "0.25rem" }}>
          <span>Expected format</span>
          <select
            value={pattern}
            onChange={(e) => setPattern(e.target.value as SupportedFormat)}
            style={{
              padding: "0.5rem 0.75rem",
              borderRadius: 6,
              border: "1px solid #ccc",
              fontFamily: "inherit",
            }}
          >
            <option value="yyyy-MM-dd">yyyy-MM-dd (2026-01-12)</option>
            <option value="dd.MM.yyyy">dd.MM.yyyy (12.01.2026)</option>
            <option value="MM/dd/yyyy">MM/dd/yyyy (01/12/2026)</option>
          </select>
        </label>

        <button
          type="submit"
          style={{
            marginTop: "0.5rem",
            padding: "0.5rem 0.75rem",
            borderRadius: 6,
            border: "none",
            background: "#111827",
            color: "white",
            cursor: "pointer",
            fontFamily: "inherit",
          }}
        >
          Parse date
        </button>
      </form>

      <div style={{ marginTop: "1rem", fontSize: 14 }}>
        {error && (
          <p style={{ color: "#b91c1c", margin: 0 }}>
            {error}
          </p>
        )}

        {parsed && !error && (
          <div
            style={{
              marginTop: "0.75rem",
              padding: "0.75rem",
              borderRadius: 6,
              background: "#f9fafb",
              border: "1px solid #e5e7eb",
            }}
          >
            <div>
              <strong>Parsed Date object:</strong>
            </div>
            <div>
              <code>{parsed.toString()}</code>
            </div>
            <div style={{ marginTop: "0.5rem" }}>
              <strong>ISO (UTC):</strong>{" "}
              <code>{parsed.toISOString()}</code>
            </div>
            <div style={{ marginTop: "0.25rem" }}>
              <strong>Formatted (yyyy-MM-dd):</strong>{" "}
              <code>{format(parsed, "yyyy-MM-dd")}</code>
            </div>
          </div>
        )}
      </div>
    </div>
  );
}

Summary
Key takeaways:

Native Date parsing is inconsistent for non-ISO formats,
Using explicit parsing rules prevents locale ambiguity,
React integration is straightforward with controlled inputs,
date-fns improves reliability and validation.

This updated MDX now includes both conceptual guidance and a practical UI demo.
Related articles

Practical Month Arithmetic and Calendar Logic in JavaScript
Mastering Array Flattening in JavaScript
Mastering Advanced Binary Operations in JavaScript

How to Handle Timezones with date-fns and date-fns-tz
Tue, 13 Jan 2026 00:00:00 GMT
Why Timezones Matter
Working with dates is deceptively complex. Different regions have local timezone offsets, daylight saving rules (DST), and historical changes.
Almost every backend stores timestamps in UTC, while frontends must show them in local time. Mistakes lead to wrong displayed times, off-by-one-day bugs, incorrect scheduling, and misaligned business rules.
Instead of building logic manually, this article uses date-fns and date-fns-tz, two lightweight libraries designed for timezone-safe manipulation.
Installation
npm install date-fns date-fns-tz

Basic Concepts

UTC is the universal storage format

Example: "2024-10-11T10:30:00.000Z"

Local time is a presentation layer

UI must render times in the user’s timezone.

date-fns-tz gives explicit control

Prevents “magic conversion bugs”.

Parsing a UTC Timestamp into Local Time
import { format } from "date-fns";
import { utcToZonedTime } from "date-fns-tz";

const iso = "2026-01-12T15:00:00.000Z";
const timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;

const date = utcToZonedTime(iso, timezone);
console.log(format(date, "yyyy-MM-dd HH:mm:ssXXX"));

Converting Local Time to UTC
import { zonedTimeToUtc } from "date-fns-tz";

const userInput = "2026-01-12 18:30:00";
const timezone = "Europe/Berlin";

const utc = zonedTimeToUtc(userInput, timezone);
console.log(utc.toISOString());

Formatting With Timezones
import { format, formatISO } from "date-fns";
import { utcToZonedTime } from "date-fns-tz";

const iso = "2026-07-01T12:00:00Z";
const zone = "America/New_York";

const local = utcToZonedTime(iso, zone);

console.log(format(local, "PPpp"));
console.log(formatISO(local));

Handling Daylight Saving Time (DST)
const winter = "2026-01-10T12:00:00Z";
const summer = "2026-07-10T12:00:00Z";
const zone = "America/New_York";

console.log(format(utcToZonedTime(winter, zone), "HH:mmXXX"));
console.log(format(utcToZonedTime(summer, zone), "HH:mmXXX"));

Comparing Dates Across Timezones
import { getTime } from "date-fns";

const same = getTime(new Date(a)) === getTime(new Date(b));

Scheduling Use Case
import { zonedTimeToUtc } from "date-fns-tz";

function schedule(userLocalDateTime, userZone) {
  const utc = zonedTimeToUtc(userLocalDateTime, userZone);
  return utc.toISOString();
}

For rendering:
import { utcToZonedTime } from "date-fns-tz";

function present(utcIso, userZone) {
  return utcToZonedTime(utcIso, userZone);
}

Browser Timezones
const zone = Intl.DateTimeFormat().resolvedOptions().timeZone;

Common Pitfalls
Wrong:
new Date("2026-01-12 10:00");

Correct:
new Date("2026-01-12T10:00:00Z");

or convert using zonedTimeToUtc.
When to Use Which Function

Task
Function

UTC → local
utcToZonedTime(utc, zone)

Local → UTC
zonedTimeToUtc(local, zone)

Format
format(date, pattern)

Store
date.toISOString()

Summary
Working with timezones is not simple subtraction. It requires:

consistent UTC storage,
correct local presentation,
DST-aware conversions,
predictable comparisons.

date-fns and date-fns-tz help avoid most timezone-related pitfalls while staying lightweight.
Related articles

Practical Month Arithmetic and Calendar Logic in JavaScript
Mastering Array Flattening in JavaScript
Mastering Advanced Binary Operations in JavaScript

Howto Build Reactive Declarative UI in Vanilla JavaScript
Mon, 12 Jan 2026 00:00:00 GMT
Modern UI frameworks offer abstraction layers that make user interfaces declarative and reactive. However, the web platform itself exposes primitives that can be composed to achieve similar patterns without introducing a dedicated UI library. This article demonstrates an experimental approach for creating a reactive, declarative UI flow using only vanilla JavaScript, Web APIs, and Proxy-based state tracking.
The purpose of the experiment is to examine how far native capabilities can be pushed without framework-level abstractions and to illustrate architectural benefits of declarative behavior in UI code: improved clarity, maintainability, and reduced coupling.

The Target Behavior
The experiment focuses on a practical business scenario:

Display a modal dialog that performs periodic polling of an API endpoint. The dialog should remain open until a specific condition is met, then resolve or reject accordingly.

The modal dynamically:

mounts itself into the DOM
starts and manages a polling process
exposes reactive internal state
updates based on the polling result
closes automatically when finished
provides optional developer controls

The primary requirement is that consumer code defines what should happen, not how to wire it.

Declarative Usage Example
Example invocation:
uiModalEngine.showPollingDialog({
  endpoint: `${getServiceBaseUrl()}/process/wait_for/confirmation`,

  requestPayload: () => ({
    taskId: currentTask.id,
    mode: "rapid",
    includeAudit: true,
  }),

  requestOptions: {
    method: "POST",
    headers: { "Content-Type": "application/json" },
  },

  shouldContinue: (response) => response.ok && response.pending === true,

  intervalMs: 1000,

  buildContent: (mountNode) => {
    const contentBlock = uiModalEngine.createContentBlock({
      title: "Waiting for confirmation...",
      description: "This dialog will close automatically once the operation completes.",
    })
    mountNode.appendChild(contentBlock)
  },

  onResolved: ({ dialogNode, response }) => {
    metrics.track("operation_confirmed")
    dialogNode.remove()
  },

  onRejected: ({ dialogNode, error }) => {
    logger.error("operation_polling_failed", error)
    dialogNode.remove()
  },

  devToolsEnabled: false,
})

Declarative Takeaways

Concern
Ownership

UI behavior
Declarative configuration

UI rendering
Modal orchestrator

DOM structure
DOM utility layer

polling logic
polling helper

reactive state
Proxy-based tracker

No framework is involved, yet responsibilities remain clearly segmented.

Core Building Block: DOM Utility Layer
To keep high-level code focused on behavior, DOM creation is delegated to a lightweight utility:
class DomToolkit {
  constructor(doc) {
    this.doc = doc
  }

  static getInstance(doc) {
    if (!DomToolkit.instance) DomToolkit.instance = new DomToolkit(doc)
    return DomToolkit.instance
  }

  createElement({ tag, classes, id, attrs = {}, styles = {}, html }) {
    const el = this.doc.createElement(tag)

    if (id) el.id = id

    if (typeof classes === "string") el.classList.add(classes)
    if (Array.isArray(classes)) classes.forEach(c => el.classList.add(c))

    Object.entries(attrs).forEach(([k, v]) => el.setAttribute(k, v))
    Object.entries(styles).forEach(([k, v]) => el.style[k] = v)

    if (html != null) el.innerHTML = html

    return el
  }
}

const domToolkit = DomToolkit.getInstance(document)

This removes boilerplate from business logic and centralizes standard element configuration.

Reactive State via Proxy
Next, the experiment introduces deep reactive state using the native Proxy object. This allows mutations at arbitrary depth to be observed without requiring explicit setters.
class DeepStateProxy {
  constructor(target, { onSet, onDelete } = {}) {
    this.onSet = onSet
    this.onDelete = onDelete
    return this.wrap(target, [])
  }

  wrap(node, path) {
    if (!node || typeof node !== "object") return node

    const handler = {
      set: (target, key, value) => {
        const fullPath = [...path, key]
        target[key] = this.wrap(value, fullPath)
        this.onSet?.(value, fullPath)
        return true
      },
      deleteProperty: (target, key) => {
        if (!(key in target)) return false
        const fullPath = [...path, key]
        delete target[key]
        this.onDelete?.(fullPath)
        return true
      },
    }

    Object.keys(node).forEach(k => {
      node[k] = this.wrap(node[k], [...path, k])
    })

    return new Proxy(node, handler)
  }
}

Usage example:
const state = new DeepStateProxy({
  attempts: 0,
  lastResponse: null,
}, {
  onSet: (value, path) => console.debug("state changed:", path.join("."), value),
})

This approach:
enables deep mutation tracking

does not require libraries

keeps state as plain objects

keeps consumer code minimal

Polling Logic as a Reusable Abstraction
To isolate asynchronous logic:
async function runPolling({ task, shouldStop, intervalMs }) {
  while (true) {
    const result = await task()
    if (shouldStop(result)) return result
    await new Promise(res => setTimeout(res, intervalMs))
  }
}

Isolating polling enables:

testability (polling logic has no DOM dependencies)
readability (consumer describes behavior declaratively)
reusability (polling can be embedded into other flows)

Modal Orchestrator
The orchestrator integrates DOM utilities, polling, and reactive state into a coherent unit:
ModalOrchestrator.prototype.showPollingDialog = function (cfg) {
  const {
    endpoint, requestPayload, requestOptions,
    shouldContinue, intervalMs,
    buildContent, onResolved, onRejected,
    devToolsEnabled = false,
  } = cfg

  const dialogNode = this.createDialogShell({ buildContent })
  document.body.appendChild(dialogNode)

  const state = new DeepStateProxy({
    attempts: 0,
    polling: true,
    aborted: false,
    lastResponse: { ok: false },
  }, {
    onSet: (value, path) => {
      if (devToolsEnabled) console.debug("state:", path.join("."), value)
    },
    onDelete: () => { throw new Error("state mutation violation") },
  })

  state.polling = true

  runPolling({
    task: async () => {
      const payload = requestPayload()
      const res = await fetch(endpoint, { ...requestOptions, body: JSON.stringify(payload) })
        .then(r => r.json())
        .catch(err => ({ ok: false, error: err.message, errored: true }))

      if (!shouldContinue(res) && !res.errored) state.polling = false
      else state.attempts++

      state.lastResponse = res
      return res
    },
    shouldStop: () => !state.polling,
    intervalMs,
  })
    .then(res => onResolved?.({ dialogNode, response: res }))
    .catch(err => onRejected?.({ dialogNode, error: err }))
}

Note the absence of framework-specific concepts such as:

components
hooks
virtual DOM
stores

Yet the intent remains clear and maintainable.

Observations & Takeaways
Key architectural observations include:

Declarative descriptions scale better than imperative wiring

The consumer code reads…

Meet Ripple: The Elegant TypeScript UI Framework
Sun, 11 Jan 2026 00:00:00 GMT
Ripple is a compiler-first TypeScript UI framework for building fast, clean, reactive applications with minimal boilerplate and optimal performance.
Why the Frontend World Needs Ripple in 2026
Front-end development has reached an unusual point in its history:

writing code is easy — maintaining it is hard.
AI accelerated code output, but did not solve code quality, consistency, or review overhead.
Traditional frameworks are powerful but often come with:

verbose state handling
over-rendering components
heavy abstraction layers
confusing refs/signals/hooks
bloated bundle sizes

Ripple was designed for this moment. It prioritizes simplicity, clarity, and reactivity.

“Code should read like it does.”

What is Ripple?
Ripple is a compiler-first, fine-grained reactive UI framework with:

TypeScript-first components
reactive variables with track() + @
no Virtual DOM
automatic dependency tracking
inline control flow
scoped CSS

Ripple’s Design Goals
1. Compiler Before Runtime
The compiler performs:

DOM dependency analysis
dead CSS removal
scoped styling
code transformation

2. Reactive by Default
let count = track(0);
<button onClick={() => @count++}>{@count}</button>

No useState, ref(), .value, $:, or signals.
3. Low Cognitive Load
Less to memorize. Business logic remains obvious.
4. Granular DOM Updates
Only updated nodes mutate — not whole components.

Getting Started
Initialize a new project:
npx create-ripple-app ripple-todo-app

Move inside:
cd ripple-todo-app

If integrating manually:
npm install ripple ripple-compiler ripple-dom

Scripts
npm run dev
npm run build
npm run preview

Folder Structure
my-ripple-app/
├─ src/
│  ├─ App.ripple
│  ├─ index.tsx
│  └─ components/
├─ public/
├─ ripple.config.ts
├─ tsconfig.json
├─ package.json

Verify Setup
component App() {
  <h1>{"Hello Ripple"}</h1>
}

If it renders, you're ready.

Ripple in 2 Minutes: Core Syntax
Reactive Variables
let count = track(0);

Read + Write
<button onClick={() => @count++}>{@count}</button>

Reactive Collections
const todos = #[];
const user = #{ name: "Tom" };

Components
component Greeting({ name }) {
  <h1>{"Hello "}{name}</h1>;
}

Inline Control Flow
for (const item of items) {
  <Item data={item}/>
}

Productivity Advantages
Ripple reduces maintenance cost by:

fewer primitives
direct reactivity
compiler constraints
minimal boilerplate
tiny runtime

Building a Real Demo: Todo List
We’ll demonstrate Ripple’s power with a fully reactive Todo List.
TodoInput Component
import { track } from "ripple";

component TodoInput({ onAdd }) {
  let text = track("");

  function submit() {
    const v = @text.trim();
    if (v) {
      onAdd(v);
      @text = "";
    }
  }

  <div class="input">
    <input
      placeholder="Add a task..."
      value={@text}
      onInput={(e) => @text = e.target.value}
      onKeyDown={(e) => { if (e.key === "Enter") submit(); }}
    />
    <button onClick={submit}>{"Add"}</button>
  </div>
}

TodoItem Component
component TodoItem({ todo, onToggle, onDelete }) {
  <li>
    <input type="checkbox" checked={todo.completed} onChange={onToggle} />
    <span class={todo.completed ? "done" : ""}>{todo.text}</span>
    <button onClick={onDelete}>{"×"}</button>
  </li>
}

App Component
export component App() {
  const todos = #[];

  function add(text) {
    todos.push(#{ id: Date.now(), text, completed: false });
  }

  function toggle(t) {
    t.completed = !t.completed;
  }

  function remove(id) {
    const idx = todos.findIndex(t => t.id === id);
    if (idx >= 0) todos.splice(idx, 1);
  }

  const remaining = () => todos.filter(t => !t.completed).length;

  <div class="app">
    <h1>{"Todo List"}</h1>

    <TodoInput onAdd={add} />

    <ul>
      for (const t of todos) {
        <TodoItem
          todo={t}
          onToggle={() => toggle(t)}
          onDelete={() => remove(t.id)}
        />
      }
    </ul>

    <p>{todos.length}{" total / "}{remaining()}{" remaining"}</p>
  </div>
}

Framework Comparison

Feature
Ripple
React
Vue 3
Svelte

State model
track() + @
Hooks
ref() / reactive
Stores

DOM updates
Fine-grained
VDOM diff
VDOM diff
Compile

Boilerplate
Very low
High
Medium
Low

CSS
Scoped
Modules
SFC Scoped
Scoped

AI-friendly
High
Medium
Medium
High

Runtime size
Small
Large
Medium
Tiny

Who Should Use Ripple?
Ripple is ideal for:

AI-assisted codebases
dashboards & realtime UIs
enterprise maintainability
mobile/web hybrid UIs
developers who dislike overengineering

Official Links

Website
GitHub

Final Thoughts
If React gave us JSX, Vue gave us SFCs, and Svelte gave us compilation, Ripple asks:

“What if UI could be reactive without ceremony?”

And it answers convincingly.
Related articles

Mastering Bun for Maximum Developer Productivity
Mastering Modern Monorepo Development with pnpm, Workspaces
Get All Files and Folders in Node.js Directories

Clean React Architecture for Sustainable Front-End Development
Fri, 09 Jan 2026 00:00:00 GMT
React projects tend to live much longer than developers expect. Features evolve, products pivot, team members change, and soon a “quick MVP” becomes a multi-year codebase. In that reality, the winning mindset isn’t “ship the UI fast”, but organize UI so future developers can ship fast too.
Clean code in React is not about pedantic rules or academic purity. It's about:

predictable component structure
transparent data flow
minimal hidden assumptions
separation of concerns
reusable behavior and presentation layers

In this extended guide, we’ll explore real-world patterns that keep React components clean, readable, and maintainable at scale — with improved examples, new entities, and modern TypeScript-friendly patterns.
1. Extracting List Rendering Into Dedicated Components
A common early smell: components that mix business logic, screen-level state, and large .map() rendering blocks.
Overloaded Component
export function ProjectTabsPanel(props) {
  const {
    projectsArray,
    selectedProjectId,
    onProjectSelect,
    filtersArray,
    selectedFilterId,
    onFilterSelect,
  } = props;

  const hasProjects = projectsArray.length > 0;
  const hasFilters = filtersArray.length > 0;

  if (!hasProjects && !hasFilters) {
    return null;
  }

  return (
    <div className="panel">
      {hasProjects && (
        <div className="project-section">
          {projectsArray.map((item) => {
            const isChosen = item.id === selectedProjectId;
            return (
              <button
                key={item.id}
                className={isChosen ? "btn active" : "btn"}
                onClick={() => onProjectSelect(item.id)}
              >
                {item.label}
              </button>
            );
          })}
        </div>
      )}

      {hasFilters && (
        <div className="filter-section">
          {/* Filter rendering */}
        </div>
      )}
    </div>
  );
}

Refactored List Component
type ProjectListProps = {
  items: Array<{ id: string; label: string }>;
  activeId: string | null;
  onSelect: (id: string) => void;
};

function ProjectTabsList({ items, activeId, onSelect }: ProjectListProps) {
  return (
    <>
      {items.map((entry) => {
        const isActive = entry.id === activeId;
        return (
          <button
            key={entry.id}
            className={isActive ? "btn active" : "btn"}
            onClick={() => onSelect(entry.id)}
          >
            {entry.label}
          </button>
        );
      })}
    </>
  );
}

2. Moving Helper Functions Outside of Components
export function TimestampText({ value }) {
  const normalize = (ts: string) =>
    new Date(ts).toLocaleString("en-US", { dateStyle: "medium" });

  return <span>{normalize(value)}</span>;
}

Better Version
export const US_DATE_FORMAT = new Intl.DateTimeFormat("en-US", {
  dateStyle: "medium",
  timeStyle: "short",
});

export function formatTimestamp(input: string): string {
  return US_DATE_FORMAT.format(new Date(input));
}

export function TimestampText({ value }: { value: string }) {
  return <span>{formatTimestamp(value)}</span>;
}

3. Destructuring Props Explicitly
function ProfileCard({ fullName, years }: { fullName: string; years: number }) {
  return (
    <>
      <p>{fullName}</p>
      <p>{years}</p>
    </>
  );
}

4. Extracting Complex Conditions Into Named Constants
useEffect(() => {
  const shouldIgnoreScroll =
    firstLoad && messages.length === 0 && newArrived;

  if (shouldIgnoreScroll) return;

  scrollDown();
}, [firstLoad, messages.length, newArrived]);

5. Collapsing Deep Property Access
function StatsValue({ record }: { record: any }) {
  const stats = record?.details?.stats;
  const value = stats?.value ?? "N/A";

  return <div>{value}</div>;
}

6. Avoiding Magic Numbers
const BONUS_SCORE_THRESHOLD = 200;
const BONUS_MULTIPLIER = 1.1;

Conclusion
Writing clean React code is about creating systems that survive time and team growth. By separating responsibilities, extracting logic, naming conditions, and removing magic values, you make code easier to maintain, onboard, and refactor. Clean code reduces cognitive load and speeds up development — today and years from now.
Related articles

10 Must-Know Custom React Hooks for Your Projects
25 React Tips to Boost Performance and Quality
Build React UIs Faster with Chakra UI

Friday Links #33:  Modern JavaScript Picks & Highlights
Fri, 09 Jan 2026 00:00:00 GMT
JavaScript moves fast — and staying up to date can feel overwhelming. Each week we curate the most relevant updates, new libraries, and ecosystem changes so you don’t have to dig through 50 tabs and timelines. From framework releases to niche tooling improvements, this collection is designed to give developers a quick pulse check on what matters right now.
Welcome to edition #33 of Friday Links — your weekly window into the ever-evolving JavaScript ecosystem.

OpenAI Launches ChatGPT Health

OpenAI has introduced ChatGPT Health, a dedicated section inside ChatGPT focused entirely on personal health. It’s more than a themed chat — users can discuss symptoms, interpret lab results, track metrics over time, and get clear explanations of medical terms.
A key feature is integration with health and fitness services. Users can connect Apple Health, MyFitnessPal, and similar apps so the AI can analyze sleep, activity, nutrition, and wellness trends. In the U.S., it can also sync with electronic health records for reviewing test results and medical history.
Privacy is a major emphasis: ChatGPT Health uses separate infrastructure with layered encryption, and its data is not used to train base models or mixed with regular chats by default.
📜 Articles & Tutorials
Mathematics for Computer Science
Introducing CSS Grid Lanes
Replacing JS with just HTML
React2Shell exploit: What happened and lessons learned
Azure Boards integration with GitHub Copilot
Automatically load .env files in Node.js scripts
Streaming JSON in just 200 lines of JavaScript
Introducing WebF Beta: Bring JavaScript and the Web dev to Flutter
Ink 6.6 — a library for building CLI apps with React, used by Claude Code, Gemini CLI, and others.
Olmo 3: Fully Open-Source LLM from AI2 (Models, Data, & Code)
Use native dialog with Turbo (and no extra JavaScript)
How microservice architectures have shaped the usage of database technologies
TypeScript Types as a Programming Language
⚒️ Tools
A new free open-source service called Maltrail has been released for analyzing inbound and outbound network traffic and detecting malware. The project can:

detect malicious domains, URLs, and IP addresses
identify harmful HTTP User-Agent strings
spot modern attack tools on workstations
provide strong network security without complex setup — installable in one click
help reveal viruses, miners, and other unwanted network-active software

npmgraph is a web-based tool that visualizes npm package dependencies. You can enter one or more package names (or upload a package.json) to see how their dependency graphs intersect. It also supports coloring packages by different metrics (like number of maintainers) and exporting the result as an SVG.
Bruno - Bruno is a fully local and Git-native solution to accelerate and secure API work and collaboration
Free Certifications - A curated list of free courses with certifications.
worktrunk - A CLI tool to manage multiple worktrees in Git repositories.
The Concise TypeScript Book - A concise and practical guide to TypeScript, covering essential concepts and features.
Vibium - Browser automation for AI agents and humans.
📚 Libs
ConvertX - Self-hosted online file converter. Supports 1000+ formats.
Fabric.js 7 - is a JavaScript library for working with the HTML5 canvas. It runs in both browsers and Node (via node-canvas) and provides an object model for canvas elements along with SVG-to-canvas and canvas-to-SVG conversion. The project also offers many demos with full source code.
jsPDF -  Client-side JavaScript PDF generation for everyone.
JoltPhysics.js - A JavaScript/WebAssembly port of the Jolt Physics engine for real-time physics simulation in web applications.
ChordSheetJS -  A JavaScript library for parsing and formatting chords and chord sheets
PlayCanvas Model Viewer - A JavaScript library for displaying 3D models in the browser using WebGL and WebXR.
recharts - A composable charting library built on React components and D3.js.
nats.js -  JavaScript client for Node.js, Bun, Deno and browser for NATS, the cloud native messaging system
bundlemon - A tool to monitor and enforce bundle size budgets for JavaScript projects.
tinypdf - A lightweight PDF manipulation library for Node.js and the browser.
Markdown UI - An open standard for rendering interactive widgets in plain Markdown.
⌚ Releases
pnpm 10.27 Released
Prisma 7.2
Deno 2.6.4
file-type 21.2 - Detect the file type of a file, stream, or data
Fast HTML Parser 7.0.2 Released
Middy 7.0 brings middleware to AWS Lambda for Node.js, now with Durable Functions support.
Node File Trace 1.2 - determines the minimal set of files required for an app to execute.
Orange ORM 4.8 — an Object-Relational Mapper for Node, Bun, and Deno.
Repomix 1.11 — package an entire repository into a single, LLM-friendly file.
hot-shots 12.0 / 12.1 — a Node.js client for statsd, DogStatsD, and Telegraf.
React Form Events & TypeScript does an excellent job of breaking down onChange, onSubmit, onBlur, onFocus, and their TypeScript typings in a clear, practical way.
However, even with a solid understanding of form events, another problem quickly appears. Knowing how forms work doesn’t automatically tell you how to structure them once your application grows. A simple form with a few inputs is easy to manage, but as soon as you have 10–20 fields, shared validation rules, server errors, and multiple screens using the same inputs, ad‑hoc solutions stop scaling.
This article focuses on that next layer of complexity. Instead of discussing events and handlers, we’ll look at how to design a predictable, reusable form system built on four ideas:

UI primitives — small, “dumb” components responsible only for appearance.
A Cell wrapper — a single place for labels, hints, and error messages.
Field components — thin adapters between React Hook Form and your UI.
Schemas — one source of truth for validation and TypeScript types.

Together, these layers help turn forms from a recurring source of chaos into a solved, scalable part of your UI architecture.
The Scaling Problem: “Toy Form” vs “Product Form”
A typical first form is built with local state and a submit handler. It works — until it doesn’t.
import * as React from "react";

export function SignInToy() {
  const [email, setEmail] = React.useState("");
  const [secret, setSecret] = React.useState("");
  const [issues, setIssues] = React.useState<{ email?: string; secret?: string }>(
    {}
  );

  const onSubmit = (e: React.FormEvent) => {
    e.preventDefault();

    const next: typeof issues = {};
    if (!email.includes("@")) next.email = "Please enter a valid email.";
    if (secret.trim().length < 6) next.secret = "Minimum 6 characters.";
    setIssues(next);

    if (Object.keys(next).length === 0) {
      // send request...
    }
  };

  return (
    <form onSubmit={onSubmit}>
      <div>
        <label>Email</label>
        <input value={email} onChange={(e) => setEmail(e.target.value)} />
        {issues.email && <div>{issues.email}</div>}
      </div>

      <div>
        <label>Password</label>
        <input
          type="password"
          value={secret}
          onChange={(e) => setSecret(e.target.value)}
        />
        {issues.secret && <div>{issues.secret}</div>}
      </div>

      <button type="submit">Sign in</button>
    </form>
  );
}

Now imagine this pattern multiplied across a large application. More fields mean more state, more branching validation logic, and more duplicated markup. At that point, reviewing, testing, and maintaining forms becomes disproportionately expensive.
Form Libraries Help Logic, Not UI
Libraries like React Hook Form reduce boilerplate and improve performance, but they mainly solve state management and validation wiring. They don’t define how your fields should look, how errors are rendered, or how consistency is enforced across the UI.
That missing layer is where most form complexity actually lives.
The Structured Approach
The solution is to separate concerns clearly:

Primitives define how inputs look and behave at the lowest level.
Cell defines how a “field” is presented: label, hint, error.
Field components connect form state to UI.
Schemas define validation and typing in one place.

This separation keeps each piece small and understandable — and makes the whole system easier to scale.
Step 1: UI Primitives
Primitives are intentionally boring. They know nothing about forms or validation.
import * as React from "react";

export const TextInput = React.forwardRef<
  HTMLInputElement,
  React.InputHTMLAttributes<HTMLInputElement>
>(function TextInput(props, ref) {
  return <input ref={ref} {...props} className="input" />;
});

Because primitives are generic, you can reuse them outside forms — in filters, search bars, or settings panels.
Step 2: The Cell Wrapper
The Cell component standardizes layout and error display.
import * as React from "react";

type CellProps = {
  label?: string;
  hint?: React.ReactNode;
  error?: string;
  children: React.ReactNode;
};

export function Cell({ label, hint, error, children }: CellProps) {
  return (
    <div className="cell">
      {label && <label className="cell__label">{label}</label>}
      <div className="cell__control">{children}</div>
      {hint && <div className="cell__hint">{hint}</div>}
      {error && <div className="cell__error">{error}</div>}
    </div>
  );
}

All visual consistency flows through this component.
Step 3: Field Components
Field components glue React Hook Form to your UI.
import { useFormContext } from "react-hook-form";

export function TextField({ name, label, ...props }) {
  const {
    register,
    formState: { errors },
  } = useFormContext();

  return (
    <Cell label={label} error={errors[name]?.message}>
      <TextInput {...register(name)} {...props} />
    </Cell>
  );
}

Each field type lives in its own small file, making behavior explicit and predictable.
Step 4: Schemas and Validation
Schemas (for example, with Zod) give you a single source of truth.
import { z } from "zod";

export const ProfileSchema = z.object({
  email: z.string().email("Invalid email"),
  password: z.string().min(6, "Minimum 6 characters"),
});

export type ProfileValues = z.infer<typeof ProfileSchema>;

Validation rules and TypeScript types stay in sync.
Step 5: Assembling a Form
import { FormProvider, useForm } from "react-hook-form";
import { zodResolver } from "@hookform/resolvers/zod";

export function ProfileForm() {
  const methods = useForm({
    resolver: zodResolver(ProfileSchema),
  });

  return (
    <FormProvider {...methods}>
      <form onSubmit={methods.handleSubmit(console.log)}>
        <TextField name="email" label="Email" />
        <TextField name="password" label="Password" type="password" />
        <button type="submit">Save</button>
      </form>
    </FormProvider>
  );
}

The form reads like intent, not implementation details.
Conclusion
Understanding React form events is the foundation — but structure is what makes forms scale. By layering primitives, a shared Cell wrapper, and small field components on top of a form library, you get consistency, reuse, and clarity without sacrificing flexibility.
Once this system is in place, forms stop being a special problem and become just another predictable part of your UI.
Related articles

 are a set with a single element

never is the empty set

Because never has no possible values, no actual value can ever belong to it. That’s why the following function is valid:
export function triggerFailure(reason: string): never {
  throw new Error(reason);
}

TypeScript ensures that functions returning never cannot complete normally.
const outcome = triggerFailure("Unexpected state!");
//    ^? never

outcome has type never, because TypeScript knows the function cannot return.

Exhaustive error handling
type ApiResult =
  | { status: "success"; data: string }
  | { status: "error"; error: Error };

function assertNever(value: never): never {
  throw new Error(`Unhandled case: ${JSON.stringify(value)}`);
}

function handleResult(result: ApiResult) {
  switch (result.status) {
    case "success":
      return result.data;

    case "error":
      throw result.error;

    default:
      return assertNever(result);
  }
}

Here, never ensures that every possible state of ApiResult is handled.
If a new status is added later, TypeScript will immediately report an error.
This is where never becomes valuable — not as a theoretical type,
but as a guardrail for evolving codebases.
The Common Mistake: Using never for Error Modeling
Developers sometimes attempt this pattern:
export function safeDivide(x: number, y: number): number | never {
  if (y === 0) {
    throw new Error("Division by zero!");
  }
  return x / y;
}

They expect the return type to reflect both “good” and “error” states.
But TypeScript evaluates:
number | never → number

The empty set adds nothing to the union — never collapses and becomes meaningless.
This is why:
const result = safeDivide(10, 0);
// result: number

This code successfully compiles but is misleading.

The never type should never be used to describe an error state.

Why never Collapses in Unions
Unions represent the set‑theoretic union of their members.
(number-set) ∪ (empty-set) = number-set

This is not a TypeScript quirk — it is mathematically correct.
Thus:

string | never → string
boolean | never → boolean
T | never → T

never disappears because it cannot contribute any valid value.

The Correct Use of never: Exhaustiveness Checking
never becomes powerful when used to model impossible states.
Step 1 — Create a discriminated union
type CircleShape = { kind: "circle"; radius: number };
type SquareShape = { kind: "square"; side: number };
type RectShape = { kind: "rectangle"; width: number; height: number };

type ShapeEntity = CircleShape | SquareShape | RectShape;

Step 2 — Write an exhaustiveness checker
function assertImpossible(value: never): never {
  throw new Error("Encountered an impossible case: " + JSON.stringify(value));
}

Step 3 — Use it inside a switch
export function computeArea(geom: ShapeEntity): number {
  switch (geom.kind) {
    case "circle":
      return Math.PI * geom.radius ** 2;

    case "square":
      return geom.side ** 2;

    case "rectangle":
      return geom.height * geom.width;

    default:
      return assertImpossible(geom);
  }
}

If someone later updates:
type TriangleShape = { kind: "triangle"; a: number; b: number; c: number };
type ShapeEntity = CircleShape | SquareShape | RectShape | TriangleShape;

The compiler immediately screams:
Argument of type 'TriangleShape' is not assignable to parameter of type 'never'.

This is exactly how never should be used:

catching missing branches

preventing silent logic failures

enforcing total coverage of all cases

A Better Model for Error Handling: The Result Pattern
Instead of misusing never, model error states explicitly using a discriminated union:
type FailureInfo = { status: "fail"; message: string };
type SuccessInfo<T> = { status: "ok"; data: T };

type ResultBox<T> = FailureInfo | SuccessInfo<T>;

Helper creators:
const createFailure = (msg: string): FailureInfo => ({
  status: "fail",
  message: msg,
});

const createSuccess = <T>(value: T): SuccessInfo<T> => ({
  status: "ok",
  data: value,
});

A safe division using proper error modeling:
export function robustDivide(n1: number, n2: number): ResultBox<number> {
  if (n2 === 0) return createFailure("Division by zero");
  return createSuccess(n1 / n2);
}

Usage:
const output = robustDivide(8, 0);

if (output.status === "fail") {
  console.error("Error:", output.message);
} else {
  console.log("Result:", output.data);
}

This is explicit, predictable, and fully typed.

Wrapping Unsafe Functions: A try-Safe Wrapper
Sometimes an existing function throws. Wrap it safely:
export function handleSafely<Args extends unknown[], Ret>(
  fn: (...p: Args) => Ret,
  ...inputs: Args
): ResultBox<Ret> {
  try {
    return createSuccess(fn(...inputs));
  } catch (err: any) {
    return createFailure(err?.message ?? "Unknown failure");
  }
}

Example:
function riskyDivide(a: number, b: number) {
  if (b === 0) throw new Error("Boom!");
  return a / b;
}

const checked = handleSafely(riskyDivide, 10, 0);

Converting ResultBox to a Throwing Function
If needed, convert the safe result back into a throwing workflow:
export function unwrapOrCrash<T>(supplier: () => ResultBox<T>): T {
  const outcome = supplier();
  if (outcome.status === "ok") return outcome.data;
  throw new Error(outcome.message);
}

Usage:
const finalAnswer = unwrapOrCrash(() => robustDivide(10, 2));

Why never Often Fails in Real Projects
Using never does not automatically make code safer.
Common mistakes include:

assuming never replaces runtime validation
overusing it in public APIs
hiding real errors behind “impossible” states

In production, never works best when combined with:

discriminated …

Chakra UI: A Complete Guide to Faster, Cleaner, and Accessible UI
Mon, 24 Nov 2025 00:00:00 GMT
In day‑to‑day frontend work, we keep solving the same problems:

building consistent buttons, forms, layouts, and modals
making everything responsive on phones, tablets, and desktops
keeping colors, typography, and spacing uniform across the app
implementing accessibility and keyboard navigation correctly
fighting with ever‑growing CSS files and design drift

Writing CSS from scratch for every new page quickly turns into a chore. That’s exactly the type of repetitive work Chakra UI removes from your life.
In this guide, we’ll look at how Chakra UI v3 paired with React helps you:

stop hand‑writing CSS for every component
keep a single source of truth for design tokens
ship accessible UI without memorizing every WAI‑ARIA rule
build responsive layouts without writing @media queries
keep performance under control with tree‑shaking and minimal styling runtime

Along the way we’ll use improved code samples, renamed variables, and modern patterns.

Official docs: chakra docs

Why Styling Libraries Exist at All
Let’s be honest: vanilla CSS is powerful, but it doesn’t scale nicely in large React apps.
Typical problems when you style everything manually:
1. Slowness
You might spend hours on details like hover states, focus rings, input errors, spacing between elements, and layout quirks.
2. Visual Inconsistency
You start with a clean design, but six months later:

different border radii, slightly different blues, spacing that "almost" matches, and three button variations that should have been one.
3. Accessibility Debt
Screen readers, roles, ARIA attributes, focus management, ESC handling, keyboard navigation – all this is crucial, but hard to do correctly and consistently with plain HTML + CSS.
4. Bloated CSS
Legacy styles accumulate: old classes, unused helpers, and confusing overrides. Bundle size grows, and nobody wants to delete anything because "it might be used somewhere".
Component styling libraries like Chakra UI solve these with:

ready‑made building blocks (Button, Stack, Modal, Menu, etc.)
theme tokens instead of magic values
accessibility first approach
built‑in responsiveness

Chakra takes this approach and makes it very ergonomic for React.

1. Styling with Props Instead of Raw CSS
In Chakra, style props are the core idea:

you describe what the component should look like directly in JSX instead of switching between JS and CSS files.
A basic button, Chakra style
import { Button } from "@chakra-ui/react"

export function SendMessageButton() {
  return (
    <Button
      colorScheme="teal"
      size="lg"
      borderRadius="xl"
      boxShadow="md"
      _hover={{
        boxShadow: "xl",
        transform: "translateY(-1px)",
      }}
    >
      Send message
    </Button>
  )
}

This one component includes:

colors
size
border radius
shadow
hover state

No separate CSS file, no BEM class names, no :hover selectors.
Equivalent CSS for comparison
.primary-button {
  background-color: #319795;
  color: #fff;
  padding: 0.75rem 1.5rem;
  border-radius: 0.75rem;
  box-shadow: 0 4px 6px rgba(0, 0, 0, .1);
  transition: all 0.15s ease-out;
}

.primary-button:hover {
  box-shadow: 0 10px 15px rgba(0, 0, 0, .15);
  transform: translateY(-1px);
}

export function SendMessageButtonRaw() {
  return <button className="primary-button">Send message</button>
}

Both work, but the Chakra version:

keeps markup and styles in one place
is more discoverable (props are auto‑completed in your IDE)
plays nicely with dynamic values coming from state or props

Style props reference

2. A Single Theme Controls the Whole App
Instead of scattering values like #319795 and 1.5rem across components, Chakra encourages you to put them into a theme.
You can extend the default theme or create your own system.
Minimal theme setup with design tokens
import {
  ChakraProvider,
  createSystem,
  defaultConfig,
  defineConfig,
} from "@chakra-ui/react"

const designConfig = defineConfig({
  theme: {
    tokens: {
      colors: {
        accent: { value: "#6ED209" },
        surface: { value: "#F8FFF2" },
      },
      radii: {
        pill: { value: "999px" },
      },
    },
  },
})

const designSystem = createSystem(defaultConfig, designConfig)

export function RootApp({ children }: { children: React.ReactNode }) {
  return <ChakraProvider value={designSystem}>{children}</ChakraProvider>
}

Now you can use accent and surface anywhere:
import { Box, Button } from "@chakra-ui/react"

export function AccentCard() {
  return (
    <Box bg="surface" p={6} borderRadius="lg">
      <Button bg="accent" borderRadius="pill">
        Accent action
      </Button>
    </Box>
  )
}

Change accent in one place → entire app updates.
Theming guide
Extracting theme configuration into its own file
A common pattern is to keep all theme logic in something like theme/system.ts:
// theme/system.ts
import { defineConfig, createSystem, defaultConfig } from "@chakra-ui/react"

const designConfig = defineConfig({
  globalCss: {
    "html, body": {
      margin: 0,
      padding: 0,
      fontFamily: "system-ui, -apple-system, BlinkMacSystemFont, sans-serif",
      scrollBehavior: "smooth",
    },
  },
  theme: {
    tokens: {
      colors: {
        "ink-strong": { value: "#1A202C" },
        "ink-soft": { value: "#718096" },
        "paper": { value: "#F7FAFC" },
      },
    },
    semanticTokens: {
      colors: {
        appBackground: {
          value: {
            base: "{colors.paper}",
            _dark: "#1A202C",
          },
        },
        appText: {
          value: {
            base: "{colors.ink-strong}",
            _dark: "{colors.paper}",
          },
        },
      },
    },
  },
})

export const designSystem = createSystem(defaultConfig, designConfig)

Then in your entry point:
// app/providers.tsx
import { ChakraProvider } from "@chakra-ui/react"
import { designSystem } from "@/theme/system"

export function Providers({ children }: { children: React.ReactNode }) {
  return <ChakraProvider value={designSystem}>{children}</ChakraProvider>
}

This gives you one place to tune your entire design language.

3. Accessibility Built In by Default
Manually making UI accessible means dealing with:

role, aria-* attributes
focus traps for modals
escape handling
tab order for menus
keyboard navigation for lists and dialogs
aria-live for announcements

Chakra UI bakes this into its components.
WAI‑ARIA specs
Accessible alert message
import { Alert, AlertIcon, AlertTitle, AlertDescription } from "@c…

Mastering React Form Events with TypeScript
Mon, 24 Nov 2025 00:00:00 GMT
Working with forms is one of the most common tasks in React — and one of the most misunderstood. Beginners often struggle with event types, how to strongly‑type form handlers, how to extract values, and how to work with keyboard, mouse, focus, and form‑submission events correctly.
This improved guide explains every major React form event, adds better TypeScript examples, and focuses heavily on real‑world patterns like validation, debouncing, controlled inputs, preventing default behavior, and working with form data.

Why React Form Events Matter
Any time a user:

types into an input
clicks a button
submits a form
focuses or blurs a field
presses a key
interacts with checkboxes, selects, radios, sliders

…React fires an event object you can react to.
TypeScript helps us ensure correctness, catch mistakes, and avoid bugs like undefined values or invalid event targets.

1. onChange: The Most Important Form Event
TypeScript Type:
React.ChangeEvent<HTMLInputElement>

onChange fires whenever the value of an input changes.
Improved Real‑World Example: Typing with Validation
import { useState } from "react";

export function UsernameField() {
  const [username, setUsername] = useState("");
  const [error, setError] = useState("");

  const handleUsername = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = e.target.value;
    setUsername(value);

    if (value.length < 3) {
      setError("Username must be at least 3 characters.");
    } else {
      setError("");
    }
  };

  return (
    <div>
      <label>
        Username:
        <input type="text" value={username} onChange={handleUsername} />
      </label>

      {error && <p style={{ color: "red" }}>{error}</p>}
    </div>
  );
}

2. onSubmit: Handling Entire Form Submission
TypeScript Type:
React.FormEvent<HTMLFormElement>

Improved Example with FormData Extraction
import { useState } from "react";

export function LoginForm() {
  const [message, setMessage] = useState("");

  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();

    const form = e.currentTarget;
    const data = new FormData(form);

    const email = data.get("email") as string;
    const password = data.get("password") as string;

    setMessage(`Submitted: ${email} / ${password}`);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="email" type="email" placeholder="Email" required />
      <input name="password" type="password" placeholder="Password" required />
      <button type="submit">Log In</button>
      <p>{message}</p>
    </form>
  );
}

3. onFocus: Detecting When a User Enters a Field
React.FocusEvent<HTMLInputElement>

Example: Highlight active field
import { useState } from "react";

export function FocusExample() {
  const [focused, setFocused] = useState(false);

  return (
    <div>
      <input
        onFocus={() => setFocused(true)}
        style={{ borderColor: focused ? "dodgerblue" : "#ccc" }}
      />
      {focused && <p>You're typing now!</p>}
    </div>
  );
}

4. onBlur: When the User Leaves a Field
React.FocusEvent<HTMLInputElement>

Example: Email validation
import { useState } from "react";

export function EmailField() {
  const [error, setError] = useState("");

  const handleBlur = (e: React.FocusEvent<HTMLInputElement>) => {
    const email = e.target.value;
    setError(email.includes("@") ? "" : "Invalid email.");
  };

  return (
    <div>
      <input type="email" onBlur={handleBlur} placeholder="Enter email" />
      {error && <p style={{ color: "red" }}>{error}</p>}
    </div>
  );
}

5. onClick: Buttons & Interactions
TypeScript Type:
React.MouseEvent<HTMLButtonElement>

Example: Button loading state
import { useState } from "react";

export function LoadingButton() {
  const [loading, setLoading] = useState(false);

  const handleClick = async () => {
    setLoading(true);
    await new Promise(res => setTimeout(res, 1000));
    setLoading(false);
  };

  return (
    <button onClick={handleClick} disabled={loading}>
      {loading ? "Loading..." : "Click me"}
    </button>
  );
}

6. Keyboard Events
React.KeyboardEvent<HTMLInputElement>

Example: Submit on Enter
import { useState } from "react";

export function SearchBox() {
  const [query, setQuery] = useState("");

  const handleKey = (e: React.KeyboardEvent<HTMLInputElement>) => {
    if (e.key === "Enter") {
      alert(`Searching for: ${query}`);
    }
  };

  return (
    <input
      value={query}
      onChange={(e) => setQuery(e.target.value)}
      onKeyDown={handleKey}
      placeholder="Press Enter to search"
    />
  );
}

7. Bonus: Debounced Input
import { useState, useEffect } from "react";

export function DebouncedInput() {
  const [raw, setRaw] = useState("");
  const [debounced, setDebounced] = useState("");

  useEffect(() => {
    const id = setTimeout(() => setDebounced(raw), 400);
    return () => clearTimeout(id);
  }, [raw]);

  return (
    <div>
      <input
        onChange={(e) => setRaw(e.target.value)}
        placeholder="Type slowly..."
      />
      <p>Debounced: {debounced}</p>
    </div>
  );
}

Final Thoughts
You now know how to handle:

change events
submit events
focus/blur
click events
keyboard events
validation
debouncing
extracting FormData

React + TypeScript becomes much easier once you understand event types.
Related articles

10 Must-Know Custom React Hooks for Your Projects
25 React Tips to Boost Performance and Quality
Build React UIs Faster with Chakra UI

Howto Fix the “Role Postgres Does Not Exist” Error in Docker
Mon, 17 Nov 2025 00:00:00 GMT
When deploying a PostgreSQL instance inside a Docker container, one of the most common startup failures is:
psql: FATAL: role "postgres" does not exist

This error typically indicates that the initialization scripts did not create the default postgres superuser. Below we explore the causes and the correct fixes.

1. Why the Error Occurs
1.1 Your data volume already has an old database
PostgreSQL only creates users when the data directory is empty.

If you reuse a volume, the postgres role may simply not exist.
1.2 You changed the default POSTGRES_USER
POSTGRES_USER=myuser

This makes myuser the superuser — not postgres.
1.3 Incorrect filesystem permissions
If PostgreSQL cannot write to /var/lib/postgresql/data, initialization may silently fail.

2. Solutions
A. Delete the old volume (recommended)
docker compose down -v
docker compose up -d

B. Explicitly set POSTGRES_USER
environment:
  POSTGRES_USER: postgres
  POSTGRES_PASSWORD: secret123

Restart:
docker compose down
docker compose up -d

C. Manually create the missing role
docker exec -it <container> bash
psql -U myuser

Inside PostgreSQL:
CREATE ROLE postgres WITH SUPERUSER LOGIN PASSWORD 'changeme';

D. Fix permissions
sudo chown -R 999:999 /path/to/volume
docker compose restart

3. Best Practices

Always specify POSTGRES_USER and POSTGRES_PASSWORD.
Prefer named volumes over bind mounts.
Add healthchecks:

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U postgres"]
  interval: 5s
  timeout: 3s
  retries: 5

4. Conclusion
This error happens because the container is using an already-initialized volume or the default superuser was changed. Resetting the volume, correcting your environment variables, or creating the role manually will resolve the problem.
If you want extended troubleshooting for specific platforms (Railway, Render, Fly.io, Docker Swarm), I can add that too.
Related articles

Setting Up Jaeger with Docker on Windows
Setting Up Local PostgreSQL with Docker Compose
Practical Month Arithmetic and Calendar Logic in JavaScript

How to Develop Accessible Interfaces with WAI-ARIA
Mon, 17 Nov 2025 00:00:00 GMT
Modern web applications have evolved into rich, desktop‑like interactive environments. Components such as modals, dropdown menus, accordions, tabs, and dynamically updated content are now standard. However, accessibility is often overlooked, leaving millions of users unable to interact with applications effectively. WAI‑ARIA provides a way to enrich custom UI components with semantic meaning and behavior for assistive technologies.
What WAI‑ARIA Is
WAI‑ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) is a specification created by the W3C to describe interactive interfaces to screen readers, keyboard users, and assistive devices. While HTML includes semantic elements like <button> and <nav>, developers frequently build UI using <div> or <span>, resulting in missing information for accessibility tools. ARIA fills in those gaps.
ARIA includes three core building blocks:

Roles — define the purpose of an element
States & Properties (aria-*) — describe its current condition
Live Regions — announce dynamic updates

ARIA Roles
Roles communicate what an element represents.
Examples include:

button
navigation
dialog
tab, tablist, tabpanel
menu, menuitem
checkbox, switch

Use native HTML elements whenever possible; use ARIA only when necessary.
ARIA Properties & States
These attributes explain how a UI element behaves and what its current status is.
Properties

aria-label
aria-labelledby
aria-describedby

States

aria-expanded
aria-selected
aria-checked
aria-disabled

Live Regions
Live regions notify users of dynamic content updates:

aria-live="polite"
aria-live="assertive"
aria-atomic="true"
aria-relevant="additions text"

These are essential for notifications, error messages, chat updates, and async content.
ARIA in SPA/React Environments
Frameworks like React sometimes re-render without changing DOM nodes, which can prevent screen readers from detecting updates. Use:

Live regions
Forced DOM updates
Proper role and aria-* attributes
Real testing with assistive tools

Keyboard Accessibility
Keyboard navigation is a core WCAG requirement.
Essential keys:

Tab / Shift+Tab — move focus
Enter / Space — activate
Arrow keys — navigate inside composite widgets
Escape — close dialogs
Home / End — jump to start/end

Use:

tabindex="0"
tabindex="-1"
aria-activedescendant for virtual focus

Testing Accessibility
Browser Tools

Axe DevTools
Lighthouse
WAVE

Screen Readers

NVDA
JAWS
VoiceOver

Linters

eslint-plugin-jsx-a11y

CI

Axe CI
Pa11y CI
Lighthouse CI

Example: Accessible Accordion Component
Here is a completely different example, not related to the previous code and without any internal comments directed at you. It demonstrates a well‑structured, accessible accordion widget using WAI‑ARIA best practices.
HTML Structure
<div class="accordion">
  <h2 id="faq-title">FAQ</h2>

  <div class="accordion__item">
    <button
      class="accordion__trigger"
      aria-expanded="false"
      aria-controls="sect-1"
      id="accordion-btn-1"
    >
      What is accessibility?
    </button>
    <div
      class="accordion__panel"
      id="sect-1"
      role="region"
      aria-labelledby="accordion-btn-1"
      hidden
    >
      <p>
        Accessibility ensures that interfaces can be used by people with
        disabilities or assistive technologies.
      </p>
    </div>
  </div>

  <div class="accordion__item">
    <button
      class="accordion__trigger"
      aria-expanded="false"
      aria-controls="sect-2"
      id="accordion-btn-2"
    >
      What is WAI‑ARIA?
    </button>
    <div
      class="accordion__panel"
      id="sect-2"
      role="region"
      aria-labelledby="accordion-btn-2"
      hidden
    >
      <p>
        WAI‑ARIA provides roles and attributes that describe UI behavior to
        assistive technologies.
      </p>
    </div>
  </div>
</div>

JavaScript Logic (Brand‑New Example)
class AriaAccordion {
  constructor(containerEl) {
    this.containerEl = containerEl;
    this.triggers = Array.from(
      containerEl.querySelectorAll(".accordion__trigger")
    );

    this.triggers.forEach(btn => {
      btn.addEventListener("click", () => this.toggle(btn));
      btn.addEventListener("keydown", e => this.onKey(e, btn));
    });
  }

  toggle(buttonEl) {
    const isOpen = buttonEl.getAttribute("aria-expanded") === "true";
    const newState = !isOpen;

    buttonEl.setAttribute("aria-expanded", newState);

    const panelId = buttonEl.getAttribute("aria-controls");
    const panel = document.getElementById(panelId);
    panel.hidden = !newState;
  }

  onKey(event, buttonEl) {
    const { code } = event;
    const index = this.triggers.indexOf(buttonEl);

    if (code === "ArrowDown") {
      event.preventDefault();
      const next = this.triggers[index + 1] || this.triggers[0];
      next.focus();
    }

    if (code === "ArrowUp") {
      event.preventDefault();
      const prev =
        this.triggers[index - 1] || this.triggers[this.triggers.length - 1];
      prev.focus();
    }
  }
}

document
  .querySelectorAll(".accordion")
  .forEach(acc => new AriaAccordion(acc));

Conclusion
ARIA is powerful, but with that power comes responsibility. Developers should:

use semantic HTML whenever possible,
apply ARIA roles and states only when appropriate,
provide keyboard interaction patterns,
test with real assistive technologies,
and follow W3C ARIA Authoring Practices.

By embracing these principles, you ensure your interface works smoothly for every user—regardless of device, ability, or assistive technology.
Related articles

Mastering Custom Elements in HTML5
The Overlooked Power of the HTML <output> Element
Checking Web Pages for WCAG Compliance

Identify If a Value Belongs to a Class in JavaScript
Mon, 17 Nov 2025 00:00:00 GMT
Introduction
Instance checking in JavaScript appears simple at first—just use instanceof.

But real-world scenarios (and tasks like LeetCode 2618) require correctly handling:

primitive values (42, 'hi', true, 5n)
wrapper constructors (Number, String, etc.)
invalid constructor inputs
functions as instances of Function
prototype chain traversal
custom instance logic via Symbol.hasInstance

This snippet provides three reliable solutions, rewritten and improved for clarity, correctness, and edge-case safety.

Solution 1 — Recommended
Using instanceof + Primitive Mapping
Works for objects and functions, with explicit special rules for built-in primitive wrappers.
function isInstance(candidate, ctor) {
  if (ctor == null || typeof ctor !== "function") return false;
  if (candidate == null) return false;

  if (candidate instanceof ctor) return true;

  const type = typeof candidate;
  if (ctor === Number) return type === "number";
  if (ctor === String) return type === "string";
  if (ctor === Boolean) return type === "boolean";
  if (ctor === BigInt) return type === "bigint";
  if (ctor === Symbol) return type === "symbol";

  return false;
}

Solution 2
Manual Prototype Chain Traversal
function isInstanceByPrototype(value, ctor) {
  if (ctor == null || typeof ctor !== "function") return false;
  if (value == null) return false;

  const type = typeof value;

  if (ctor === Number) return type === "number";
  if (ctor === String) return type === "string";
  if (ctor === Boolean) return type === "boolean";
  if (ctor === BigInt) return type === "bigint";
  if (ctor === Symbol) return type === "symbol";

  if (type !== "object" && type !== "function") return false;

  let proto = Object.getPrototypeOf(value);
  const target = ctor.prototype;

  while (proto) {
    if (proto === target) return true;
    proto = Object.getPrototypeOf(proto);
  }

  return false;
}

Solution 3
Using Symbol.hasInstance
function isInstanceBySymbol(value, ctor) {
  if (ctor == null || typeof ctor !== "function") return false;
  if (value == null) return false;

  const hook = ctor[Symbol.hasInstance];
  if (typeof hook === "function" && hook.call(ctor, value)) {
    return true;
  }

  const type = typeof value;
  if (ctor === Number) return type === "number";
  if (ctor === String) return type === "string";
  if (ctor === Boolean) return type === "boolean";
  if (ctor === BigInt) return type === "bigint";
  if (ctor === Symbol) return type === "symbol";

  return false;
}

Examples
class Creature {}
class Feline extends Creature {}
function Demo() {}

console.log(isInstance(new Date(), Date));        
console.log(isInstance(new Feline(), Creature));  
console.log(isInstance(123, Number));             
console.log(isInstance("ok", String));            
console.log(isInstance(true, Boolean));           
console.log(isInstance(7n, BigInt));              
console.log(isInstance(Symbol("x"), Symbol));     

console.log(isInstance(123, Object));             
console.log(isInstance(null, Object));            
console.log(isInstance(undefined, Number));       
console.log(isInstance(Creature, Creature));      
console.log(isInstance(Demo, Function));          

Related content

WebSocket Client JavaScript Implementation
Deeply Freeze a Nested Object
Convert coordinates from EPSG-4326 to EPSG-3857

Goal	Command
Remove local commit	`git reset`
Undo pushed commit safely	`git revert`
Restore file	`git restore`
Fix last commit	`git commit --amend`
Recover deleted history	`git reflog`

Trend	Impact on the Ecosystem
React Server Components	Reduced client bundle sizes and moved data fetching closer to the server
TypeScript Everywhere	Libraries increasingly design APIs around type inference
AI-Assisted Development	Tooling shifted toward faster iteration and code generation workflows
Edge Deployment	Frameworks optimized for distributed execution
Monorepo Growth	Shared packages and workspace tooling became standard
Utility-First Styling	Tailwind and token-based systems became dominant
Async UI Patterns	Streaming and optimistic interfaces became common

Prefix	Meaning
feat	new feature
fix	bug fix
docs	documentation changes
style	formatting only
refactor	code improvements without behavior change
test	new or updated tests
chore	tooling or configuration changes

Operation	Description	Required Complexity
`get(key)`	Return the value associated with the key, or `-1` if not found. Also mark it as recently used.	O(1)
`put(key, value)`	Insert or update a value. If capacity is exceeded, remove the least recently used item.	O(1)

OOP Concept	React Equivalent
Class	Component
Method	Hook / handler
Dependency	Service / API
Composition	Component composition
Abstraction	Hook interface

Method	End-of-month safe	DST aware	Recommended
`+30 days`	No	No	Never
`setMonth`	Partial	Yes	Good
Custom safe function	Yes	Yes	Billing scenarios
`date-fns addMonths`	Yes	Yes	Most applications

Use Case	Approach
Billing	custom EOM logic
UI calendars	date-fns `addMonths`
Internal UTC timestamps	native `setMonth`
Finance	custom logic + UTC

Task	Function
UTC → local	`utcToZonedTime(utc, zone)`
Local → UTC	`zonedTimeToUtc(local, zone)`
Format	`format(date, pattern)`
Store	`date.toISOString()`

Concern	Ownership
UI behavior	Declarative configuration
UI rendering	Modal orchestrator
DOM structure	DOM utility layer
polling logic	polling helper
reactive state	Proxy-based tracker

Feature	Ripple	React	Vue 3	Svelte
State model	`track()` + `@`	Hooks	`ref()` / reactive	Stores
DOM updates	Fine-grained	VDOM diff	VDOM diff	Compile
Boilerplate	Very low	High	Medium	Low
CSS	Scoped	Modules	SFC Scoped	Scoped
AI-friendly	High	Medium	Medium	High
Runtime size	Small	Large	Medium	Tiny

JavaScript Development Space - Master JS and NodeJS

Build a Minimal Crypto Dashboard with CCXT, CoinGecko and React

Introduction

Step 1: Create the Project

Step 2: Add Scripts

Step 3: Create the Backend API

Step 4: Define the Watchlist

Step 5: Add CoinGecko Fallback

Step 6: Create the Prices Endpoint

Step 7: Add Candlestick Data with fetchOHLCV

Howto Find the Start of a Cycle in a Linked List

The Problem

Example 1

Example 2

Example 3

Why a Normal Traversal Doesn't Work

Floyd's Fast and Slow Pointer Technique

Visual Example

Finding the Entry Point of the Cycle

Why Does This Work?

JavaScript Solution

Step-by-Step Walkthrough

Phase 1: Detect the Cycle

Phase 2: Locate the Entry

Alternative Solution Using a Hash Set

Pros

Cons

Complexity Analysis

Common Interview Questions

Why do the pointers always meet when a cycle exists?

Why reset one pointer to the head?

Can this problem be solved without Floyd's algorithm?

What prevents the fast pointer from causing errors?

Final Thoughts

How to Build Smooth Scrolling Interfaces with CSS Scroll Snap

Introduction

What Is CSS Scroll Snap?

The Basic Structure

Understanding scroll-snap-type

Mandatory vs Proximity Snapping

Using scroll-snap-align

Building a CSS-Only Product Carousel

Improving the Carousel for Real Projects

Next.js App Router Caching: Why Your Data Stayed Stale

Step One: Detect Whether the Server Rendered Again

Rendering Freshness and Data Freshness Are Different Signals

force-cache: The UI Updates, the Network Request Doesn't

no-store: When Every Request Must Be Fresh

revalidate: Usually the Practical Choice

Protecting Next.js Applications in the Era of Server Actions

The New Frontend Security Model

Why Server Actions Quietly Changed the Threat Model

The Dangerous Illusion of Hidden Server Logic

Treat Server Actions Like Production API Endpoints

TypeScript Is Not Runtime Security

Defense in Depth with Zod

Making Server Actions Safer with next-safe-action

Server Components and Accidental Data Leaks

Howto Use Git Bisect to Find the Commit That Broke Everything

The Core Idea: Binary Search for Broken Code

Starting a Git Bisect Session

Testing Each Candidate Commit

When Git Finds the Guilty Commit

A Practical Example

Don’t Forget to Reset Afterwards

Automating Git Bisect with Tests

Using Custom Validation Scripts

Why Developers Forget This Tool Exists

When Git Bisect Becomes Especially Valuable

Regression Bugs

Large Teams

Old Codebases

CI Failures

Final Thoughts

TypeScript Security From Backend to Browser

TypeScript Is Not a Security Boundary

Backend Reality: HTTP Requests Arrive Before Type

SQL Injection Still Exists Inside ORM Code

The Hidden ORM Trap: QueryBuilder and Raw()

NoSQL Injection Is Still Injection

Step 7: Add Candlestick Data with `fetchOHLCV`

Understanding `scroll-snap-type`

Using `scroll-snap-align`

`force-cache`: The UI Updates, the Network Request Doesn't

`no-store`: When Every Request Must Be Fresh

`revalidate`: Usually the Practical Choice

Making Server Actions Safer with `next-safe-action`

The Hidden ORM Trap: `QueryBuilder` and Raw()

Dangerous Pattern #1 — Dynamic `eval()`

🎟️ Use code `TWIR` for 10% off your ticket.

The Binding Rules Behind `this`

Remove the Last Local Commit with `git reset`

Understanding `HEAD~1`

Undo a Pushed Commit with `git revert`

Restore a Single File with `git restore`

Fix the Last Commit with `git commit --amend`

Recover Deleted Work with `git reflog`

Undo `git add`