soroushm

Docker Images: node:26-slim vs node:26-alpine

Choosing a base image for your Node.js 26 containers looks like a small decision, but it affects image size, build reliability, native module compatibility, and even runtime performance. The two most popular minimal options on Docker Hub are node:<version>-slim and node:<version>-alpine — for Node 26, that means node:26-slim and node:26-alpine. This guide breaks down how they differ and which one you should ship to production.

What is node:26-slim?

The node:<version>-slim tag is a stripped-down Debian-based image. It keeps glibc, the standard C library that virtually all prebuilt Node.js native addons target, but removes compilers, documentation, and most of the packages included in the full node:26 image. The result is an image that behaves exactly like a standard Linux environment while staying reasonably small — typically in the 200 MB range uncompressed, versus roughly 1 GB for the full node:26 image.

Because it is Debian under

soroushm

Prefetching, SSR, and SSG with TanStack Query

In Mastering React Hydration we looked at hydration from the runtime's point of view: the server ships HTML, React walks the existing DOM, attaches event listeners, and the page becomes interactive. We spent most of that article worrying about mismatches — what happens when the markup React expects and the markup it finds disagree.

Hydration of markup is only half the story. The other half is hydration of data. Your server rendered a product page with real prices in it; the moment React takes over on the client, the component tree needs those same prices in memory, or your carefully server-rendered page will flash a spinner and refetch everything it just displayed.

That's the problem TanStack Query's SSR support solves. This article is about the data half: how to prefetch on the server, how to serialize a cache across the network boundary, and how the pattern changes between SSG, SSR, and React Server Components.

The problem, concretely

soroushm

Install CocoaPods on a Mac

To install CocoaPods on a Mac with an M1, M2, M3, M4 chip (Apple Silicon, ARM architecture), the process is almost the same as on an Intel Mac, but there are a few things to keep in mind regarding Ruby compatibility and Homebrew setup. Here’s the recommended approach:

---

🔧 Step 1: Install Homebrew (if not already installed)

Homebrew makes managing dependencies much easier.

soroushm

Understanding Hydration in React: Why It Matters and How It Works

Before diving into the concept of hydration in React, it’s important to understand two foundational rendering strategies: Client-Side Rendering (CSR) and Server-Side Rendering (SSR). These approaches set the stage for why hydration is necessary and how it optimizes the user experience.

---

Client-Side Rendering (CSR)

In client-side rendering, all rendering takes place in the browser using JavaScript. When a user navigates to a page, the browser loads a minimal HTML shell and then fetches JavaScript to render the actual content. This results in longer initial load times and can lead to a blank screen until the JavaScript is fully executed.

soroushm

The Problem

Inconsistent code formatting makes code review difficult. When each developer uses a different style, every pull request ends up filled with formatting changes that reduce the readability of the actual code modifications.

Whether you're working solo or on a team, life’s too short to argue about The One True Brace Style or the eternal tabs vs spaces debate.

Tools like ESLint and Prettier solve this by automatically enforcing a consistent style guide. You can run Prettier manually via the command line or have it auto-format on save in your editor. However, this setup relies on each developer having their tools configured properly and it’s easy for that configuration to be missed, misconfigured, or simply forgotten.

Ideally, we want to ensure Prettier and ESLint run automatically after code changes are made but before they're committed to the repository.