JavaScript Development Space - Master JS and NodeJS

Friday Links #41: JavaScript, AI and Open Source

Fri, 17 Jul 2026 00:00:00 GMT

Another busy week brought new JavaScript releases, fresh AI coding tools, browser improvements, and several open source projects that deserve attention. There were also important updates from the Node.js ecosystem, new developer utilities, and a handful of experiments that hint at where modern web development is heading next.

As always, this issue collects the stories, libraries, tutorials, and launches that stood out. Whether you're building production applications, experimenting with AI-assisted development, or simply trying to keep up with the ecosystem, these are the links worth adding to your reading list.

🧠 Language & Runtime Updates

TypeScript 7.0

The biggest release of the week is finally here. TypeScript 7 has officially landed, introducing the long-awaited Go-based compiler that's designed to dramatically reduce compilation times, especially for large codebases.

It's still early days, though. Much of the ecosystem continues to target TypeScript 6 while tooling authors update plugins, language servers, and build integrations. If you're planning to upgrade, it's worth checking compatibility with your existing toolchain first.

npm 12

npm has reached another major milestone with the release of version 12.

The new version includes CLI improvements, dependency management updates, performance refinements, and plenty of internal cleanup. While there aren't many headline-grabbing features, it's an important release that lays the groundwork for future improvements across the Node.js ecosystem.

Bun 1.3.14

Bun continues its rapid release cadence. Version 1.3.14 focuses primarily on bug fixes, compatibility improvements, and runtime performance.

The Bun team also published one of the most interesting engineering stories of the year: a detailed write-up explaining how the runtime is being rewritten from Zig to Rust using dozens of parallel Claude Code sessions. The Rust implementation will become the foundation of Bun 1.4.

Node.js 26.5.0

Node.js 26 continues to evolve with another feature-packed release. Version 26.5 adds support for importing text files using ESM import attributes, making it easier to work with non-JavaScript assets without custom loaders.

The release also introduces blob.textStream() along with several smaller improvements across the runtime, performance, and platform APIs.

📜 Articles & Tutorials

LiteRT.js, Google's high performance Web AI Inference

6 security settings every GitHub maintainer should enable this week

How to Read Large JSON Files Without Losing Your Mind

Building Persistent Page Transitions with WebGPU and Vanilla JavaScript

SolidJS 2.0: A React Developer's First Look at Signals and Async

Do we still need build tools?

How to create awesome staggered animations in CSS, Color.js v0.7.0

Password Hashing Done Right: Argon2, bcrypt, Salt and Pepper

Next.js Security Release and Our Next Patch Release

⚒️ Tools

HTML Formatter Online - A simple online tool for formatting and beautifying HTML code. It supports various formatting options, including indentation styles, line breaks, and attribute sorting, making it easy to clean up messy HTML code.

Babylon Lite: A Fresh Take on Babylon.js — What if the Babylon.js team could rebuild their 3D engine from scratch today? That's exactly the idea behind Babylon Lite. Designed exclusively for WebGPU, the new engine is significantly smaller and faster than the original, thanks to a cleaner architecture and the removal of years of legacy compatibility. The trade-off is that some features haven't made the jump yet, but Babylon Lite offers a glimpse of what the next generation of web-based 3D engines could look like.

HYPERBLAM lets you make music with HTML

web-ext 10.5 - A command line tool to help build, run, and test web extensions

WordPalette – Generate a brand palette and visual identity from a word or image

Blur and Unblur Faces – A simple web tool that uses AI to blur or unblur faces in images. It can be useful for privacy protection, content moderation, or creative effects.

eslint-node-test — An ESLint plugin that catches common mistakes and enforces best practices when writing tests with Node.js's built-in node:test runner.

Nub — A TypeScript-first toolchain that runs TypeScript files, package.json scripts, and local CLIs using your existing Node.js installation, with no custom runtime or vendor lock-in.

DepsGuard — A native cross-platform security tool that scans and hardens npm, pnpm, Yarn, Bun, uv, pip, and Poetry configurations to reduce supply chain risks with a single command and zero dependencies.

📚 Libs

tailwindcss-motion - A new animation library for Tailwind CSS that adds more than 20 ready-to-use animations with a simple drop-in setup. Every effect can be previewed, tweaked, and customized directly in the browser, and the project even includes a visual animation builder for creating your own motion presets without writing complex CSS.

Flue - The Open Agent Framework. Build durable AI agents and workflows with Flue's programmable TypeScript harness. Write once, deploy anywhere, use any LLM.

CrustJS — A lightweight, dependency-free CLI framework built specifically for Bun and written with a TypeScript-first approach. It features a fluent builder API, composable modules, and a modern developer experience, making it easy to build fast, maintainable command-line applications without pulling in a large dependency tree.

Gea — A compiler-first UI framework that shifts most of the work to build time instead of runtime. Rather than relying on a virtual DOM, hooks, or signals, Gea analyzes ordinary classes and functions during compilation and generates highly targeted DOM updates. The result is a lightweight runtime with minimal overhead while letting developers write familiar JavaScript and TypeScript code.

eve — A framework for building AI agents with a Next.js-like developer experience, combining Markdown-based instructions, Typ…

Master Docker Swarm with Real Production Examples

Thu, 16 Jul 2026 00:00:00 GMT

Containerization changed how applications are built and deployed. Running a single Docker container on one machine is straightforward, but production systems rarely stay that simple. As applications grow, they need redundancy, automated recovery, rolling deployments, service discovery, and the ability to scale across multiple servers.

Docker Swarm was created to solve exactly these problems.

Unlike many orchestration platforms that introduce an entirely new ecosystem, Swarm extends Docker itself. If you already understand Docker images, containers, and networks, moving to Swarm feels like a natural next step instead of learning an entirely different platform.

This guide explores how Docker Swarm works internally, how its architecture is organized, and why many teams continue to use it for production environments where simplicity is often more valuable than unlimited flexibility.

Why Docker Swarm Exists

A standalone Docker engine works perfectly for local development and small deployments. Everything runs on one machine, networking is simple, and container management is straightforward.

Production infrastructure introduces new challenges.

What happens if the server fails?

How do you distribute traffic between multiple container replicas?

How do you update an application without interrupting users?

How can containers running on different physical servers communicate securely?

Managing all of these concerns manually quickly becomes impractical.

Docker Swarm groups multiple Docker hosts into a single logical cluster. Instead of thinking about individual machines, you manage services that the cluster automatically schedules across available nodes.

The platform handles many operational tasks behind the scenes, including:

scheduling workloads
restarting failed containers
distributing traffic
maintaining the desired number of replicas
rolling out updates safely
recovering from node failures

The result is an orchestration system that feels familiar to anyone already using Docker.

Docker Swarm vs Standalone Docker

A single Docker host and a Swarm cluster share the same Docker engine, but they solve very different problems.

Feature	Standalone Docker	Docker Swarm
Hosts	One machine	Multiple machines
High availability	No	Built in
Service discovery	Manual	Automatic
Load balancing	External tools	Integrated
Scaling	Manual	Automatic
Rolling updates	Manual	Built in
Cluster management	None	Native

Standalone Docker gives you complete control over one server.

Docker Swarm provides centralized management for an entire fleet of Docker hosts.

Where Swarm Fits in the Container Ecosystem

Several orchestration platforms exist today, each with different goals.

Docker Swarm

Docker Swarm focuses on simplicity.

It integrates directly with Docker, requires very little additional tooling, and can often be deployed in minutes. Teams that already use Docker can begin clustering servers with minimal changes to their existing workflows.

Kubernetes

Kubernetes offers significantly more features.

It includes advanced scheduling, custom controllers, autoscaling, extensive networking options, and one of the largest cloud-native ecosystems available today.

The tradeoff is complexity.

Learning Kubernetes requires understanding many new concepts that go far beyond containers themselves.

Nomad

Nomad, developed by HashiCorp, takes a different approach.

It schedules containers alongside virtual machines, binaries, and other workloads while maintaining a relatively small operational footprint.

Many organizations choose Nomad when they need flexibility beyond Docker containers.

Understanding the Swarm Architecture

A Docker Swarm cluster consists of multiple servers working together as one distributed system.

At a high level, every node belongs to one of two categories.

                 Docker Swarm Cluster

         ┌─────────────────────────────┐
         │        Manager Nodes        │
         │                             │
         │  Leader      Followers      │
         └──────────────┬──────────────┘
                        │
        ─────────────────────────────────
           │                       │
     Worker Node             Worker Node
           │                       │
        Containers            Containers

Although every server runs Docker, not every machine performs the same responsibilities.

Understanding these roles is essential before deploying a production cluster.

Manager Nodes

Manager nodes control the cluster.

They maintain the desired state of every service, schedule workloads, monitor cluster health, and coordinate communication between all participating nodes.

Whenever you create or update a service, the request is processed by a manager.

Managers are responsible for:

cluster configuration
scheduling decisions
service updates
node management
certificate distribution
maintaining cluster state

Only managers can change the cluster configuration.

Worker nodes execute tasks but cannot modify the cluster itself.

Leader Election

Manager nodes do not all perform identical work.

One manager becomes the leader.

The leader accepts write operations and coordinates changes throughout the cluster.

Additional managers remain synchronized replicas.

If the leader becomes unavailable, another manager automatically takes over without manual intervention.

This election process is powered by the Raft consensus algorithm.

Why Raft Matters

Distributed systems need agreement.

If multiple managers accepted conflicting updates simultaneously, the cluster would quickly become inconsistent.

Raft solves this problem by ensuring every manager shares the same view of cluster state.

Only one leader processes updates, while followers replicate the resulting state.

For production environments, Docker recommends using an odd number of managers.

Typical configurations include:

3 managers
5 managers
7 managers for very large clusters

Odd numbers prevent split-brain scenarios and maximize fault tolerance.

Worker Nodes

Worker nodes are much simpler.

Their primary responsibility is running containers assigned by managers.

Workers do not participate in scheduling decisions.

Instead, they:

execute tasks
report container status
perform health checks
download required images
communicate results back to managers

This separation keeps the architecture clean.

Managers coordinate.

Workers execute.

Core Components Behind the Scenes

Several internal components work together every time a service is created.

Scheduler

The scheduler determines where workloads should run.

It evaluates:

available CPU
memory
placement rules
node availability
labels
resource reservations

After analyzing the cluster, it selects the most appropriate node for each task.

Howto Use the Decorator Pattern in Front-End Development

Thu, 16 Jul 2026 00:00:00 GMT

The decorator pattern appears throughout modern front-end development, even when developers do not call it by name.

Higher-order functions, React higher-order components, performance wrappers, retry utilities, access-control layers, and memoization helpers all follow a similar principle. They take existing behavior and add something around it without rewriting the original implementation.

React's memo function is a familiar example. It accepts a component and returns an enhanced version that can skip unnecessary renders.

The same approach can be used for API monitoring, retry strategies, permission checks, loading indicators, debouncing, analytics, and error handling.

This article explains the decorator pattern through practical JavaScript and React examples.

The Problem: Business Logic Mixed with Monitoring

Suppose an application needs to measure how long an API request takes.

The most direct solution is to place timing code inside the request function:

async function fetchUsers() {
  const start = performance.now();

  const response = await fetch('/api/users');
  const data = await response.json();

  const duration = performance.now() - start;
  console.log(`Request completed in ${duration.toFixed(2)}ms`);

  return data;
}

The function works, but it now has two responsibilities.

It retrieves users and measures performance.

That may not seem serious when there is only one request. The problem becomes clearer after adding fetchOrders, fetchProducts, fetchInvoices, and several other API functions.

Each function would need similar timing logic. Updating the logging format or changing the monitoring system would require editing every implementation.

This is the kind of duplication the decorator pattern can remove.

Performance tracking is a cross-cutting concern. It affects many parts of an application, but it is not part of the main business operation.

Other common cross-cutting concerns include:

Logging
Analytics
Authentication
Authorization
Caching
Retries
Error reporting
Rate limiting
Debouncing

Instead of placing these behaviors inside every function, decorators keep them in reusable wrappers.

What Is the Decorator Pattern?

The decorator pattern adds new responsibilities to an existing function, object, or component without changing its original source code.

In JavaScript, a decorator is often implemented as a function that accepts another function and returns a new one.

function withExtraBehavior(fn) {
  return function (...args) {
    // Run additional behavior before the original function.

    const result = fn(...args);

    // Run additional behavior after the original function.

    return result;
  };
}

The returned function preserves the original behavior while adding another layer around it.

Front-end applications commonly use two forms of this pattern:

Higher-order functions that decorate ordinary JavaScript functions.
Higher-order components that decorate React components.

Modern React applications often prefer custom Hooks and component composition over higher-order components. However, HOCs remain useful in libraries, route guards, legacy codebases, and reusable component infrastructure.

Decorating Functions with Higher-Order Functions

A higher-order function accepts another function, returns a function, or does both.

This makes higher-order functions a natural way to implement decorators in JavaScript.

Adding Performance Monitoring

The timing logic from the previous example can be extracted into a reusable decorator:

function withPerformance(fn, label = fn.name || 'anonymous') {
  return async function (...args) {
    const start = performance.now();

    try {
      return await fn.apply(this, args);
    } finally {
      const duration = performance.now() - start;

      console.log(
        `[${label}] completed in ${duration.toFixed(2)}ms`,
      );
    }
  };
}

The original API function can now focus only on its main responsibility:

async function fetchUsers() {
  const response = await fetch('/api/users');

  if (!response.ok) {
    throw new Error(`Request failed with status ${response.status}`);
  }

  return response.json();
}

Create a decorated version when performance monitoring is required:

const monitoredFetchUsers = withPerformance(
  fetchUsers,
  'Fetch users',
);

const users = await monitoredFetchUsers();

The decorator runs the original function, measures its execution time, and reports the result.

The finally block ensures that timing information is recorded even when the request fails.

The use of fn.apply(this, args) also preserves the original function's context. This matters when decorating object methods that depend on this.

The original fetchUsers function remains unchanged and can still be used without monitoring.

Adding a Retry Mechanism

Network requests can fail because of temporary connectivity problems, rate limits, overloaded services, or unstable third-party APIs.

Retry logic can also be implemented as a decorator:

function wait(duration) {
  return new Promise((resolve) => {
    setTimeout(resolve, duration);
  });
}

function withRetry(
  fn,
  {
    retries = 3,
    delay = 1000,
    shouldRetry = () => true,
  } = {},
) {
  return async function (...args) {
    let lastError;

    for (let attempt = 0; attempt <= retries; attempt += 1) {
      try {
        return await fn.apply(this, args);
      } catch (error) {
        lastError = error;

        const reachedLastAttempt = attempt === retries;

        if (reachedLastAttempt || !shouldRetry(error)) {
          throw error;
        }

        await wait(delay);
      }
    }

    throw lastError;
  };
}

The request can now gain retry behavior without knowing anything about retry rules:

const resilientFetchUsers = withRetry(fetchUsers, {
  retries: 3,
  delay: 800,
});

const users = await resilientFetchUsers();

The decorator is reusable because it is not tied to fetchUsers.

const resilientFetchOrders = withRetry(fetchOrders, {
  retries: 2,
  delay: 500,
});

const resilientSaveProduct = withRetry(saveProduct, {
  retries: 4,
  delay: 1200,
});

A retry decorator should not automatically repeat every failed operation.

For example, retrying a request after a 401 Unauthorized response is usually pointless. Retrying a payment request may also be dangerous if the endpoint is not idempotent.

The shouldRetry option allows the caller to decide which failures are temporary:

const resilientFetchUsers = withRetry(fetchUsers, {
  retries: 3,
  delay: 1000,
  shouldRetry(error) {
    return error instanceof TypeError;
  },
});

The strategy can later be replaced with exponential backoff without modifying every API function.

function withExponentialRetry(fn, retries = 3) {
  return async function (...args) {
    for (let attempt = 0; attempt <= retries; attempt += 1) {
      try {
        return await fn.apply(this, args);
      } catch (error) {
        if (attempt === retries) {
          throw error;
        }

        const delay = 500 * 2 ** attempt;
        await wait(delay);
      }
    }
  };
}

Centralizing the retry policy makes it easier to test, maintain, and change.

Decorating Functions with Debouncing

Search fi…

JavaScript String Algorithms Every Developer Should Know

Tue, 14 Jul 2026 00:00:00 GMT

String algorithms are among the most common topics in JavaScript interviews.

At first glance, they seem straightforward. Reverse a string, check whether it's a palindrome, or remove a character. None of these problems look particularly difficult.

However, these exercises teach much more than simple string manipulation. They reveal how well you understand JavaScript fundamentals, immutable data structures, algorithmic thinking, and time and space complexity.

In this article, we'll explore three classic interview questions:

Reversing a string
Checking whether a string is a palindrome
Determining whether removing at most one character can produce a palindrome

Along the way, you'll also learn why the two-pointer technique is one of the most valuable patterns in algorithm design.

Reversing a String

The classic problem is simple.

Given:

"abc"

Return:

"cba"

Unlike arrays, JavaScript strings don't have a built-in reverse() method.

This doesn't work:

const str = "abc";

// TypeError
str.reverse();

Instead, the standard solution converts the string into an array.

const str = "abc";

const reversed = str
  .split("")
  .reverse()
  .join("");

console.log(reversed); // "cba"

The process consists of three steps:

split("") converts the string into an array.
reverse() reverses the array.
join("") combines everything back into a string.

This solution is clean, easy to read, and runs in O(n) time.

Its space complexity is also O(n) because a new array is created.

Why Does a String Have `.length`?

JavaScript strings are primitive values.

typeof "hello";
// "string"

Yet they still behave like objects.

const str = "hello";

console.log(str.length);
console.log(str[0]);

How is that possible?

Whenever you access a property or method on a primitive string, JavaScript temporarily wraps it in a String object behind the scenes.

Conceptually, it's similar to this:

const temp = new String("hello");

temp.length;

The wrapper object exists only for the duration of the operation before being discarded.

This behavior lets primitive values expose useful methods while remaining lightweight.

Understanding `call()` and `this`

Another interview favorite involves Function.prototype.call().

Consider this example.

const person = {
  name: "Alice",

  say() {
    console.log(this.name);
  },
};

const anotherPerson = {
  name: "Bob",
};

person.say();

person.say.call(anotherPerson);

The first call prints:

Alice

The second prints:

Bob

call() doesn't copy the function.

It simply changes what this refers to during execution.

This same mechanism powers one of JavaScript's most reliable type-checking techniques.

Object.prototype.toString.call([]);

Result:

[object Array]

Because toString() executes with a different this, it can inspect many different object types.

Checking for a Palindrome

A palindrome reads the same in both directions.

Examples include:

level
racecar
abba

The simplest solution reverses the string and compares it with the original.

function isPalindrome(str) {
  return str ===
    str
      .split("")
      .reverse()
      .join("");
}

Although easy to understand, this approach creates another string and requires extra memory.

The Better Solution: Two Pointers

A palindrome is symmetrical.

Instead of reversing the entire string, compare characters from both ends.

function isPalindrome(str) {
  let left = 0;
  let right = str.length - 1;

  while (left < right) {
    if (str[left] !== str[right]) {
      return false;
    }

    left++;
    right--;
  }

  return true;
}

This solution still runs in O(n) time.

However, it only uses O(1) extra memory because no additional arrays or strings are created.

The two-pointer technique appears in countless interview questions involving:

symmetric data
sorted arrays
substrings
intervals
partitioning

Learning it early pays off repeatedly.

Remove One Character to Form a Palindrome

Now let's make the problem slightly harder.

Given a string, determine whether removing at most one character makes it a palindrome.

Examples:

"aba"  → true

"abca" → true

"abc"  → false

The two-pointer approach still works.

Whenever the left and right characters match, continue toward the center.

If they don't match, only two possibilities remain.

Skip the left character.

Or skip the right one.

function validPalindrome(str) {

  function isPalindrome(left, right) {

    while (left < right) {

      if (str[left] !== str[right]) {
        return false;
      }

      left++;
      right--;
    }

    return true;
  }

  let left = 0;
  let right = str.length - 1;

  while (left < right) {

    if (str[left] !== str[right]) {

      return (
        isPalindrome(left + 1, right) ||
        isPalindrome(left, right - 1)
      );
    }

    left++;
    right--;
  }

  return true;
}

The helper function lets us verify both possibilities without duplicating code.

Why Only Two Cases?

Suppose these two characters don't match.

... x ........ y ...
    ↑          ↑
   left      right

If removing one character can solve the problem, then one of these mismatched characters must disappear.

Removing any other character won't fix the current mismatch.

Therefore, we only need to test:

isPalindrome(left + 1, right);

isPalindrome(left, right - 1);

Nothing else needs to be checked.

That's why the algorithm remains linear instead of becoming quadratic.

Complexity Analysis

Reverse String

Time: O(n)
Space: O(n)

Palindrome (Two Pointers)

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

Remove One Character

Although an additional palindrome check may occur after finding a mismatch, every character is still visited only a constant number of times.

The complexity remains:

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

Good Habits When Solving String Problems

As you practice more interview questions, several patterns emerge.

Remember that strings are immutable.

Most operations create new strings rather than modifying existing ones.

Prefer two pointers whenever possible.

They're often faster and require less memory than repeatedly creating arrays or substrings.

Extract reusable logic.

Small helper functions usually make algorithms easier to understand and easier to test.

Always think about edge cases.

Test your solution with:

empty strings

single-character strings

Observer vs Publish-Subscribe: What's the Difference?

Tue, 14 Jul 2026 00:00:00 GMT

If you've been building frontend applications for a while, you've probably encountered both the Observer pattern and the Publish-Subscribe (Pub/Sub) pattern.

They often look almost identical. Both involve listeners, callbacks, and notifications. Both allow multiple parts of an application to react when something changes.

Because of these similarities, developers frequently use the names interchangeably. In reality, they solve different problems and lead to different application architectures.

Understanding where they differ helps you design applications that are easier to scale, test, and maintain.

Let's compare both patterns using the same real-world example.

A Common Frontend Scenario

Imagine you're building a real-time stock dashboard.

A WebSocket connection continuously receives market updates.

Several independent parts of the application need those updates:

a price chart
a watchlist
a notification panel
an activity log

The WebSocket should not care who consumes the data. It simply receives new market information.

There are two common ways to distribute those updates.

Option 1: The Observer Pattern

With the Observer pattern, the subject directly keeps track of every observer.

Whenever new data arrives, it loops through every registered observer and calls them one by one.

class Subject {
  #observers = new Set();

  subscribe(observer) {
    this.#observers.add(observer);
    return () => this.#observers.delete(observer);
  }

  notify(payload) {
    this.#observers.forEach(observer => observer(payload));
  }
}

Usage is straightforward.

const ticker = new Subject();

const drawChart = (tick) => {};
const flashRow = (tick) => {};
const logTick = (tick) => {};

ticker.subscribe(drawChart);
ticker.subscribe(flashRow);
ticker.subscribe(logTick);

socket.addEventListener("message", event => {
  ticker.notify(JSON.parse(event.data));
});

Here, the ticker object knows every consumer.

Whenever new market data arrives, it actively notifies each observer.

Characteristics

The subject owns the list of observers.
Every observer receives every update.
Consumers are directly connected to the data source.
Adding a new observer only requires calling subscribe().

This creates a clear one-to-many relationship between a single source of truth and its consumers.

Option 2: Publish-Subscribe

The Publish-Subscribe pattern introduces an intermediary.

Instead of sending updates directly to consumers, publishers emit events into an event bus.

Subscribers simply listen for the events they care about.

class EventBus {
  #events = {};

  on(event, callback) {
    (this.#events[event] ||= []).push(callback);
    return () => this.off(event, callback);
  }

  off(event, callback) {
    this.#events[event] =
      this.#events[event]?.filter(cb => cb !== callback);
  }

  emit(event, ...args) {
    this.#events[event]?.forEach(cb => cb(...args));
  }
}

Using the event bus looks very similar.

const bus = new EventBus();

bus.on("tick", drawChart);
bus.on("tick", flashRow);
bus.on("tick", logTick);

socket.addEventListener("message", event => {
  bus.emit("tick", JSON.parse(event.data));
});

The important difference is that the WebSocket never communicates with the consumers directly.

It only emits an event.

The event bus decides who receives it.

The Key Difference

At first glance, both implementations produce the same result.

The architecture, however, is completely different.

Observer

WebSocket
      │
      ▼
   Subject
      │
 ┌────┼────┐
 ▼    ▼    ▼
Chart List Logger

The subject knows every observer.

Communication is direct.

Publish-Subscribe

WebSocket
      │
      ▼
  Event Bus
      │
 ┌────┼────┐
 ▼    ▼    ▼
Chart List Logger

Neither the publisher nor the subscribers know about each other.

The event bus sits between them.

This extra layer creates much looser coupling.

Where You'll Find the Observer Pattern

Many frontend APIs are built around Observer semantics.

React State Subscriptions

React doesn't implement the classic Observer pattern internally in the same way as Vue, but the pattern appears throughout the React ecosystem.

When a component subscribes to an external store, it automatically re-renders whenever the relevant state changes. Libraries like Redux, Zustand, MobX, Jotai, and React's own useSyncExternalStore API all rely on this idea.

Each store maintains a list of subscribers. When the state changes, it notifies those subscribers, allowing React to update only the components that depend on the changed data.

The relationship is still the same: a single source of state owns its subscribers and informs them whenever its data changes.

Browser Observer APIs

Modern browsers also provide several observer-based APIs.

Examples include:

IntersectionObserver
MutationObserver
ResizeObserver

Each watches a specific target and triggers callbacks whenever that target changes.

Again, the observed object directly manages its observers.

State Management Libraries

Several state management solutions also follow Observer principles.

Examples include:

MobX
Signals
SolidJS reactivity
Angular Signals

All of them maintain explicit relationships between observable state and dependent computations.

Where Publish-Subscribe Shines

Pub/Sub becomes much more useful when modules should remain independent.

A publisher shouldn't know who is listening.

A subscriber shouldn't know who produced the event.

Cross-Component Communication

Lightweight event buses are common in both React and Vue applications.

One popular choice is mitt.

import mitt from "mitt";

type Events = {
  "user-login": {
    userId: string;
    name: string;
  };
};

export const eventBus = mitt<Events>();

Publishing an event:

eventBus.emit("user-login", {
  userId: user.id,
  name: user.name,
});

Listening for it:

useEffect(() => {
  const handler = data => setUser(data);

  eventBus.on("user-login", handler);

  return () => {
    eventBus.off("user-login", handler);
  };
}, []);

The login component doesn't know who reacts to the event.

The navigation bar doesn't know where the event originated.

Both only communicate through the event bus.

Micro-Frontends

Micro-frontend architectures frequently use Pub/Sub.

Independent applications often communicate through shared event buses rather than importing each other's code directly.

This keeps teams independent while allowing applications to exchange information.

Custom Events

The browser's own CustomEvent system is another example of Publish-Subscribe.

Components dispatch events.

Other components listen for them.

Neither side depends on the other.

A Common Mistake: Forgetting to Unsubscribe

Both patterns rely on callbacks.

That means both can create memory leaks.

If callbacks remain registered after a component has been destroyed, the JavaScript gar…

How to Protect HTML Content from Being Copied

Tue, 14 Jul 2026 00:00:00 GMT

Every few months, someone asks the same question:

"How can I stop users from copying my website?"

The short answer is simple.

You can't.

If a browser can display your content, a user can eventually copy it.

The only thing frontend code can do is increase the effort required.

Whether that's enough depends on who you're trying to stop. Casual visitors, curious developers, and professional scrapers all require very different levels of protection.

Understanding this difference is the key to choosing the right approach.

The Fundamental Problem

Every anti-copy solution starts with the same limitation.

Before a browser can display text, it has to download and render that content.

Once users can see it, they have multiple ways to extract it.

They can:

copy the text
inspect the HTML
capture a screenshot
run OCR on the screenshot
use browser extensions
automate the browser with scripts

As long as people can read the content, there will always be a way to obtain it.

That means anti-copy techniques don't answer the question:

Can users copy this?

Instead they answer:

How difficult is it to copy?

Level 1: CSS Protection

The simplest approach disables text selection.

.protected {
  user-select: none;
  -webkit-user-select: none;
}

Users can't highlight text, which also prevents the usual Ctrl+C workflow.

This is probably the most common anti-copy technique on the web.

How easy is it to bypass?

Very easy.

Open DevTools and remove the CSS rule.

Or simply execute:

document.querySelector(".protected")
  .style.userSelect = "text";

Text selection immediately works again.

Disable the Context Menu

Another popular trick blocks the right-click menu.

document.addEventListener(
  "contextmenu",
  event => event.preventDefault()
);

Without the context menu, users lose quick access to Copy.

Unfortunately, they also lose:

Translate
Inspect
Dictionary lookup
Accessibility tools
Browser extensions

The downside often outweighs the protection.

Most browsers also allow users to disable websites from blocking the context menu.

Level 2: JavaScript Event Blocking

Instead of preventing selection, JavaScript can intercept the copy operation itself.

document.addEventListener(
  "copy",
  event => {
    event.preventDefault();
  }
);

Pressing Ctrl+C no longer places anything on the clipboard.

This is slightly stronger than CSS.

It is still easy to bypass.

A developer can register another event listener before yours or simply disable JavaScript entirely.

Invisible Overlay Layers

Some websites place a transparent element above the content.

.overlay {
  position: absolute;
  inset: 0;
  z-index: 999;
}

Users interact with the overlay instead of the text underneath.

Again, DevTools defeats the technique almost instantly.

Deleting the overlay or changing pointer-events restores normal interaction.

Level 3: Allow Copying, but Modify It

Instead of fighting the user, many large websites take a different approach.

They allow copying.

They simply modify what gets copied.

document.addEventListener(
  "copy",
  event => {

    event.preventDefault();

    const text =
      window.getSelection().toString();

    event.clipboardData.setData(
      "text/plain",
      text +
      "\n\nSource: example.com"
    );
  }
);

Users still get their selected text.

However, every paste now includes a source attribution.

This strategy has become popular because it preserves usability while encouraging proper attribution.

It's far less frustrating than disabling copying altogether.

Level 4: Don't Store Text as Text

Eventually developers realize that every DOM node can be inspected.

The next idea is simple.

Don't place text inside the DOM.

Render Everything with Canvas

Instead of HTML, draw text directly onto a <canvas>.

const ctx =
  canvas.getContext("2d");

ctx.font = "16px sans-serif";

ctx.fillText(
  "Confidential",
  20,
  40
);

Users see readable content.

The HTML contains almost nothing.

Traditional scrapers receive an empty page.

There are serious trade-offs.

Search engines cannot index the content.

Screen readers lose access.

Rendering becomes more expensive.

Responsive layouts become harder.

Attackers can still use OCR or intercept drawing commands.

Font Obfuscation

One of the strongest frontend techniques uses custom fonts.

The HTML stores meaningless characters.

The font maps those characters to completely different glyphs.

For example:

HTML:
xk#2m

Displayed:
hello

When users copy the text, they receive the original encoded characters instead of what appeared on screen.

This technique is commonly used by premium document platforms and online reading services.

It is significantly harder to bypass.

However, it still isn't impossible.

A determined attacker can analyze the font mapping or simply rely on OCR.

Choose Protection Based on the Threat

Not every website needs military-grade protection.

Think about who you're trying to stop.

Casual visitors

Simple CSS and basic JavaScript usually discourage accidental copying.

Developers

Browser DevTools bypass nearly every client-side protection within seconds.

Professional scrapers

Automation tools combined with OCR can eventually extract almost any visible content.

The difference is time.

The stronger your protection, the longer extraction takes.

Don't Sacrifice User Experience

Many anti-copy techniques create bigger problems than they solve.

Blocking selection prevents users from quoting your articles.

Disabling right-click breaks browser features people rely on every day.

Rendering everything inside Canvas hurts SEO and accessibility.

Before adding protection, ask yourself an important question.

Are you trying to stop content theft, or are you making your own website harder to use?

In many cases, adding attribution to copied text provides a better balance than preventing copying entirely.

Which Technique Should You Choose?

For most websites, a layered approach works best.

Start with lightweight protection.

Add clipboard attribution.

Avoid techniques that harm accessibility or search indexing unless your content genuinely requires stronger protection.

If you're publishing premium documents or paid educational material, Canvas rendering or font obfuscation may provide additional resistance.

Just remember that these techniques delay copying.

They don't eliminate it.

Final Thoughts

The perfect anti-copy solution doesn't exist.

Every piece of content displayed in a browser can eventually be extracted.

The goal is not to build an unbreakable system.

The goal is to raise the cost of copying high enough that casual users stop trying while legitimate visitors continue enjoying a …

Howto Replace if-Else with the Strategy Pattern

Tue, 14 Jul 2026 00:00:00 GMT

How to Use the Strategy Pattern in JavaScript

Every frontend developer has written a function that started with one if statement and slowly turned into twenty.

It usually begins with something harmless.

You need to validate an email.

Then someone asks for phone number validation.

Next comes passwords, usernames, ZIP codes, country-specific rules, feature flags, and suddenly one function contains the business logic for half the application.

The code still works, but every new requirement makes it harder to read, test, and maintain.

The Strategy Pattern offers a much cleaner solution.

Instead of expanding one giant conditional statement, you split each behavior into an independent strategy and choose the correct one at runtime.

The Problem with Large if-Else Chains

Imagine you're building a user registration form.

A common implementation looks something like this.

function validate(value, type) {
  if (type === "email") {
    return /\S+@\S+\.\S+/.test(value)
      ? ""
      : "Invalid email address";
  }

  if (type === "phone") {
    return /^\+?[1-9]\d{7,14}$/.test(value)
      ? ""
      : "Invalid phone number";
  }

  if (type === "password") {
    return value.length >= 8
      ? ""
      : "Password is too short";
  }

  return "";
}

The implementation works.

The problem is scalability.

Every new validation rule requires modifying the same function.

Soon dozens of unrelated conditions become tightly coupled, making even small changes risky.

What Is the Strategy Pattern?

The Strategy Pattern encapsulates multiple algorithms behind a common interface.

Instead of asking a function to decide how something should happen, you provide the behavior you want to execute.

Rather than writing:

if this...
else if that...
else...

you write:

Select strategy
↓

Execute strategy

Each strategy becomes a small, reusable function with a single responsibility.

Refactoring Validation

Instead of putting every rule inside one function, separate them into individual validators.

const validators = {
  required: value =>
    value.trim()
      ? ""
      : "This field is required",

  email: value =>
    /^\S+@\S+\.\S+$/.test(value)
      ? ""
      : "Invalid email address",

  phone: value =>
    /^\+?[1-9]\d{7,14}$/.test(value)
      ? ""
      : "Invalid phone number",

  minLength: length =>
    value =>
      value.length >= length
        ? ""
        : `Minimum ${length} characters`,
};

Now the validation engine becomes extremely small.

function validate(value, rules) {

  for (const rule of rules) {

    const strategy =
      typeof rule === "function"
        ? rule
        : validators[rule];

    const error = strategy(value);

    if (error) {
      return error;
    }
  }

  return "";
}

Using it is straightforward.

validate(
  "john@example.com",
  ["required", "email"]
);

validate(
  "abc",
  [
    "required",
    validators.minLength(8),
  ]
);

Notice what changed.

Adding a new validation rule never requires touching the validation engine.

You simply register another strategy.

This follows one of the core principles of good software design:

Open for extension, closed for modification.

React Integration

This approach works naturally with modern React form libraries.

For example:

<Form.Item
  name="email"
  rules={[
    {
      validator: (_, value) =>
        validators.email(value),
    },
  ]}
>
  <Input />
</Form.Item>

The form doesn't care how email validation works.

It simply executes the selected strategy.

The same validators can also be reused in APIs, custom hooks, or server-side validation.

Strategy Pattern for Status Mapping

Validation isn't the only place where developers overuse conditional logic.

Status mapping is another common example.

Many applications receive numeric status codes from an API.

Instead of writing multiple conditional statements throughout the UI, create a configuration object.

const ORDER_STATUS = {

  pending: {
    label: "Pending",
    color: "orange",
  },

  paid: {
    label: "Paid",
    color: "green",
  },

  cancelled: {
    label: "Cancelled",
    color: "gray",
  },
};

Now rendering becomes much simpler.

const status =
  ORDER_STATUS[order.status];

<Tag color={status.color}>
  {status.label}
</Tag>

Adding a new status becomes a single-line change.

No rendering logic needs to be modified.

This pattern also works well for:

user roles
notification types
feature flags
payment states
API response codes

Environment-Specific Behavior

Different environments often require completely different implementations.

During development you may want verbose console logging.

Production applications usually send errors to monitoring services instead.

Instead of adding environment checks everywhere, provide different strategies.

// devLogger.ts

export const logger = {
  error: console.error,
  warn: console.warn,
};

// productionLogger.ts

export const logger = {
  error(message, extra) {
    Sentry.captureMessage(
      message,
      { extra }
    );
  },

  warn() {},
};

Then load the appropriate implementation.

const logger = await import(
  `./loggers/${import.meta.env.MODE}.ts`
);

logger.error("Something failed");

Modern bundlers can tree-shake unused implementations, keeping production bundles smaller.

Other Great Use Cases

Once you start looking for them, Strategy Pattern opportunities appear everywhere.

Formatting values:

Date formatter
Currency formatter
File size formatter
Percentage formatter

Authentication:

Password login
OAuth
Magic links
Passkeys

Payments:

Stripe
PayPal
Square
Adyen

Search algorithms:

Exact match
Fuzzy search
Full-text search
Semantic search

Instead of branching through multiple implementations, choose the appropriate strategy.

Benefits

Using the Strategy Pattern provides several advantages.

Smaller functions

Each strategy has one responsibility.

Better testing

Strategies can be tested independently.

Easy extension

Adding new behavior doesn't require modifying existing logic.

Reusable code

The same strategies can be shared across multiple features.

Cleaner architecture

Business logic becomes separated from decision-making logic.

When Not to Use It

Not every if statement should become a strategy.

If you only have two simple conditions that are unlikely to grow, introducing extra abstraction may make the code harder to understand.

The Strategy Pattern shines when:

new behaviors are added regularly
multiple implementations share the same interface
business rules change frequently
different environments require different behavior

Otherwise, a simple conditional may be perfectly acceptable.

Final Thoughts

The Strategy Pattern is one of the most practical design patterns in frontend develop…

10 Claude Code Settings That Made Me a Faster Software Architect

Fri, 03 Jul 2026 00:00:00 GMT

Like most developers, I started by accepting the defaults. They worked well enough, and Claude quickly became part of my daily workflow. But over time I noticed a pattern: the mistakes weren't random. They repeated themselves.

The agent would occasionally forget project conventions, lose important context halfway through a long session, or confidently refactor code that didn't need changing. None of these issues were catastrophic, but together they added up to hours of unnecessary review, corrections, and backtracking every month.

Instead of blaming the model, I started treating Claude Code like any other engineering tool: something that benefits from configuration.

After months of experimentation, I ended up with ten changes that noticeably improved both speed and reliability. Some came from the documentation, while others only emerged after making plenty of mistakes in real projects.

This isn't a beginner's guide to Claude Code.

It's a collection of workflows, configuration patterns, and practical guardrails for developers who already use the tool and want to get more consistent results.

Each section includes configuration examples you can copy directly into your own project.

1. Keep `CLAUDE.md` Small

One of the biggest mistakes I made during my first few months was turning CLAUDE.md into an encyclopedia.

At one point the file had grown to nearly 40,000 characters.

It contained architecture decisions, coding conventions, testing rules, domain knowledge, onboarding notes, deployment instructions, prompt templates, API contracts, and even project history.

My assumption seemed reasonable:

More context should produce better answers.

It didn't.

The Attention Problem

Large language models don't treat every part of a long document equally.

As the file grew, Claude became increasingly likely to overlook information buried in the middle. Important architectural rules that had worked perfectly before suddenly started disappearing from its reasoning.

This wasn't subtle.

I actually tested it by asking Claude to repeat a rule located around line 300 of my own CLAUDE.md.

It couldn't find it.

After repeating the experiment several times, the pattern became obvious: the longer the document became, the less reliable its middle sections were during extended conversations.

My Rule: 8,000 Characters Maximum

Today I treat CLAUDE.md as permanent session context.

Only information that should appear in every single conversation belongs there:

technology stack
coding principles
architectural constraints
project-wide rules
links to additional documentation

Everything else lives elsewhere.

My project now looks like this:

.claude/
├── CLAUDE.md              # Always loaded (<8 KB)
├── skills/
│   ├── nestjs.md
│   ├── migrations.md
│   ├── review.md
│   └── testing.md
└── specs/
    ├── domain-model.md
    ├── api-contracts.md
    └── infrastructure.md

Instead of trying to keep every possible detail loaded all the time, I organize information into focused documents that Claude only reads when they're actually relevant.

Think of it as lazy loading for project knowledge.

The Results

After restructuring everything:

CLAUDE.md shrank from roughly 40K to 6K characters.
Session initialization became noticeably cheaper.
Token usage dropped by roughly 35%.
Claude stopped "forgetting" rules buried in the middle of giant documents.
Responses became more consistent during long development sessions.

This single change produced a bigger improvement than any prompt engineering trick I experimented with.

Sometimes better AI results don't come from writing better prompts.

They come from giving the model less—but better organized—context.

2. Three `settings.json` Tweaks That Changed My Workflow

Most developers never open .claude/settings.json.

The default configuration is good enough to get started, so it's easy to ignore. But after a month of daily usage, I realized that a few small changes dramatically improved the experience.

These are the three settings that had the biggest impact.

Allow Safe Commands Automatically

The first change was removing unnecessary confirmation prompts.

Claude spends much of its time reading files, checking Git history, running tests, or searching through the project. None of these operations are destructive, yet by default they often require confirmation.

I allow read-only operations and verification commands to run automatically while keeping anything destructive behind manual approval.

{
  "permissions": {
    "allow": [
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git status:*)",
      "Bash(git show:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run typecheck:*)",
      "Bash(cat:*)",
      "Bash(grep:*)",
      "Bash(find:*)"
    ],
    "deny": [
      "Bash(git push:*)",
      "Bash(git reset --hard:*)",
      "Bash(rm -rf:*)"
    ]
  }
}

The difference was immediate.

Instead of approving fifteen or twenty harmless operations during a session, I now approve only the actions that could actually change something important.

Development feels much more like pair programming than remote controlling an assistant.

Log Every Session Automatically

The second improvement was surprisingly simple.

I added a Stop hook that records every completed Claude session.

{
  "hooks": {
    "Stop": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "echo \"$(date '+%Y-%m-%d %H:%M') session ended\" >> ~/.claude/log.txt"
      }]
    }]
  }
}

At first I expected this to be little more than curiosity.

Instead, it gave me real data.

I discovered I was spending more than two hours every day working with Claude Code across four or five separate sessions. Before measuring it, I would have guessed less than half that amount.

You can't optimize what you never measure.

Block Obviously Dangerous Commands

Finally, I explicitly deny commands that should never execute accidentally.

{
  "permissions": {
    "deny": [
      "Bash(drop table:*)",
      "Bash(truncate:*)",
      "Bash(delete from * where 1:*)"
    ]
  }
}

These rules don't replace good engineering practices.

They simply provide another layer of protection against expensive mistakes.

The entire configuration lives inside the repository, so every developer on the team benefits from the same safety rails instead of relying on individual habits.

3. Don't Enable `acceptEdits` Everywhere

One of Claude Code's most tempting features is acceptEdits.

It removes confirmation dialogs before file modifications, making the agent feel dramatically faster.

The first time you enable it, you'll probably wonder why it isn't always on.

After six months of using it, my answer is simple:

Because it shouldn't be.

Where It Works Well

I enable acceptEdits for tasks that are predictable and easy to verify automatically.

For example:

migrating JavaScript to TypeScript
replacing any types
renaming files or symbols
updating imports
formatting code
ge…

Friday Links #40 — JavaScript News, New Libraries & AI Tools

Fri, 03 Jul 2026 00:00:00 GMT

Welcome to Friday Links #40.

Another busy week brought new JavaScript releases, React improvements, AI-powered developer tools, open-source projects, performance techniques, and plenty of interesting discussions across the web.

As always, we've filtered out the noise and collected only the links that are actually worth your time. Whether you're building React applications, working with Node.js, experimenting with AI coding assistants, or simply trying to stay current with the modern web ecosystem, this week's roundup has something useful for you.

Grab a coffee and enjoy the reading.

📜 Articles & Tutorials

A former Microsoft engineer has rebuilt Notepad, and it's 2.5KB in size and has zero AI bloat

The Goldilocks customizable select height

Different hydration and rendering strategies

Introducing the <usermedia> HTML element

The Shifting Line Between CSS States and JavaScript Events

Experimenting with random() in CSS

An animated radial gradient mask over text in CSS

WebGL without a GPU

Grid algorithm adventures

Actions steps can now be run in parallel

Announcing Genkit Agents: A full-stack foundation for conversational AI

VSCode - Iterating faster with TypeScript 7

How to Read Large JSON Files Without Losing Your Mind

⚒️ Tools

JSON Formatter - A simple and fast JSON formatter and validator for developers. It can format, validate, and beautify JSON data in a user-friendly interface.

JSON Handbook

Recall - fully-local project memory for Claude Code

Orca - is the ADE for working with a fleet of parallel agents. Run any coding agent with your own subscription. Available on desktop and mobile.

Infographic - An Infographic Generation and Rendering Framework, bring words to life with AI!

Drawbridge - Design editor for Claude Code and Cursor. "Figma Comments" for the browser, are sent directly to Claude Code and Cursor as prompts.

Claude HUD - A Claude Code plugin that shows what's happening — context usage, active tools, running agents, and todo progress. Always visible below your input.

Lore - Lore is a next-generation, open source version control system

📚 Libs

DaloyJS - The secure TypeScript API framework that runs anywhere

pdfme - Open-source PDF generation library built with TypeScript and React. Features a WYSIWYG template designer, PDF viewer, and powerful generation capabilities.

hiraki - A zero-dependency React drawer component. All 4 directions, velocity-aware gestures, snap points, 6 variants, and a pure CSS animation system without Radix, Framer Motion, or any external runtime dependencies.

Gridland - Terminal apps that run anywhere - even the browser!

rari - High-performance React Server Components framework powered by a Rust runtime, delivering 18.1x faster response times (0.12ms vs 2.17ms) and 67.4x higher throughput (97,826 vs 1,452 req/sec) than Next.js with zero-config setup.

Mantic.sh - A structural code search engine for Al agents.

ArtPlayer - ArtPlayer.js is a modern and full featured HTML5 video player

<qr-code> - Web Component for generating QR Codes

whatwg-url - An implementation of the WHATWG URL Standard in JavaScript

⌚ Releases

Astro 7.0 Released

Astro 7 is the biggest release since Astro 5, with a strong focus on build performance and AI-powered workflows. The framework now ships with Vite 8, a brand-new Rust-based .astro compiler, Rust-powered Markdown/MDX processing, queued rendering, and stable route caching. The Astro team reports 15–61% faster builds, with some large documentation sites building more than twice as fast. Astro 7 also introduces Advanced Routing, astro dev --background for AI coding agents, and structured JSON logging.

Announcing Angular v22

Intelligent Terminal 0.1.1 is here: bash support, new slash commands, and more customization

Vite 8.1 is out!

Node.js 26.4.0 (Current)

Announcing Rspack 2.1

React Hook Form v7.80, React Native v0.86, Motion v12.40, Electron 43, Next.js 16.3: Instant Navigations, React-Router 8.1

Announcing Rspack 2.1, nuqs 2.9, RedwoodSDK 1.5, Prettier 3.9, Deno 2.9, Webpack 5.108, ESLint v10.6.0 released

Highlights from Git 2.55

📺 Videos

NestJS Full Course for Beginners in 2026 | Build a Production-Ready API

Modern UI…

Docker Explained: A Practical Guide to Containers for Developers

Thu, 02 Jul 2026 00:00:00 GMT

Why Docker Exists

Introduction

Docker has become one of those technologies that almost every developer eventually encounters. Whether you're building a small side project, deploying a production API, or preparing for a DevOps interview, Docker is everywhere.

Yet many developers use it every day without fully understanding why it exists.

You have probably seen commands like:

docker build
docker run
docker compose up

and perhaps even copied a Dockerfile from another repository without thinking much about what happens behind the scenes.

That works—for a while.

Sooner or later, however, you'll run into questions like:

Why does my application work on my machine but fail in production?
Why is this Docker image 3 GB?
Why does every build take several minutes?
Why did updating a base image suddenly break my application?
What exactly is the difference between an image and a container?

This guide answers those questions from first principles.

Rather than memorizing commands, you'll learn how Docker actually works, why its design solves real engineering problems, and how experienced developers structure their containerized applications.

By the end of this guide you'll understand:

why containers became the industry standard
what Docker actually does
how images are built
how containers run
how isolation works
how to write cleaner Dockerfiles
how to avoid common beginner mistakes

Why Docker Was Created

Before Docker became mainstream, deploying software was surprisingly fragile.

Imagine a simple Python web application.

It depends on:

Python 3.11
PostgreSQL
Redis
several third-party libraries
operating system packages
environment variables
configuration files

Everything works perfectly on your laptop.

Then you send the project to a teammate.

Five minutes later they message you:

"It doesn't work."

Nothing changed in your code.

Yet somehow everything is broken.

This situation became so common that developers jokingly called it:

"Works on my machine."

The problem wasn't the application.

The problem was the environment.

Different computers had:

different operating systems
different package versions
different runtime versions
different system libraries
different configurations

Even reinstalling your own project six months later could produce completely different results.

Docker was designed to eliminate this entire category of problems.

One Application, One Environment

Instead of installing everything directly onto the operating system, Docker packages an application together with everything it needs to run.

That package is called an image.

An image contains:

your application
the runtime
installed dependencies
configuration
operating system libraries
startup commands

Everything is bundled into a predictable environment.

If the image contains Python 3.11, Docker will always use Python 3.11.

If it contains Node.js 22, every container created from that image will use Node.js 22.

It doesn't matter whether the image runs on:

your laptop
a teammate's computer
GitHub Actions
AWS
DigitalOcean
a Kubernetes cluster

The environment remains identical.

That's Docker's biggest promise:

Build once. Run anywhere.

Stability Through Reproducibility

Modern software changes constantly.

Package managers receive updates.

Operating systems evolve.

Libraries introduce breaking changes.

Configuration defaults change.

Without isolation, even a small system update can unexpectedly break a working application.

Docker avoids this by freezing the execution environment inside an image.

Instead of relying on whatever happens to be installed on the host machine, every container starts from the exact same filesystem and dependency versions every time.

This makes deployments reproducible.

If version 1.2.0 of your application worked yesterday, it will continue to work next month—as long as you're running the same image.

For teams, this dramatically reduces debugging time because everyone is running the same environment.

Isolation: Keeping Applications Out of Each Other's Way

Stability is only half of Docker's value.

The other half is isolation.

Imagine a server hosting several applications.

One service requires:

Python 3.9

Another requires:

Python 3.12

A third depends on:

PostgreSQL 14

Another expects:

PostgreSQL 16

Installing everything directly on one operating system quickly becomes difficult.

Different versions overwrite one another.

Configuration files collide.

Library updates break unrelated services.

Docker solves this by giving every application its own isolated environment.

Each container has its own:

filesystem
processes
network interfaces
installed libraries
environment variables

Containers don't interfere with one another.

You can run multiple versions of the same runtime side by side without conflicts.

This isolation makes Docker particularly useful for:

microservices
CI/CD pipelines
development environments
testing multiple software versions
self-hosted infrastructure

Resource Limits

Isolation isn't just about software.

Docker can also isolate hardware resources.

A container can be limited to:

a fixed amount of RAM
a specific number of CPU cores
storage quotas
process limits

For example, a logging service can be restricted to 512 MB of memory, while a database receives several gigabytes.

If one container starts consuming excessive resources, Docker prevents it from affecting the rest of the system.

Instead of allowing a single runaway application to crash an entire server, each workload stays within its assigned limits.

This is one of the reasons Docker has become such a common foundation for modern cloud infrastructure.

Why Developers Love Docker

After understanding these ideas, Docker becomes much easier to appreciate.

Its popularity isn't about learning new commands.

It's about solving real engineering problems.

Docker gives developers:

predictable environments
repeatable deployments
isolated applications
easier collaboration
safer experimentation
simpler onboarding
cleaner production servers

Once you've experienced working in fully reproducible environments, it's surprisingly difficult to go back to manually configuring applications on every machine.

Docker Terminology Every Developer Should Know

Before writing your first Dockerfile or running your first container, it's important to understand Docker's vocabulary. Many beginners struggle not because Docker is difficult, but because its documentation assumes you already know what terms like image, c…

Modern CSS Features That Replace Old Tricks

Mon, 29 Jun 2026 00:00:00 GMT

CSS has changed more in the last few years than it did during the previous decade.

Many patterns that developers once considered "best practice" were actually workarounds for missing browser features. We relied on JavaScript to compensate for layout problems, added unnecessary wrappers, and wrote dozens of lines of CSS just to accomplish relatively simple tasks.

Today, most of those hacks are no longer necessary.

Modern browsers support a collection of new CSS features that make code shorter, more readable, and easier to maintain. If your stylesheets still contain old patterns copied from projects built five or ten years ago, chances are you can simplify them considerably.

Let's look at several CSS features that deserve a permanent place in every modern codebase.

1. Stop Fixing Layout Shifts with JavaScript

One of the oldest UI problems appears whenever a modal dialog opens.

The browser removes the scrollbar after overflow: hidden is applied to the page, causing the entire layout to jump horizontally.

For years developers compensated by manually calculating the scrollbar width.

body.modal-open { overflow: hidden; margin-right: 14px; }

Others preferred changing the body's width instead.

body.modal-open { position: fixed; overflow: hidden; width: calc(100% - 14px); height: 100%; }

Both approaches work.

Neither is particularly elegant.

The hardcoded value depends on the operating system, browser, zoom level, and accessibility settings. Sooner or later someone reports that the layout still shifts.

Modern CSS solves this with a single property.

html { scrollbar-gutter: stable; }

That's it.

When scrollbar-gutter: stable is enabled, the browser permanently reserves space for the scrollbar. Opening a modal no longer changes the layout because that space already exists.

html, body { scrollbar-gutter: stable; }

The browser determines the correct scrollbar width automatically.

No calculations.

No JavaScript.

No platform-specific fixes.

2. Replace Generic Font Fallbacks with system-ui

Many projects still define fonts like this.

body { font-family: "Inter", sans-serif; }

There is nothing technically wrong with it.

The problem appears when the custom font fails to load.

The browser falls back to an arbitrary sans-serif font that often looks completely different from the rest of the operating system.

Modern CSS offers a better fallback.

body { font-family: "Inter", system-ui; }

The system-ui keyword tells the browser to use the platform's native interface font.

That means:

San Francisco on macOS and iOS

Segoe UI on Windows

Roboto on Android

Ubuntu on Ubuntu Linux

The result feels much more natural because your application immediately adopts the typography users already see throughout their operating system.

If your custom font loads successfully, nothing changes.

If it doesn't, the fallback still looks intentional.

3. Center Elements Without Flexbox

Ask most developers how they center an element and the answer is usually one of these.

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

Or:

.container { display: grid; place-items: center; }

Both are perfectly valid.

The question is whether you actually need Flexbox or Grid.

If the parent only contains one child, modern CSS provides a surprisingly clean alternative.

.container { min-height: 300px; align-content: center; } .card { width: 240px; margin-inline: auto; }

Here the responsibilities are divided naturally.

The parent handles vertical alignment.

The child centers itself horizontally.

There is no need to introduce Flexbox solely for centering.

This approach reduces unnecessary layout contexts and keeps the CSS easier to reason about.

4. Simplify Dark Mode with light-dark()

Dark mode used to require media queries everywhere.

A typical implementation looked like this.

:root { --background: white; --text: black; } @media (prefers-color-scheme: dark) { :root { --background: #1b1b1b; --text: white; } } body { background: var(--background); color: var(--text); }

There is nothing fundamentally wrong with this pattern.

It simply becomes repetitive as projects grow.

Modern CSS introduces light-dark().

:root { color-scheme: light dark; --background: light-dark(#ffffff, #1b1b1b); --text: light-dark(#222222, #f4f4f4); }

The rest of the stylesheet remains unchanged.

body { background: var(--background); color: var(--text); }

The browser automatically selects the appropriate value based on the user's preferred color scheme.

This significantly reduces duplicated variables and media queries.

The only requirement is enabling support with:

:root { color-scheme: light dark; }

For projects supporting both light and dark themes, light-dark() quickly becomes one of the most useful additions to modern CSS.

5. Stop Using left and right for Text Alignment

Most websites are built for left-to-right languages.

As a result, developers often write:

.article { text-align: left; }

Or:

.article { text-align: right; }

These values work until the application needs to support Arabic, Hebrew, or another right-to-left language.

Modern CSS solves this elegantly.

.article { text-align: start; }

Or:

.article { text-align: end; }

The browser automatically adapts.

For English:

start → left end → right

For Arabic:

start → right end → left

No additional CSS is required.

Logical properties make internationalization almost effortless and eliminate another class of layout bugs.

Why These Features Matter

None of these properties are revolutionary on their own.

Their real value comes from what they replace.

Instead of JavaScript hacks, manual calculations, duplicated media queries, and unnecessary layout containers, developers can rely on native browser behavior.

That leads to:

Less code

Fewer bugs

Better accessibility

Easier maintenance

More predictable layouts

Better internationalization support

Modern CSS is no longer just about writing styles.

It increasingly provides high-level layout and UI primitives that previously required frameworks or custom utilities.

The more of these features you adopt, the smaller your stylesheets become.

Ironically, writing modern CSS often means writing much less CSS.

Final Thoughts

CSS has matured into an incredibly capable language.

Properties such as scrollbar-gutter, system-ui, margin-inline, align-content, light-dark(), and logical alignment values eliminate many patterns that developers relied on for years.

If you're starting a new project today, there is little reason to carry those old workarounds forward.

The browser can now solve many of those problems…

Bulletproof React: Building React Apps That Survive Growth

Tue, 23 Jun 2026 00:00:00 GMT

Every React developer has experienced this moment.

You open a project you built six months ago and immediately wonder:

Why is this component here?

Why does this hook depend on three unrelated modules?

Why are API requests scattered across five different directories?

And perhaps the most terrifying question:

Who wrote this code?

Then you realize it was you.

React is one of the most flexible frontend frameworks ever created. It gives developers complete freedom over component design, state management, folder structures, API communication, testing strategies, and architectural decisions.

That freedom is both React's greatest strength and its biggest weakness.

Without clear boundaries, most React projects slowly evolve into collections of loosely connected components, utilities, hooks, and services that become increasingly difficult to understand, maintain, and extend.

This problem becomes especially painful as teams grow.

What starts as a clean side project eventually becomes a codebase nobody fully understands.

That is exactly the problem that Bulletproof React was created to solve.

The ideas discussed in this article are inspired by Alan Alickovic's excellent open-source project - bulletproof-react - which has become one of the most popular React architecture references on GitHub.

Rather than providing another boilerplate or starter kit, Bulletproof React offers a set of architectural principles and conventions designed to keep React applications maintainable long after their initial release.

Let's explore why it has become one of the most respected React architecture references on GitHub.

The Real Problem With React

React intentionally avoids enforcing architectural decisions.

Unlike frameworks that prescribe strict folder structures and application boundaries, React gives developers complete freedom.

At first, that feels empowering.

A typical project starts with something like this:

src/ components/ hooks/ utils/ services/ pages/

Everything looks perfectly reasonable.

Until it doesn't.

As the application grows, related code becomes scattered throughout the project.

A profile page may depend on:

components/UserProfile.tsx

hooks/useUser.ts

services/userApi.ts

utils/userHelpers.ts

types/user.ts

Understanding a single feature requires jumping between multiple unrelated directories.

The project is technically organized.

But it isn't structured around how developers actually think.

Developers think in features.

Traditional React projects are usually organized around file types.

That's where Bulletproof React starts.

The Core Idea: Organize by Features

The most important concept in Bulletproof React is feature-based architecture.

Instead of grouping code by technical category, related functionality lives together.

A simplified example looks like this:

src/ features/ auth/ projects/ comments/ notifications/

Each feature contains everything it needs:

auth/ api/ components/ hooks/ stores/ types/ utils/ index.ts

Authentication logic stays inside authentication.

Project management logic stays inside projects.

Comment functionality stays inside comments.

Everything related to a feature lives together.

This creates several immediate advantages.

Better Discoverability

When a developer needs to modify authentication, they know exactly where to go.

No more hunting across five unrelated folders.

Easier Refactoring

Changes remain localized.

Modifying a feature rarely impacts unrelated parts of the application.

Team Scalability

Multiple developers can work simultaneously on different features without constantly stepping on each other's toes.

Clear Ownership

Features naturally become bounded contexts.

Developers can reason about them independently.

This is one of the biggest reasons large engineering teams increasingly prefer feature-driven architectures.

Shared Code Still Exists

Not everything belongs inside a feature.

Some code is truly reusable.

Bulletproof React keeps shared infrastructure at the application level:

src/ components/ ui/ layout/ lib/ providers/ routes/ types/ utils/

The key rule is simple:

If something is only used by one feature, it belongs inside that feature.

If it is reused across multiple features, it can be promoted to shared infrastructure.

Many teams accidentally reverse this rule and end up with gigantic shared component directories that nobody understands.

Public APIs: Protecting Your Architecture

Feature-based architecture alone is not enough.

Developers can still bypass boundaries.

Imagine this import:

import { PrivateRoute } from '@/features/auth/components/PrivateRoute';

Technically it works.

Architecturally it's dangerous.

The importing module now depends on an internal implementation detail.

If the authentication team refactors its internal structure, unrelated parts of the application break.

Bulletproof React solves this through Public APIs.

Every feature exposes only approved exports through its root index file:

export { useAuth } from './hooks/useAuth'; export { AuthProvider } from './components/AuthProvider'; export type { User } from './types';

Consumers import only from the feature root:

import { useAuth } from '@/features/auth';

Everything else remains private.

This approach mirrors how libraries and packages expose public interfaces.

Features become miniature applications with clearly defined contracts.

Enforcing Architecture With ESLint

Architecture documentation is helpful.

Automated enforcement is better.

Bulletproof React strongly encourages using ESLint rules to prevent illegal imports.

Without enforcement, architectural boundaries eventually become suggestions.

With enforcement, they become guarantees.

A properly configured ESLint setup can block imports from internal feature directories and ensure that all communication happens through public APIs.

This transforms architecture from a convention into a system.

The result is less architectural drift and fewer accidental dependencies.

Rethinking State Management

Few topics generate more debate in the React ecosystem than state management.

Redux.

Context.

Zustand.

MobX.

Jotai.

Recoil.

The list never ends.

Bulletproof React approaches the problem differently.

Instead of asking:

"Which state library should we use?"

It asks:

"What kind of state is this?"

That distinction changes everything.

UI State

Temporary component state belongs inside components.

const [isOpen, setIsOpen] = useState(false);

Simple.

Local.

No global storage required.

Application State

Things like notifications, themes, and global UI behavior belong in lightweight state stores.

Libraries like Zustand excel here.

Server State

This is where many React projects make mistakes.

Data fetched from an API is not application state.

It is cached server state.

Treating server d…

Howto Use Next.js Route Handlers as a Mini Backend

Fri, 19 Jun 2026 00:00:00 GMT

When a Next.js project starts small, calling an external API directly from a page feels like the fastest path.

There is a list page.

There is a search box.

There is an external data source.

So the simplest solution is obvious: fetch the data and render it.

For a demo, that works.

For a real application, it usually starts creating problems.

The UI becomes coupled to someone else's response shape. Errors arrive in a format that is not designed for your product. Query parameters get validated in the component layer. Base URLs appear as strings inside UI code. Eventually, an API key or another secret appears, and suddenly the browser is no longer the right place for that logic.

That is where a server boundary becomes useful.

In the Next.js App Router, Route Handlers can provide that boundary.

They let you create internal API routes inside the app directory using the standard Web Request and Response APIs. They can handle methods such as GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS.

In practice, Route Handlers allow a Next.js app to contain a small backend layer without creating a separate backend service.

That layer can:

proxy external APIs

normalize responses for the UI

validate query parameters

hide environment variables

protect secrets

return predictable error formats

define an internal API contract

This makes Route Handlers especially useful for small full-stack projects, dashboards, admin panels, prototypes, and production apps that do not yet need a separate backend.

Where Direct Fetch Starts to Hurt

A typical first version might look like this:

'use client'; import { useEffect, useState } from 'react'; export default function ProductsPage() { const [products, setProducts] = useState([]); useEffect(() => { async function loadProducts() { const response = await fetch( 'https://dummyjson.com/products?limit=12' ); const data = await response.json(); setProducts(data.products); } loadProducts(); }, []); return ( <ul> {products.map(product => ( <li key={product.id}> {product.title} </li> ))} </ul> ); }

There is nothing terrible here.

The code is short.

It works.

But architecturally, the component now knows too much.

It knows the external URL.

It knows the external response shape.

It knows that the products live in data.products.

It will probably handle external API errors directly.

If the third-party API changes a field name, the UI breaks.

If authentication is added later, this client-side request becomes the wrong place for it.

The real question is:

Why should the UI know anything about dummyjson.com?

The interface does not need an external service.

It needs a clean list of products in an internal format.

Route Handler as an Internal API Boundary

Instead of calling the external API directly from the component, create an internal route:

src/app/api/products/route.js

This gives the application its own server endpoint:

/api/products

The UI can call this internal endpoint, while the Route Handler talks to the external API.

Here is a cleaner implementation:

// src/app/api/products/route.js import { getProductsApiBaseUrl } from '@/app/_config/env'; function createErrorResponse(message, status, details = null) { return Response.json( { ok: false, error: message, details, }, { status } ); } function parseNumberParam(searchParams, name, options) { const rawValue = searchParams.get(name); if (rawValue === null) { return { ok: true, value: options.defaultValue, }; } if (!/^\d+$/.test(rawValue)) { return { ok: false, error: { field: name, message: `${name} must be a positive integer`, }, }; } const value = Number(rawValue); if (value < options.min || value > options.max) { return { ok: false, error: { field: name, message: `${name} must be between ${options.min} and ${options.max}`, }, }; } return { ok: true, value, }; } function mapProduct(product) { return { id: product.id, title: product.title, price: product.price, thumbnail: product.thumbnail, category: product.category, brand: product.brand ?? null, rating: product.rating ?? null, }; } function normalizeProductsResponse(rawData, params) { const products = Array.isArray(rawData.products) ? rawData.products : []; return { items: products.map(mapProduct), page: { total: Number(rawData.total ?? products.length), limit: params.limit, skip: params.skip, }, query: { q: params.q, }, }; } export async function GET(request) { const apiBaseUrl = getProductsApiBaseUrl(); const url = new URL(request.url); const q = url.searchParams.get('q')?.trim() ?? ''; const limitResult = parseNumberParam( url.searchParams, 'limit', { defaultValue: 12, min: 1, max: 100, } ); if (!limitResult.ok) { return createErrorResponse( 'Bad Request', 400, limitResult.error ); } const skipResult = parseNumberParam( url.searchParams, 'skip', { defaultValue: 0, min: 0, max: 10000, } ); if (!skipResult.ok) { return createErrorResponse( 'Bad Request', 400, skipResult.error ); } const limit = limitResult.value; const skip = skipResult.value; const upstreamUrl = q ? new URL('/products/search', apiBaseUrl) : new URL('/products', apiBaseUrl); upstreamUrl.searchParams.set('limit', String(limit)); upstreamUrl.searchParams.set('skip', String(skip)); if (q) { upstreamUrl.searchParams.set('q', q); } try { const upstreamResponse = await fetch( upstreamUrl.toString() ); if (!upstreamResponse.ok) { const bodyPreview = await upstreamResponse .text() .then(text => text.slice(0, 200)) .catch(() => ''); return createErrorResponse( 'Upstream API Error', 502, { status: upstreamResponse.status, statusText: upstreamResponse.statusText, bodyPreview, } ); } const rawData = await upstreamResponse.json(); const data = normalizeProductsResponse( rawData, { q, limit, skip, } ); return Response.json( { ok: true, ...data, }, { status: 200 } ); } catch (error) { return createErrorResponse( 'Failed to load products', 500, { name: error?.name ?? 'Error', message: error?.message ?? String(error), } ); } }

This route does more than forward the request.

It creates a contract.

The browser no longer depends on the external API directly. It depends on your own /api/products route.

That is the important architectural shift.

Normalization Is More Useful Than Proxying

A weak Route Handler simply returns the external JSON as-is.

That is technically a proxy, but it does not solve much.

A stronger Route Handler normalizes the response into the shape the UI actually needs.

External response:

{ products: [ { id: 1, title: 'Phone', description: '...'…
Friday Links #39 — JavaScript Releases & Web Experiments Fri, 19 Jun 2026 00:00:00 GMT Another busy week in software development. AI tooling continued evolving at an absurd pace, JavaScript frameworks shipped new releases, browser vendors rolled out experimental features, and open-source maintainers somehow found time to launch another wave of libraries, runtimes, and developer tools. This edition collects the releases, discussions, tutorials, experiments, and projects that stood out during the week. Whether you're following React, TypeScript, AI agents, browser APIs, infrastructure, or modern web tooling, here are the links worth opening in a new tab. 🧠 Language & Runtime Updates TypeScript 7.0 Beta Continues To Generate Excitement The TypeScript team continues refining TypeScript 7.0 and its new Go-based compiler architecture. Early benchmarks and community testing suggest substantial performance improvements for large codebases, monorepos, and editor tooling. The transition marks one of the most significant architectural changes in TypeScript's history. VoidZero Joins Cloudflare One of the biggest JavaScript ecosystem stories this week: the team behind Vite, Rolldown, Oxc, Vitest, and VoidZero is joining Cloudflare. The move could accelerate development across the next generation of JavaScript tooling and infrastructure. The Cloudflare Blog npm 12 Will Disable Install Scripts By Default npm is preparing a major security-focused change. Future versions will no longer execute preinstall, install, and postinstall scripts automatically by default. The goal is to reduce supply-chain attack risks and improve package installation security. Node.js Security Releases Land Across Multiple Branches Node.js shipped security updates for multiple active release lines, including fixes for high-severity vulnerabilities. Teams running production workloads should review the latest security advisories and update accordingly. rfcs Node.js 24 Continues To Improve Developer Experience Recent updates to Node.js 24 introduced support for UUID v7 generation, additional testing utilities, and improvements across the platform. The project continues pushing toward a more batteries-included developer experience. Node.js Security Releases Land Across Multiple Versions The Node.js team released security updates across several supported release lines, including Node.js 22, 24, and 26. The updates address multiple high-severity vulnerabilities affecting core dependencies and runtime components. Teams running production workloads should review the advisories and upgrade as soon as possible to ensure their applications remain protected. Node.js Security Releases 📜 Articles & Tutorials How to Build ChatGPT From Scratch: Understanding LLMs Step by Step TypeScript Performance in TanStack Table V9 Introducing eve, an open-source agent framework How to Use Lazy Loading Without Hurting Web Performance An Interactive Cover Component Streaming HTML A backdoor in a LinkedIn job offer The problem with useEffect AI-assisted engineers are burning out, is this fine? How To Make Your Design System AI-Ready Introducing the MDN MCP server Software Is Made Between Commits ⚒️ Tools NextWeekAI - Curated directory of cutting-edge AI tools. View Transitions Toolkit A collection of utility functions to more easily work with View Transitions. eslint-plugin-unicorn 67.0 - Adds Even More Ways to Improve Your Code Nodemailer 9.0 Tightens Email Security in Node.js Nodemailer 9.0 is out, bringing updates to one of the most widely used email libraries in the Node.js ecosystem. The package continues to support SMTP, Amazon SES, and Sendmail-based delivery, while version 9.0 adds a notable security improvement: TLS connections are now validated by default when fetching remote content. For projects that generate rich emails with external assets, this is a small but important hardening update. Tabulator 6.5 - Easy to use, simple to code, fully featured, interactive JavaScript tables and data grids. <relative-time> element - Web component extensions to the standard <time> element. MiniPixelFont generator React Foundation Launches to Support the Future of React The newly announced React Foundation aims to provide long-term sustainability for one of the world's most widely used frontend ecosystems. The organization introduces a community-driven governance model focused on transparent decision-making, direct funding for maintainers, and financial support for critical open-source projects. By creating a dedicated foundation, the React community hopes to ensure the continued health, stability, and growth of the ecosystem for years to come. Is Your Site Agent-Ready? - A simple tool to check if your website is ready for AI agents. Taste Skill - Helps frontend projects escape the generic SaaS look Gemma Gem - Your personal AI assistant living right inside the browser. Gemma Gem runs Google's Gemma 4 model entirely on-device via WebGPU — no API keys, no cloud, no data leaving your machine. It can read pages, click buttons, fill forms, run JavaScript, and answer questions about any site you visit. Desktop Commander MCP - This is MCP server for Claude that gives it terminal control, file system search and diff file editing capabilities DepsGuard - Hardens Package Manager Configs Against Supply-Chain Attacks 📚 Libs zod-compiler Brings Zero-Overhead Validation to Zod zod-compiler is a new build-time optimization tool that transforms existing Zod schemas into highly optimized validators during bundling. Designed to work with Vite, Webpack, and other modern build systems, it preserves the familiar Zod API while generating tree-shakeable validation code with virtually no runtime ov… 35 React Interview Questions Senior Developers Still Get Wrong Wed, 17 Jun 2026 00:00:00 GMT React interviews have changed dramatically over the past few years. A few years ago, candidates were asked about class components, lifecycle methods, and whether they could recite the difference between componentDidMount() and componentDidUpdate(). Today, those questions rarely matter. Modern React interviews focus on a completely different set of topics: Rendering behavior State management React 19 features Server Components Performance optimization Architecture decisions Developer experience Interviewers want to understand whether a developer can build and maintain large React applications—not whether they memorized API documentation. This guide covers the React questions that appear most frequently in modern interviews and explains the reasoning behind the answers. Understanding How React Actually Renders Many React developers can build applications successfully without fully understanding what happens after state changes. Unfortunately, this becomes obvious during interviews. What Is React? The simplest answer is: React is a JavaScript library for building user interfaces using reusable components. A better answer explains why developers choose React: React allows developers to describe UI declaratively. Instead of manually updating the DOM, components describe what the UI should look like for a given state, and React handles the updates. What Is JSX? JSX is a syntax extension that allows HTML-like syntax inside JavaScript. Example: function WelcomeCard() { return ( <section> <h2>Welcome</h2> <p>Thanks for joining.</p> </section> ); } During compilation, JSX is transformed into React element creation calls. Modern React projects rarely require developers to think about this transformation, but interviewers still occasionally ask about it. What Is the Virtual DOM? One of the most common React interview questions. The Virtual DOM is an in-memory representation of the UI. When state changes: React creates a new virtual tree. Compares it with the previous tree. Calculates the minimum required updates. Updates the browser DOM efficiently. Many candidates incorrectly claim that the Virtual DOM is "faster than the DOM." That's not entirely true. The real advantage is that React minimizes expensive DOM operations. What Is Reconciliation? Reconciliation is the process React uses to compare two virtual trees. For example: function Counter({ count }: Props) { return <span>{count}</span>; } If count changes from 5 to 6, React does not rebuild the entire component tree. It identifies the smallest possible change and updates only the affected node. Keys: The Question That Appears Everywhere Why Are Keys Important? Keys help React identify elements between renders. Bad: { users.map((user, index) => ( <UserRow key={index} user={user} /> )); } Good: { users.map((user) => ( <UserRow key={user.id} user={user} /> )); } Using array indexes can cause: Incorrect state preservation Broken animations Unexpected form behavior Unnecessary re-renders This question appears surprisingly often in interviews. Modern React Hooks Questions Hooks remain one of the most important interview topics. When Should You Use useState? Use state when data affects rendering. const [isOpen, setIsOpen] = useState(false); Examples include: Modals Form inputs Selected tabs UI toggles If changing a value should trigger a UI update, it belongs in state. When Should You Use useRef Instead of useState? A common senior-level question. Not every value belongs in state. Bad: const [socket, setSocket] = useState<WebSocket | null>( null ); Better: const socketRef = useRef<WebSocket | null>( null ); Good use cases for refs: WebSocket instances Timers DOM elements External libraries Refs do not trigger re-renders. What Is the Biggest useEffect Mistake? Many developers use effects for derived state. Example: const [fullName, setFullName] = useState(''); useEffect(() => { setFullName( `${firstName} ${lastName}` ); }, [firstName, lastName]); This is unnecessary. Better: const fullName = `${firstName} ${lastName}`; If a value can be calculated during rendering, it usually should be. useEffect vs useLayoutEffect A classic interview question. Hook Runs useEffect After paint useLayoutEffect Before paint Example: useLayoutEffect(() => { const width = element.current?.offsetWidth; }, []); Use useLayoutEffect when measuring or synchronizing with the DOM before the browser paints. For most side effects, use useEffect. React 19 Interview Questions This is where most modern interviews focus. What Are Actions? Actions simplify async state management. Before React 19: const [loading, setLoading] = useState(false); const handleSubmit = async () => { setLoading(true); try { await saveProfile(); } finally { setLoading(false); } }; React 19: const [ profile, submitProfile, pending, ] = useActionState( updateProfile, null ); Understanding React 19 useActionState From First Principles Less boilerplate. Better UX. Built-in pending states. What Is useOptimistic? One of the most popular React 19 questions. It allows optimistic updates before a request finishes. const [ messages, addOptimisticMessage, ] = useOptimistic( chatMessages, (current, text) => [ ...current, { id: crypto.randomUUID(), text, pending: true, }, ] ); The UI updates immediately. The server response arrives later. Users perceive the application as much faster. What Is React Compiler? React Compiler is one of the biggest React changes in years. Historically: const activeUsers = useMemo( () => users.filter( (user) => user.active ), [users] ); With React Compiler: const activeUsers = users.filter( (user) => user.active ); The compiler can automatically insert memoization where safe. As adoption increases, many manual optimization patterns may disappear. What Is the Difference Between Server Components and Client Components? Server Components: Run on the server Send no JavaScript Can access databases directly Howto Master React 19 useActionState for Async Forms Wed, 17 Jun 2026 00:00:00 GMT React developers have spent years writing the same code over and over again. A form submits data. The UI enters a loading state. Errors must be handled. Success messages appear. Buttons become disabled. Then everything needs to be reset. The implementation rarely changes. Only the business logic does. A typical React form before React 19 often looked like this: function NewsletterForm() { const [pending, setPending] = useState(false); const [error, setError] = useState<string | null>(null); const [success, setSuccess] = useState(false); async function handleSubmit( event: React.FormEvent ) { event.preventDefault(); setPending(true); setError(null); try { const form = new FormData( event.currentTarget ); await subscribeUser(form); setSuccess(true); } catch (err) { setError( 'Subscription failed' ); } finally { setPending(false); } } return ( <form onSubmit={handleSubmit}> <input name="email" type="email" /> <button disabled={pending}> {pending ? 'Submitting...' : 'Subscribe'} </button> {error && <p>{error}</p>} </form> ); } There is nothing wrong with this code. The problem is repetition. Every form in every application eventually grows into a collection of loading flags, error states, success states, and submission handlers. React 19 introduces a different approach. What Is useActionState? useActionState is a React 19 hook designed to manage asynchronous state transitions. Instead of manually tracking: loading state success state error state submission lifecycle React manages the workflow automatically. The API is surprisingly small: const [ state, submitAction, isPending, ] = useActionState( action, initialState ); Three values. One hook. A significant reduction in boilerplate. The Simplest Example Imagine a newsletter subscription form. type FormState = { success: boolean; message: string; }; const initialState: FormState = { success: false, message: '', }; async function subscribe( previousState: FormState, formData: FormData ): Promise<FormState> { const email = formData.get('email'); await new Promise( resolve => setTimeout(resolve, 1000) ); return { success: true, message: `Subscribed ${email}`, }; } Using useActionState: function NewsletterForm() { const [ state, formAction, pending, ] = useActionState( subscribe, initialState ); return ( <form action={formAction}> <input name="email" type="email" /> <button disabled={pending}> {pending ? 'Submitting...' : 'Subscribe'} </button> {state.message && ( <p>{state.message}</p> )} </form> ); } The result is dramatically cleaner. No preventDefault. No loading state. No manual state synchronization. No try/catch boilerplate. React handles the lifecycle automatically. Why React Built This Hook At first glance, useActionState appears to be a form utility. It is not. Internally, React treats it as part of a much larger concept: Actions. An Action represents a user intent that changes application state. Examples include: submitting a form publishing a post deleting a record updating a profile synchronizing data React 19 introduces several APIs built around this concept: useActionState useOptimistic useTransition useFormStatus Server Actions Together they form a complete system for handling asynchronous state. Understanding the State Flow Traditional React applications often separate state and side effects. User Click ↓ Event Handler ↓ Loading State ↓ API Request ↓ Success/Error ↓ UI Update With useActionState: User Action ↓ Action Function ↓ React ↓ Updated State React becomes responsible for coordinating the transition. The developer focuses on business logic. Working with Validation A common use case is form validation. type LoginState = { error: string | null; }; async function loginAction( previousState: LoginState, formData: FormData ): Promise<LoginState> { const email = String( formData.get('email') ); if (!email.includes('@')) { return { error: 'Please enter a valid email', }; } return { error: null, }; } Inside the component: const [ state, submit, pending, ] = useActionState( loginAction, { error: null, } ); Validation errors become part of state instead of being handled separately. This creates a more predictable data flow. The Relationship Between useActionState and Server Actions One of the most exciting aspects of React 19 is Server Actions. A server action can be used directly with useActionState. Example: 'use server'; export async function createPost( previousState, formData ) { const title = formData.get('title'); await db.post.create({ data: { title, }, }); return { success: true, }; } Client component: const [ state, formAction, pending, ] = useActionState( createPost, { success: false, } ); This creates an extremely clean full-stack workflow. No custom API route. No fetch request. No manual serialization. No client-side request management. React handles everything. useActionState vs useReducer Many developers compare these APIs. They solve different problems. useReducer Best for: synchronous state updates complex UI state finite state machines reducers Example: dispatch({ type: 'ADD_TODO', }); useActionState Best for: forms API requests server mutations async workflows Example: formAction(formData); A useful rule: If the state change requires I/O, useActionState is usually the better choice. useActionState and useOptimistic The real power appears when these hooks work together. Imagine a comment form. Instead of waiting for the server: User submits ↓ Wait 2 seconds ↓ Comment appears You can show the comment immediately. const [ comments, addOptimisticComment, ] = useOptimistic( initialComments, ( currentComments, text ) => [ ...currentComments, { id: crypto.randomUUID(), text, pending: true, }, ] ); The UI feels instant. The server catches up later. This is one of the biggest user experience improvements enabled by React 19. Performance Considerations One hidden advantage of useActionState is its integration with Rea… The Forgotten Security Goldmine Hiding in Chrome DevTools Tue, 16 Jun 2026 00:00:00 GMT It's 2026. Autonomous delivery robots move through city streets. AI-powered QA systems automatically scan applications for common vulnerabilities. Modern frameworks can power everything from a local bakery website to a massive healthcare platform serving millions of users. Software development has never been more automated. Yet one of the oldest tools available in every browser continues to uncover security issues that expensive scanners still miss. I'm talking about the Source tab inside Chrome DevTools. For many developers, it feels like a relic from an earlier era of frontend development. Most people open DevTools for the Network panel, Console, Performance tools, or React DevTools. Few spend much time manually exploring JavaScript bundles and source files. That is exactly why it remains useful. When used carefully, the Source tab can reveal everything from forgotten debugging endpoints to sensitive credentials accidentally exposed during development. Sometimes you'll find nothing more than harmless internal tooling. Other times you'll discover security issues that deserve immediate attention. The goal isn't to hunt for vulnerabilities in a specific company or service. The goal is to understand a simple reality: Everything shipped to the browser is visible to the browser. And that makes source analysis surprisingly valuable even in 2026. The Source Tab Isn't Dead Many engineers assume that modern build pipelines have solved this problem. After all, we have: Bundlers Tree shaking Minification Source maps Secret scanning tools Static analysis AI code reviews Security scanners Surely nothing interesting remains visible to users anymore. In reality, that's not how software gets built. Large applications contain thousands of files and hundreds of contributors. Features move quickly. Debugging code gets added under pressure. Temporary workarounds become permanent solutions. Over time, small mistakes accumulate. A forgotten endpoint here. A hardcoded key there. An internal feature flag somewhere else. Most automated scanners look for known patterns. Humans are still remarkably good at finding things that don't fit a predefined rule. That's where manual source analysis continues to shine. A Simple Source Inspection Workflow Let's use a public website as an example. Not because we're trying to find vulnerabilities there, but because the workflow is universal. The process is straightforward: Open Chrome DevTools. Navigate to the Sources tab. Explore the loaded JavaScript files. Look for files with suspicious names. Search through code for common indicators. Files worth examining often contain names like: api helper debug test internal admin sandbox feature-flags experimental dev-tools [IMAGE: Screenshot placeholder showing Chrome DevTools Sources panel with multiple JavaScript bundles.] When a file catches your attention, search for terms such as: api token secret key auth admin debug internal endpoint staging password Modern applications frequently contain thousands of lines of bundled code. You don't need to read every line. Instead, think like an investigator looking for clues. You're searching for unusual behavior, hidden functionality, or information that doesn't belong in a public client application. What Do People Actually Find? Over the years I've seen developers uncover all sorts of things inside frontend code. Some findings are harmless. Others are serious. The most common categories tend to be: Internal or undocumented API endpoints. Secrets accidentally exposed to the client. Let's look at both. Undocumented Internal APIs Risk level: Medium to Critical This is one of the most common findings in modern applications. During development, engineers often create helper endpoints for testing, debugging, administrative actions, migrations, or internal tooling. Sometimes those endpoints are never removed. Sometimes they remain accessible from production code. Sometimes they're protected correctly. And sometimes they aren't. A common example looks something like this: const ADMIN_ENDPOINT = '/api/internal/reset-cache'; Or: fetch('/api/debug/set-user-role'); The presence of an endpoint alone isn't necessarily a vulnerability. Proper authentication and authorization may still prevent misuse. The problem appears when security controls are missing. Over the years I've encountered examples ranging from amusing to dangerous. At the low end, I've seen endpoints that allowed users to grant themselves cosmetic forum titles. At the high end, I've seen internal endpoints capable of modifying inventory counts for marketplace sellers. The difference between a curiosity and a critical issue is often just one missing authorization check. Why Hidden Endpoints Matter Many teams assume that if an endpoint isn't documented, nobody will find it. That assumption is dangerous. If the endpoint appears inside shipped JavaScript, it is effectively public. Attackers don't need documentation. They only need visibility. This is why security should never rely on obscurity. An endpoint must be protected even if every user on Earth knows its URL. A practical rule I've adopted is simple: Protect debugging endpoints exactly as aggressively as production endpoints. If an endpoint can change state, expose data, or trigger business logic, it deserves proper authorization controls. No exceptions. Secrets in Frontend Code Risk level: Low to Critical The second major category is exposed secrets. This usually happens because developers use credentials during development and accidentally leave them behind. Sometimes the secret appears directly in code. Sometimes it appears in comments. Sometimes it exists inside a configuration object that was never intended to reach production. Examples found in real-world applications include: AWS access keys Azure credentials API keys Payment provider secrets Email service credentials Slack tokens GitHub tokens Telegram bot tokens JWT signing secrets Administrative passwords Occasionally you encounter something like: const adminPassword = 'SuperSecretPassword123'; Or even: // temporary admin account // admin:password123 Yes, these examples sound ridiculous. Yet they still happen. Why Exposed Secrets Are Dangerous The consequences vary dramatically depending on the credential. An expired key may have no impact. An active credential can become catastrophic. Potential outcomes include: Repository access Cloud infrastructure compromise Administrative account takeover Database access Email service abuse Payment system abus… 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>  <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"> × </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>  <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"> × </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>  <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

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

JavaScript Development Space - Master JS and NodeJS

Friday Links #41: JavaScript, AI and Open Source

🧠 Language & Runtime Updates

TypeScript 7.0

npm 12

Bun 1.3.14

Node.js 26.5.0

📜 Articles & Tutorials

⚒️ Tools

📚 Libs

Master Docker Swarm with Real Production Examples

Why Docker Swarm Exists

Docker Swarm vs Standalone Docker

Where Swarm Fits in the Container Ecosystem

Docker Swarm

Kubernetes

Nomad

Understanding the Swarm Architecture

Manager Nodes

Leader Election

Why Raft Matters

Worker Nodes

Core Components Behind the Scenes

Scheduler

Howto Use the Decorator Pattern in Front-End Development

The Problem: Business Logic Mixed with Monitoring

What Is the Decorator Pattern?

Decorating Functions with Higher-Order Functions

Adding Performance Monitoring

Adding a Retry Mechanism

Decorating Functions with Debouncing

JavaScript String Algorithms Every Developer Should Know

Reversing a String

Why Does a String Have .length?

Understanding call() and this

Checking for a Palindrome

The Better Solution: Two Pointers

Remove One Character to Form a Palindrome

Why Only Two Cases?

Complexity Analysis

Reverse String

Palindrome (Two Pointers)

Remove One Character

Good Habits When Solving String Problems

Observer vs Publish-Subscribe: What's the Difference?

A Common Frontend Scenario

Option 1: The Observer Pattern

Characteristics

Option 2: Publish-Subscribe

The Key Difference

Observer

Publish-Subscribe

Where You'll Find the Observer Pattern

React State Subscriptions

The relationship is still the same: a single source of state owns its subscribers and informs them whenever its data changes.

Browser Observer APIs

State Management Libraries

Where Publish-Subscribe Shines

Cross-Component Communication

Micro-Frontends

Custom Events

A Common Mistake: Forgetting to Unsubscribe

How to Protect HTML Content from Being Copied

The Fundamental Problem

Level 1: CSS Protection

How easy is it to bypass?

Disable the Context Menu

Level 2: JavaScript Event Blocking

Invisible Overlay Layers

Level 3: Allow Copying, but Modify It

Level 4: Don't Store Text as Text

Render Everything with Canvas

Font Obfuscation

Choose Protection Based on the Threat

Casual visitors

Developers

Professional scrapers

Don't Sacrifice User Experience

Which Technique Should You Choose?

Final Thoughts

Why Does a String Have `.length`?

Understanding `call()` and `this`

1. Keep `CLAUDE.md` Small

2. Three `settings.json` Tweaks That Changed My Workflow

3. Don't Enable `acceptEdits` Everywhere

2. Replace Generic Font Fallbacks with `system-ui`

4. Simplify Dark Mode with `light-dark()`

5. Stop Using `left` and `right` for Text Alignment