Original post on my personal blog. Click here to read the full article

The most insidious bug in a mature codebase is Primitive Obsession.

We define our complex worlds in terms of string, number, and boolean. To our compilers, a UserId is mathematically identical to a TransactionId. A StockPrice is just a number, exactly the same as a Temperature.

This leads to the classic “swapped argument” disaster:

TypeScript

// The compiler thinks this is perfectly fine.
// But you just sent money to the wrong person.
transfer(amount, toAddress, fromAddress);

If your function signature is transfer(amount: number, from: string, to: string), you have effectively disabled the type system for those arguments. You are flying blind.

In this post, I am going to show you how to fix this using Branded Types and Zod. We are going to move from “trusting the developer” to “enforcing the architecture.”

The Problem: TypeScript is Structural

To solve this, we have to fight TypeScript’s nature. TypeScript uses a structural type system. If it looks like a duck, the compiler accepts it as a duck.

interface Admin { id: string; }
interface User { id: string; }
const admin: Admin = { id: "admin_1" };
const user: User = admin; // ✅ Valid in TypeScript!

This is great for flexibility but terrible for domain modeling. We need Nominal Typing. We need a system where a User is distinct from an Admin because we said so, not just because they happen to have the same fields.

Since TypeScript does not support this natively, we have to lie to the compiler. It is a useful lie.

The Solution: The “Unique Symbol” Brand

I have seen many ways to implement Branded types, including classes and private fields. Most have runtime overhead or clutter your IntelliSense.

After years of iteration, this is the only pattern I recommend for production. It uses unique symbol to create a "private" property that exists only in the type system.

// branding.ts
// 1. Declare a unique symbol.
// This exists only in type space if we don't export the value.
declare const __brand: unique symbol;
// 2. Define the generic utility
export type Brand<T, B> = T & { [__brand]: B };
// 3. Define your domain types
export type UserId = Brand<string, "UserId">;
export type Email = Brand<string, "Email">;
export type Cents = Brand<number, "Cents">;

This approach wins for three reasons. First, it has Zero Runtime Cost because the intersection vanishes after compilation. Second, it offers maximum safety because __brand is a unique symbol, so no other type can accidentally match it. Third, it keeps your runtime objects clean without ugly _type properties cluttering your console logs.

Now, if you try to assign a plain string to a UserId, TypeScript screams at you.

TypeScript

const id: UserId = "123"; 
// ❌ Error: Type 'string' is not assignable to type 'UserId'

The Runtime Gatekeeper: Integrating Zod

This creates a new problem. If we cannot assign a string to a UserId, how do we ever create one?

You could manually cast it using as UserId, but that defeats the purpose. Manual casting is dangerous. We need a rigorous way to "bless" raw data into our trusted types.

This is where Zod shines. We use Zod to validate the structure at the I/O boundary. If it passes validation, we transform it into our brand.

The “Parse, Don’t Validate” Pattern

I rarely use Zod’s native .brand() method because it locks you into Zod's internal types. Instead, I use a custom transform pipeline.

TypeScript

import { z } from "zod";
import { UserId, Email } from "./types";
// The Gatekeeper
export const UserIdSchema = z.string()
.uuid() // 1. Validate structure first
.transform((val) => val as UserId); // 2. "Bless" the type

export const EmailSchema = z.string()
.email()
.toLowerCase() // Normalization is free here!
.transform((val) => val as Email);

Why is as UserId safe here?

It is safe because it lives inside the Zod pipeline. We only cast the value after Zod has verified it is a valid UUID. We have encapsulated the “unsafe” operation inside a verified factory.

Putting It Together: The Architecture

Here is how this looks in a real Next.js or Node.js application.

1. The Domain Layer (Core)

Your business logic becomes self-documenting. It is impossible to call this function with an unvalidated string.

TypeScript

// domain/users.ts
import { UserId, Email } from "@/types";

export async function activateUser(id: UserId, email: Email) {
  // If we are here, 'id' is guaranteed to be a valid UUID
  // and 'email' is guaranteed to be a valid, lowercase email.
  console.log(`Activating ${id}...`);
}

2. The Input Layer (API/Actions)

This is the only place where raw strings exist.

TypeScript

// actions.ts
import { UserIdSchema, EmailSchema } from "@/schemas";
import { activateUser } from "@/domain/users";

export async function handleRequest(rawInput: unknown) {
  const payload = z.object({
    id: UserIdSchema,
    email: EmailSchema,
  }).safeParse(rawInput);

  if (!payload.success) {
    return { error: "Invalid data" };
  }
  // Payload.data.id is now typed as `UserId` automatically!
  await activateUser(payload.data.id, payload.data.email);
}

3. The Database Layer (Drizzle ORM)

If your database returns plain strings, you lose the safety chain. Drizzle ORM allows us to enforce brands at the schema level using $type.

TypeScript

// db/schema.ts
import { pgTable, text } from "drizzle-orm/pg-core";
import { UserId } from "@/types";


export const users = pgTable("users", {
  // Tell Drizzle: "This column is a UserId, not just a string"
  id: text("id").$type<UserId>().primaryKey(), 
  name: text("name"),
});

Now, when you run db.select().from(users), the result automatically has id: UserId. The safety extends from your database all the way to your frontend components.

When Should You Use This?

I do not brand everything. Branding FirstName or Description is usually overkill because those are just text.

I use the “Identity & Criticality” rule. I apply brands to three specific categories.

• IDs: UserId, OrderId, ProductId. Mixing these up is fatal to data integrity.
• Units of Measure: Seconds, Milliseconds, Cents. NASA lost a Mars orbiter because of this error, and you might just lose a customer.
• Sensitive Data: HashedPassword, SanitizedHtml. This prevents you from accidentally rendering a password to the UI.

Final Thoughts

Branded Types represent more than just a clever TypeScript hack. They are a declaration of intent. They allow us to write code that aligns with Domain-Driven Design, where our function signatures speak the language of the business rather than the language of the CPU.

By combining the compile-time guarantees of Branded Types with the runtime verification of Zod, you create a defense-in-depth strategy that eliminates entire categories of bugs before they ever reach production.

Stop passing strings. Start passing meaning.

Original post on my personal blog. Click here to read the full article

References & Resources

If you want to dive deeper into the tools and concepts mentioned in this article, here are the official resources:

• Zod Documentation: zod.dev
• Learning TypeScript (Branded Types): learningtypescript.com/articles/branded-types
• Drizzle ORM Custom Types: orm.drizzle.team/docs/custom-types
• Deep Dive on Branded Types (Video):(https://www.youtube.com/watch?v=aP6w2OzidYM)

Branded Types & Zod: The Senior Engineer’s Secret to Safety was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

I remember exactly when I fell out of love with Styled Components.

For years, it was my go-to. The developer experience felt like magic. I could pass props to my styles! I could use logic inside my CSS! It felt like the future.

Then, I led the development of a massive design system for a fintech client. We weren’t building a simple landing page; we were building complex dashboards with thousands of DOM nodes.

This is just the tip of the iceberg. I break down the full strategy with examples in the original post on my personal blog. Click here to read the full article

Suddenly, that “magic” started to feel heavy. The application became sluggish on lower-end devices. The initial load times crept up.

We realized the tool that helped us move fast in the beginning was now the very thing slowing us down.

1. The “Runtime Tax” is Too Expensive

Here is the simple truth:

Styled Components forces the browser to do extra work.

When your user loads a page, the browser has to download the JavaScript, parse it, execute it, and then inject the styles into the document.

It’s a lot of steps just to make a button blue.

On a small blog, you won’t notice it. But on an enterprise dashboard with data tables, visualizations, and hundreds of interactive elements? That overhead stacks up fast.

We found that by moving to a zero-runtime solution (like CSS Modules or Tailwind), we weren’t just changing syntax; we were giving the CPU a break.

2. It Fights Against Server Components

The React ecosystem is changing. With Next.js and the rise of Server Components, the goal is to do as much work as possible on the server before it ever reaches the user.

Runtime CSS-in-JS libraries like Styled Components are inherently client-side heavy. They need the browser to work their logic.

Trying to force them to play nice with the new App Router in Next.js felt like swimming upstream. We ended up with “use client” directives everywhere, effectively opting out of the performance benefits we were trying to gain.

3. Debugging Became a Nightmare

Have you ever tried to debug a production issue and looked at the DOM, only to see this?

<div class="sc-bdVaJa bDWFJH">...</div>

Those random hashes are useless.

When you are managing a team and trying to fix a critical UI bug, clarity is everything. We missed semantic class names. We missed being able to look at the HTML and instantly know what component we were dealing with.

Migrating away gave us our readability back.

The Conclusion

I still think Styled Components is a fine tool for smaller projects or rapid prototyping. But engineering is about trade-offs.

When you are building for scale, performance isn’t just a “nice to have”, it’s a feature. We realized that shipping JavaScript just to generate CSS was a trade-off we could no longer afford.

This is just the tip of the iceberg. I break down the full strategy with examples in the original post on my personal blog. Click here to read the full article

Styled Components Are Killing Your App’s Performance was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

From working on high-traffic gaming portals and complex fintech dashboards, one thing has been very clear to me: the way you structure a Next.js app is as important as the stack itself. Next.js, TypeScript, React, TanStack Query… they all help — but without a clear architecture, the project will slow you down.

This is the condensed version of how I structure Next.js projects to stay fast, discoverable, and scalable over time. For the full deep dive, including more code and context, you can read the original article on my blog: How I Structure Next.js Projects for Scale (gperrucci.com)

From “components/hooks/utils” to Feature-Based Architecture

Most tutorials start with a technical folder split:

• components/
• hooks/
• utils/

This works for a portfolio or a simple marketing site. But in real products — multi-tenant platforms, financial dashboards, back-office tools — this style actively hurts you:

• You need to jump across 3–5 folders just to change one feature.
• Business concepts are scattered: API calls in lib/ or services/, components in components/, types in types/…

Instead, I organize by feature / business domain.

If I delete src/features/invoices, I expect to remove everything related to invoices: components, hooks, API layer, and types. That’s my test for a good feature boundary.

So the core principle is:

Group by feature, not by file type.

The High-Level Folder Layout

Here’s the layout I use as a default for production-grade Next.js (App Router) apps:

src/
├── app/                  # Routing & layouts only
│   ├── (public)/
│   ├── (dashboard)/
│   ├── layout.tsx
│   └── page.tsx
├── components/           # Shared UI ("Design System")
│   ├── button/
│   ├── modal/
│   └── typography/
├── features/             # Business domains
│   ├── auth/
│   ├── settings/
│   └── financial-risk/
├── lib/                  # 3rd-party wiring & config
│   ├── axios.ts
│   ├── query-client.ts
│   └── utils.ts
└── types/                # Global types (keep small)

Each of these top-level folders has a very specific responsibility.

Keeping app/ Thin: Routes, Not Business Logic

The App Router is fantastic for layouts and data-fetching, but that doesn’t mean your page.tsx files should become 300-line components.

I treat each page.tsx as an entry point that hands off almost immediately to a feature.

Bad pattern: doing everything in the route file.

// ❌ app/dashboard/page.tsx
'use client';
export default function DashboardPage() {
  // Local state, effects, complex logic, transformations...
  // 50+ lines of behavior mixed with JSX
  return <div>...</div>;
}

Preferred pattern: delegate to a feature.

// ✅ app/dashboard/page.tsx
import { DashboardOverview } from '@/features/dashboard/components/dashboard-overview';
export default function DashboardPage() {
  return <DashboardOverview />;
}

This gives you:

• Simpler routing layer.
• Cleaner separation between URL structure and business logic.
• Easier refactors when product requirements evolve.

The features/ Directory: Where the Real Work Lives

The features/ folder is where 80–90% of your time should be spent. Each feature behaves like a mini-application, with clear internal structure:

src/features/financial-risk/
├── components/           # Only for this feature
│   ├── risk-chart.tsx
│   └── risk-table.tsx
├── hooks/                # Feature-specific hooks
│   └── use-risk-calculations.ts
├── api/                  # Data access for this domain
│   └── get-risk-data.ts
└── types/                # Domain types
    └── index.ts

Some guidelines:

• Don’t put shared-looking code here too early. It’s fine if risk-table.tsx initially duplicates some logic from positions-table.tsx.
• Do keep everything that belongs to the domain together: UI, hooks, data access, and types.

When a feature becomes obsolete, you remove one folder and you’re done. No orphaned files hiding in utils/.

The components/ Directory: Your Internal Design System

src/components/ is reserved for shared UI, not business logic.

Think of it as your local design system:

• Buttons, modals, form controls, layout primitives.
• No knowledge of API calls, business rules, or domain terms like “invoice” or “risk”.

A button component should care about things like variant and size, not about “approve invoice” vs “reject invoice”. That logic lives in your features.

The benefit is two-fold:

• Product teams can move fast inside features without worrying about breaking other areas.
• Design consistency is enforced through a small set of shared components.

Example: A Transaction Feature Built for Scale

Let’s connect the pieces with a concrete example: a Transactions feature using TypeScript and TanStack Query.

1. API layer — encapsulate server access for this domain:

// src/features/transactions/api/get-transactions.ts
import { axios } from '@/lib/axios';
import type { Transaction } from '../types';
export const getTransactions = async (): Promise<Transaction[]> => {
  const response = await axios.get('/transactions');
  return response.data;
};

2. Typed model — strictly scoped to the feature:

// src/features/transactions/types/index.ts
export interface Transaction {
  id: string;
  amount: number;
  currency: string;
  createdAt: string;
}

3. UI component — co-locates the behavior and rendering:

// src/features/transactions/components/transaction-list.tsx
'use client';
import { useQuery } from '@tanstack/react-query';
import { getTransactions } from '../api/get-transactions';
import type { Transaction } from '../types';
import { Spinner } from '@/components/ui/spinner';
const TransactionItem = ({ transaction }: { transaction: Transaction }) => (
  <li>
    {transaction.amount} {transaction.currency} –{' '}
    {new Date(transaction.createdAt).toLocaleString()}
  </li>
);
export const TransactionList = () => {
  const { data, isLoading, isError } = useQuery({
    queryKey: ['transactions'],
    queryFn: getTransactions,
  });
  if (isLoading) return <Spinner />;
  if (isError) return <div>Failed to load transactions</div>;
  return (
    <ul className="space-y-2">
      {data?.map((tx) => (
        <TransactionItem key={tx.id} transaction={tx} />
      ))}
    </ul>
  );
};

4. Route file — thin entry point:

// app/(dashboard)/transactions/page.tsx
import { TransactionList } from '@/features/transactions/components/transaction-list';
export default function TransactionsPage() {
  return <TransactionList />;
}

With this setup:

• Routing is clean and focused.
• Transactions logic lives entirely in features/transactions.
• Shared UI (Spinner) comes from components/.
• Server state is handled by TanStack Query, not by ad-hoc state sprinkled across the app.

State Management: Lean Hard on Server State

A frequent mistake in React apps is to push everything into global state (Redux, Zustand, contexts) even when the data actually lives on the server.

My rule of thumb:

1. Comes from an API or DB? Use TanStack Query (server state).
2. Represents filters, sorting, pagination? Use URL search params (Next.js useSearchParams).
3. Pure UI concerns (dialog open, selected tab)? Use local useState in the closest component.
4. Truly global UI (theme, layout toggles) or cross-feature coordination? Then consider context or a small Zustand store.

This keeps global state small and targeted, while the majority of your data flows through well-understood server-state tooling.

When to Abstract: The “Rule of Two”

Engineers often abstract too early: a “shared” component appears the first time a pattern is used, and then it slowly turns into a massive God component that everybody is afraid to touch.

I try to follow a simple rule:

Don’t move a component into src/components/ until it’s used in at least two different features.

Before that, leave it inside the feature, even if it looks generic. Duplicating a small chunk of code is cheaper than maintaining the wrong abstraction across the entire codebase.

Once you genuinely see the same behavior in multiple features, you can extract a cleaner, more accurate shared component.

For the full version of this article — with more detail, screenshots, and additional nuances around migration and team workflows — you can read it on my blog: How I Structure Next.js Projects for Scale.

How I Structure Next.js Projects for Scale was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a condensed version of my original article published on my blog:
“The Mental Shift: Unlearning Next.js 12 to Master the App Router”
👉 https://www.gperrucci.com/en/blog/react/mental-shift-nextjs-12-app-router

If you have spent years working with Next.js 12, you probably move through a familiar ritual:

• Add getServerSideProps or getStaticProps without thinking.
• Wire global state in _app.tsx.
• Fight waterfalls and layout shifts when data comes from the client.

Upgrading to Next.js 14/15 with the App Router is not “Next.js 12 with a nicer API.” It feels much closer to switching frameworks.

The real work is not learning new functions. It is unlearning the old mental model and replacing it with a server-first way of thinking powered by React Server Components (RSC).

This article is about that mental reset.

The Old World: The “Thick Client” Illusion

In the Pages Router era, the pipeline looked like this:

1. The server runs getServerSideProps / getStaticProps, fetches data, and renders HTML.
2. The browser receives HTML + JSON + a JavaScript bundle.
3. React hydrates on the client and takes over.

Even when the server did some work, the real “application” still lived in the browser. Your React tree always shipped as JavaScript, and hydration was the price you paid to get interactivity.

This had some painful side effects:

• Deeply nested components needing data forced you into prop drilling from the page level.
• Or you shifted fetching into the client (via useEffect, React Query, etc.) and accepted waterfalls and loading spinners.
• Global state grew just to keep the UI in sync with APIs that really belonged closer to the backend.

We spent a lot of time optimizing around constraints that were baked into this architecture.

The New Reality: Server Components as the Default

The App Router introduces React Server Components and quietly flips the entire model:

• In app/, components are Server Components by default.
• They render on the server only.
• They never hydrate, and their code is never shipped to the browser.

Instead of your component being a template waiting for data, the component itself can be the backend boundary:

• It can read cookies and headers.
• It can call your database directly.
• It can use secrets without exposing them to the client.

This is why the App Router feels so different. You’re no longer bolting server behavior onto a client app; you’re building a server-first tree with small, explicit islands of interactivity.

A Concrete Example: Dashboard in Next 12 vs App Router

Let’s look at a common scenario: a dashboard that needs a user profile and settings.

The Next.js 12 Way (Pages Router)

// pages/dashboard.tsx
import { GetServerSideProps } from 'next'
import { User, Settings } from '../types'
interface Props {
  user: User
  settings: Settings
}
export const getServerSideProps: GetServerSideProps<Props> = async (ctx) => {
  const userRes = await fetch('https://api.internal/user', {
    headers: { Cookie: ctx.req.headers.cookie || '' },
  })
  const user = await userRes.json()
  const settingsRes = await fetch(
    `https://api.internal/settings/${user.id}`,
  )
  const settings = await settingsRes.json()
  return { props: { user, settings } }
}

export default function Dashboard({ user, settings }: Props) {
  return (
    <main>
      <h1>Welcome, {user.name}</h1>
      <SettingsPanel data={settings} />
    </main>
  )
}

Here the data-fetching logic is detached from the component tree. If SettingsPanel needs more data later, you go back to getServerSideProps, change the query, and drill more props down.

The page is not self-contained; the data pipeline lives elsewhere.

The App Router Way (Server Components)

Now with the App Router, we colocate data and UI in async Server Components.

// app/dashboard/page.tsx
import { cookies } from 'next/headers'
import { SettingsPanel } from './_components/settings-panel'
export default async function DashboardPage() {
  const cookieStore = await cookies()
  const token = cookieStore.get('auth_token')?.value
  const user = await getUser(token)
  return (
    <main>
      <h1>Welcome, {user.name}</h1>
      {/* SettingsPanel can fetch its own data */}
      <SettingsPanel userId={user.id} />
    </main>
  )
}

// app/dashboard/_components/settings-panel.tsx
async function SettingsPanel({ userId }: { userId: string }) {
  const settings = await db.settings.findUnique({ where: { userId } })
  return (
    <section>
      <h2>Settings</h2>
      <pre>{JSON.stringify(settings, null, 2)}</pre>
    </section>
  )
}

The important part is what changed:

• Both DashboardPage and SettingsPanel run on the server.
• They fetch their own data.
• The browser receives fully rendered HTML for the user and settings, with zero client-side fetches needed for this view.

In the Next 12 mindset, this pattern would usually push SettingsPanel into client-side fetching. In the App Router mindset, you keep it server-side, closer to your data.

That’s the “aha” moment for most teams.

The Heuristic: When to Write "use client"

One of the first questions people ask is:

“So do we just never use client components anymore?”

You absolutely still use them, but for a different reason.

Instead of using them for data fetching, you use them for interactivity.

This is the rule I work with:

• If a component mostly reads data (DB queries, API calls, static content) → keep it as a Server Component.
• If a component needs to listen to the user (onClick, onChange, useState, useEffect) → make it a Client Component.

You opt into client behavior explicitly with "use client" at the top of the file:

// app/components/like-button.tsx
'use client'
import { useState } from 'react'
export default function LikeButton() {
  const [likes, setLikes] = useState(0)
  return (
    <button onClick={() => setLikes((prev) => prev + 1)}>
      Like {likes}
    </button>
  )
}

You then embed <LikeButton /> inside a Server Component:

// app/post/[slug]/page.tsx (server)
import LikeButton from '@/app/components/like-button'
export default async function PostPage() {
  const post = await getPostFromDB()
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
      <LikeButton />
    </article>
  )
}

The result:

• The post content is server-rendered, cacheable, and SEO-friendly.
• Only the small LikeButton island hydrates and runs in the browser.

You start thinking in terms of interactive islands inside a server-rendered tree, not one big client app with some SSR sprinkled in.

Pros, Cons, and Reality Checks

This new model comes with real benefits, but also real friction.

Why It’s Worth It

You gain:

• Smaller bundles — server component code never ships to the browser. Heavy utilities and parsing libraries stay on the server.
• Better security — database queries and secrets live directly in server components, no extra API layer required just for rendering.
• Clearer boundaries — components can own their data and markup instead of acting as passive templates.

In practice, this usually translates to better performance and a simpler data flow, especially in large dashboards and content-heavy apps.

The Friction You Will Feel

You also have to accept new constraints:

• You must track where a component runs. Trying to use useState in a Server Component will fail, and that’s by design.
• Some library ecosystems are still catching up to RSC, especially if they assume a browser environment everywhere.
• Caching behavior in the App Router is more opinionated and more aggressive; the old mental model of “getServerSideProps always runs on every request” no longer applies.

There is a learning curve, and you will hit it.

Original Article & Further Reading

You can find the full, extended version of this article here:
👉 https://www.gperrucci.com/en/blog/react/mental-shift-nextjs-12-app-router

The Mental Shift: Unlearning Next.js 12 to Master the App Router was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

CSS subgrid is the feature that finally fixes this. It lets nested grids reuse the exact same tracks as their parent, so components align as if they were on a single shared grid — even when they live several levels deep in the DOM.

This article is a concise version of my full deep dive, which you can read here:
👉 Original article: https://www.gperrucci.com/en/blog/css/css-subgrid-consistent-complex-layouts

👉 Live code example (StackBlitz): https://stackblitz.com/~/github.com/centrodph/subgrid-example

What Subgrid Really Does (In One Paragraph)

With normal CSS Grid, every grid container defines its own rows and columns. A child grid has no idea what tracks exist on the parent; it is a separate layout world. Subgrid changes that: when you set grid-template-rows: subgrid or grid-template-columns: subgrid on a child grid, it inherits the track sizes and gaps from the parent area it spans. The child still controls how its own items are placed, but the tracks themselves are shared.

That means your cards, sections or nested layouts can all line up vertically and horizontally without copy-pasting grid-template-rows and hoping nothing drifts out of sync.

Why Nested Grids Used To Be So Awkward

Imagine a common layout: a responsive grid of cards with a title, body and footer.

Without subgrid, you usually do something like:

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(18rem, 1fr));
  gap: 1.5rem;
}

.card {
  display: grid;
  grid-template-rows: auto 1fr auto; /* duplicated everywhere */
}

Each .card is an independent grid. The tallest card determines the column height, but internal rows are not shared, so titles and footers only “kind of” align. If you change the parent’s track logic, you must manually keep every nested grid in sync.

Some developers tried to cheat with display: contents so grandchildren become direct children of the main grid. That helps alignment, but it breaks the idea of a “card” as a real layout boundary and can confuse accessibility tools and devtools.

Enter Subgrid: One Grid, Many Levels

With subgrid, you keep the card as a proper grid item and a grid container, but you allow its row tracks to come from the parent grid.

HTML

<section class="section">
  <h1 class="heading">Latest articles</h1>
  <div class="cards">
    <article class="card">
      <h2 class="card__title">Subgrid for perfectly aligned cards</h2>
      <p class="card__excerpt">
        Use CSS subgrid to keep titles, excerpts and CTAs aligned across cards.
      </p>
      <footer class="card__meta">5 min read · Layout</footer>
    </article>
    <!-- More .card elements... -->
  </div>
</section>

CSS with subgrid

.section {
  padding: 2rem clamp(1.5rem, 4vw, 4rem);
  background: #020617;
  color: #e5e7eb;
}
.heading {
  font-size: clamp(1.5rem, 3vw, 2rem);
  margin-bottom: 1.5rem;
}
/* Parent grid defines the “layout contract” */
.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(18rem, 1fr));
  grid-template-rows: auto 1fr auto; /* title / body / footer */
  gap: 1.5rem;
}
/* Each card becomes a subgrid for rows */
.card {
  display: grid;
  grid-template-rows: subgrid;  /* reuse auto 1fr auto */
  grid-row: auto / span 3;      /* span those 3 parent tracks */
  padding: 1.25rem 1.5rem;
  border-radius: 0.75rem;
  background: #020617;
  border: 1px solid #1f2933;
}
/* Children align to the shared row tracks */
.card__title {
  grid-row: 1;
  margin: 0 0 0.5rem;
  font-size: 1.125rem;
  font-weight: 600;
}
.card__excerpt {
  grid-row: 2;
  margin: 0 0 0.75rem;
  font-size: 0.95rem;
  line-height: 1.5;
}
.card__meta {
  grid-row: 3;
  margin-top: auto;
  font-size: 0.85rem;
  opacity: 0.75;
}

The key ideas:

• The parent grid defines the row tracks (auto 1fr auto) and the gap.
• Each card declares grid-template-rows: subgrid and spans three rows, so it adopts those exact tracks.
• The card’s children place themselves in row 1, 2 and 3, and every card now lines up perfectly, regardless of content length.

If you want to see a full working example (including React/TypeScript structure), you can open the StackBlitz project here:
👉 https://stackblitz.com/~/github.com/centrodph/subgrid-example

Subgrid in Design Systems: Macro Grids and Shared Rhythm

Subgrid becomes even more interesting when you think beyond a single card grid and start reasoning in terms of macro grids.

You can define a page-level or app-level grid with named rows and columns — [header], [main], [footer], [content-start], [content-end], and so on. Each major region (header, main content, sidebar, footer) becomes a grid that uses grid: subgrid / subgrid, so they all align to the same track system.

This connects directly to how many design systems are modelled in tools like Figma: a single grid that everything respects. Subgrid is the missing piece that allows your markup to mirror that concept without duplicating layout logic in every component.

Browser Support and Fallback Strategy

The good news: modern browsers finally support subgrid.

The practical approach is progressive enhancement:

/* Baseline: normal nested grid */
.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(18rem, 1fr));
  gap: 1.5rem;
}

.card {
  display: grid;
  grid-template-rows: auto 1fr auto;
}

/* Enhancement for browsers that understand subgrid */
@supports (grid-template-rows: subgrid) {
  .cards {
    grid-template-rows: auto 1fr auto;
  }

  .card {
    grid-template-rows: subgrid;
    grid-row: auto / span 3;
  }
}

Older browsers see a standard nested grid with “good enough” layout. Newer browsers get aligned rows and a cleaner layout model. You do not need JavaScript to “polyfill” subgrid; you simply give modern engines a better version of the same layout.

When Subgrid Is Worth It

Subgrid is not something you sprinkle randomly; it pays off most when:

• You have repeating components (cards, tiles, media items) that must align in both axes across a grid.
• You maintain a design system and want a single source of truth for page layout.
• You are already committed to CSS Grid and want to remove hacks like forced heights and display: contents wrappers.

If your layout is simple, classic Grid or Flexbox may still be enough. But once you feel the pain of nested alignment, subgrid is usually the more honest and maintainable solution.

Wrap-Up and Further Reading

CSS subgrid closes a long-standing gap in CSS layout: it gives you nested components that behave like they live on the same grid, without throwing away encapsulation. It does not replace Grid; it extends it in a way that matches how we already think about pages and design systems.

If you want the complete deep dive with more examples, browser details and design-system patterns, you can read the original article here:

👉 Original article on my blog:
https://www.gperrucci.com/en/blog/css/css-subgrid-consistent-complex-layouts

And if you prefer to explore the code, tweak it and see the layout update instantly:

👉 Live StackBlitz demo:
https://stackblitz.com/~/github.com/centrodph/subgrid-example

CSS Subgrid: Making Complex Layouts Behave was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaScript has become the “duct tape of the Internet,” as Charlie Campbell put it, and modern front-end development is the proof.

When you browse an online store, filter products, compare prices, and complete a checkout, you are moving through a carefully orchestrated front-end stack: HTML for structure, CSS for design, JavaScript or TypeScript for behavior, and increasingly preprocessors and frameworks that keep everything maintainable as projects grow.

This article is a condensed version of the full guide. It focuses on what actually matters when you are deciding how to build front-end applications today.

Modern Front-End Development: From HTML and CSS to Angular, React, and Vue

1. The core: HTML, CSS, and JavaScript still matter

Despite all the tooling noise, modern front-end work still rests on three pillars:

• HTML defines what exists: headings, buttons, forms, images.
• CSS defines how it looks: layout, spacing, typography, responsive behavior.
• JavaScript / TypeScript define what it does: interactions, data fetching, dynamic updates.

A tiny example captures the relationship:

<!-- index.html -->
<button id="login-button">Log in</button>
<script type="module" src="main.js"></script>

// main.ts – TypeScript compiled to JavaScript
const loginButton = document.querySelector<HTMLButtonElement>('#login-button');

if (!loginButton) {
  throw new Error('Login button not found');
}

loginButton.addEventListener('click', () => {
  // In a real app, you would call your backend here
  alert('Logging in...');
});

HTML gives us a button, CSS (not shown) determines whether it looks trustworthy or sketchy, and TypeScript wires the behavior. Everything else in modern front-end stacks builds on top of this foundation.

If your fundamentals in HTML, CSS, and JavaScript are weak, frameworks will only hide the problem, not solve it. MDN’s documentation for HTML and the JavaScript guide are still the best starting point.

2. When plain CSS starts to hurt: Sass and Less

Plain CSS works fine for a small marketing site. It becomes painful when you are styling a complex dashboard or e-commerce app:

• You repeat the same colors and spacing everywhere.
• Simple refactors become dangerous because selectors are tangled.
• You struggle to express “design tokens” like spacing scales or color palettes.

That is where Sass and Less come in.

Sass adds variables, nesting, mixins, and functions, then compiles down to plain CSS. You might define a $primary-color once and reuse it across components. The official docs at sass-lang.com show how far you can push this, especially for design systems.

Less offers similar capabilities with a slightly different syntax and the option to compile in the browser via less.js. It is still common in older design systems and legacy projects; the docs live at lesscss.org.

In practice:

• For new projects with a build step, Sass is often the pragmatic choice.
• For existing codebases already using Less, migrating just to follow trends rarely pays off.
• For small sites, good plain CSS with custom properties is enough and keeps the toolchain simpler.

Preprocessors are not mandatory, but they are often the difference between a stylesheet you can refactor confidently and one you are afraid to touch.

3. Adaptive vs responsive: not just buzzwords

The web course material you started from correctly highlights adaptive and responsive design, but many teams still conflate them.

• Adaptive design creates distinct layouts for specific breakpoints (mobile, tablet, desktop). The system chooses which layout to serve. You may even change content per device class.
• Responsive design uses a single layout that fluidly reflows, relying on flexible grids, relative units, and functions like min(), max(), and clamp().

Most modern products should default to responsive design: one system that adapts gracefully. Adaptive design is a conscious choice when you want different experiences, for example a radically simplified mobile checkout.

Whichever approach you choose, frameworks will not fix poor layout decisions. You need solid CSS skills either way.

4. Angular, React, and Vue: what really distinguishes them

As applications grow, direct DOM manipulation becomes unmanageable. You need components, routing, state management, and patterns that scale beyond a handful of pages. That is where frameworks come in — most teams standardize around Angular, React, or Vue.

Angular — opinionated and integrated

Angular is a TypeScript-first framework with a strong architecture baked in. You get components, routing, dependency injection, forms, and HTTP utilities out of the box.

Angular works well when you have:

• Larger teams that benefit from strict conventions.
• Enterprise-style apps that need clear layering and long-term maintainability.

The trade-off: the learning curve is noticeably steeper, and the boilerplate can feel heavy for smaller or design-driven front-ends.

Official docs: angular.dev · GitHub: angular/angular

React — flexible and ecosystem-driven

React is “the library for web and native user interfaces.” It focuses on the view layer and leaves routing, data fetching, and many architectural decisions to you and the ecosystem.

A minimal React + TypeScript component looks like this:

// ProductCard.tsx
type ProductCardProps = {
  name: string;
  price: number;
  onAddToCart: () => void;
};

export const ProductCard = ({ name, price, onAddToCart }: ProductCardProps) => (
  <article className="product-card">
    <h3>{name}</h3>
    <p>${price.toFixed(2)}</p>
    <button type="button" onClick={onAddToCart}>
      Add to cart
    </button>
  </article>
);

React shines when:

• You need flexibility and want to compose your own stack (for example, Next.js, TanStack Query, Zustand).
• You care about ecosystem depth and reusing logic across web and native (React Native).

The downside is the same flexibility: you must make more decisions and keep up with a fast-moving ecosystem.

Official docs: react.dev · GitHub: facebook/react

Vue — approachable and progressive

Vue brands itself as a progressive framework: you can drop it into an existing page or build a full SPA with routing and state management.

It is attractive when:

• You want template syntax that feels very close to HTML.
• You need to enhance server-rendered pages with pockets of interactivity instead of rewriting everything.

Vue often feels like a middle ground between Angular’s structure and React’s flexibility, with a strong focus on developer experience.

Official docs: vuejs.org/guide · GitHub: vuejs/core

So which one should you choose?

There is no universal winner. A practical heuristic:

• Choose Angular when you want strong conventions, a complete toolbox, and are building long-lived, large-team applications.
• Choose React when you need maximum flexibility, want to leverage a huge ecosystem, or plan to share code across platforms.
• Choose Vue when you value an approachable learning curve and progressive adoption in existing projects.

What matters more than the logo on your slide deck is consistency: once you choose a framework, define shared patterns for file structure, state management, data fetching, and testing so your UI does not collapse under incremental complexity.

5. A realistic learning path (without chasing every trend)

Modern front-end development is noisy. There is always a new build tool, a new meta-framework, a new state library. You do not need all of them.

For most developers, a pragmatic path looks like this:

1. Master HTML and CSS. Semantic markup, Flexbox, Grid, responsive design. No shortcuts.
2. Get comfortable with JavaScript and TypeScript in the browser. Manipulate the DOM, handle events, call APIs with fetch.
3. Add Sass or Less when your CSS starts to hurt. Capture design tokens in variables instead of copy-pasting values.
4. Pick one framework — Angular, React, or Vue — and go deep. Build at least one real app with routing, forms, authentication, and error handling.
5. Iterate on real products. Dashboards, admin panels, and e-commerce flows will teach you more than another to-do app ever will.

If you focus on these fundamentals, you will be able to evaluate new tools on their merits instead of chasing them out of fear of missing out.

Read the full article

This is a condensed version of the full piece. If you want more detailed examples, including code for Angular, React, and Vue components, plus references to MDN and official docs, you can read the original here:

➡️ Full article:
Modern Front-End Development: From HTML and CSS to Angular, React, and Vue

Modern Front-End Development in Practice: From HTML & CSS to Angular, React, and Vue was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you test UI behavior, proving that “something is not there” is as important as proving that it is. The tricky part: elements can be present but invisible, scheduled to unmount, or living in a portal. Here’s the practical, reliable approach that avoids flakiness.

More reasoning and real-world tradeoffs in the full article:
https://www.gperrucci.com/en/blog/react/assert-non-existence-react-testing-library

The core rule (burn it into muscle memory)

Use queryBy* + not.toBeInTheDocument() for absence.

import { screen } from "@testing-library/react";
import "@testing-library/jest-dom/extend-expect";
// Synchronous absence
expect(screen.queryByRole("dialog", { name: /profile/i })).not.toBeInTheDocument();

// TestID fallback when no accessible role/name fits
expect(screen.queryByTestId("role-icon")).not.toBeInTheDocument();

Why not getBy*? Because getBy* throws if nothing is found, so your test never reaches the matcher.

Don’t confuse absence with invisibility

• not.toBeInTheDocument() ⇒ the node doesn’t exist in the DOM.
• not.toBeVisible() ⇒ the node exists but is hidden (CSS or ARIA).

Use the one that matches your intent:

// Exists but hidden:
expect(screen.getByRole("dialog", { hidden: true })).not.toBeVisible();

// Truly gone:
expect(screen.queryByRole("dialog")).not.toBeInTheDocument();

When something should disappear after an action

Animation or async state updates can make tests flaky if you assert too early. Tie the wait to the actual node.

import { waitForElementToBeRemoved } from "@testing-library/react";
import userEvent from "@testing-library/user-event";

await userEvent.click(screen.getByRole("button", { name: /close/i }));

await waitForElementToBeRemoved(() =>
  screen.queryByRole("dialog", { name: /settings/i })
);
expect(screen.queryByRole("dialog", { name: /settings/i })).not.toBeInTheDocument();

Fallback if your component toggles visibility before unmounting:

import { waitFor } from "@testing-library/react";

await userEvent.keyboard("{Escape}");
await waitFor(() => {
  expect(screen.queryByRole("dialog")).not.toBeInTheDocument();
});

Prefer accessible queries; use data-testid only when needed

Accessible queries mirror how users (and assistive tech) experience your UI and reduce brittle tests.

// Better:
expect(screen.queryByRole("menu")).not.toBeInTheDocument();

// Acceptable fallback:
expect(screen.queryByTestId("user-menu")).not.toBeInTheDocument();

Common anti-patterns (and fixes)

getBy* for absence

// ❌ Throws before matcher
expect(screen.getByTestId("x")).not.toBeInTheDocument();

// ✅
expect(screen.queryByTestId("x")).not.toBeInTheDocument();

findBy* with negation (await screen.findBy…; expect(...).not)

This waits for something to appear, then negates it. Slow and misleading.
Use waitForElementToBeRemoved or waitFor when asserting disappearance.

Array length checks

// ❌ Brittle & throws when empty
expect(screen.getAllByRole("menu").length).toBe(0);

// ✅ Clear intent
expect(screen.queryByRole("menu")).not.toBeInTheDocument();

Using visibility to prove absence

toBeVisible() tests CSS, not DOM presence. If the requirement is “it’s gone,” assert non-existence.

Edge cases you should plan for

• Portals (modals, tooltips): Your queries still operate on document.body, but ensure your test environment renders portals like production. If you mount to a custom container, reflect that in setup.
• Transitions: Many UI libs keep nodes in the DOM during exit animations. First assert the transitional state (e.g., aria-hidden="true" or toBeVisible() false), then wait for removal.
• Live regions / alerts: If a banner announces (e.g., role="alert") and should vanish, wait for removal rather than using arbitrary timeouts.
• Hidden content searches: If you intentionally need to include hidden nodes in a query, pass { hidden: true }—but don’t conflate this with absence.

A tiny decision guide

• Expect missing now?
  expect(screen.queryByRole(...)).not.toBeInTheDocument()
• Expect to disappear after user action?
  await waitForElementToBeRemoved(() => screen.queryByRole(...))
• Expect hidden but mounted?
  expect(screen.getByRole(..., { hidden: true })).not.toBeVisible()

Wrap-up

• Presence ⇒ getBy*
• Absence ⇒ queryBy* + not.toBeInTheDocument()
• Disappearance ⇒ waitForElementToBeRemoved (or waitFor)
• Prefer accessible queries; use TestIDs only when necessary
• Don’t test CSS when you mean DOM

Stop Testing Ghosts: Test Non-Existence with React Testing Library was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comparative Analysis of Error Tracking & Performance Monitoring Tools

Tool Summaries

• Sentry: Offers robust error tracking with detailed stack traces and performance monitoring. Suitable for teams that prioritize deep error insights.
• Rollbar: Provides real-time error tracking with intelligent grouping, aiding in rapid issue resolution. Ideal for teams emphasizing quick error detection.
• Bugsnag: Focuses on application stability, offering real-time error tracking and stability scores. Beneficial for teams aiming to monitor and improve app stability.(StackShare)
• New Relic: Delivers comprehensive application performance monitoring, including infrastructure and user experience insights. Best suited for enterprises needing full-stack observability.(Walturn)
• Datadog: Provides extensive observability features, including APM, infrastructure monitoring, and security. Suitable for organizations requiring a unified monitoring platform.(Walturn)
• Atatus: Offers an all-in-one monitoring solution with error tracking, APM, and real user monitoring. Ideal for teams seeking comprehensive insights in a single platform.(Walturn)
• GlitchTip: An open-source alternative compatible with Sentry SDKs, offering basic error tracking and performance monitoring. Suitable for organizations preferring self-hosted solutions.(BetterStack)

✅ Recommendation

Considering the features and capabilities of the tools analyzed, Atatus emerges as a compelling choice for React applications. It offers a comprehensive suite of monitoring tools, including error tracking, performance monitoring, and real user monitoring, all within an easy-to-use platform. Its affordability and ease of setup make it accessible for teams of various sizes.

References

• 15 Best Sentry Alternatives For Error Tracking & Monitoring — Alerty
• Sentry vs Bugsnag: Choosing the Right Error Monitoring Tool
• New Relic vs Sentry — In-depth Comparison Guide [2025] | SigNoz
• 11 Best Error Tracking Tools in 2025 | Better Stack Community
• Rollbar vs Sentry | What are the differences? — StackShare
• The Top 5 Sentry Alternatives — AppSignal Blog

Analysis of Error Tracking & Performance Monitoring Tools was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

CSS mask-image is an exciting property that helps developers add creative visuals to websites without heavy graphic editing. Imagine shaping images, fading out text, or creating interactive visual effects directly through CSS—this is what mask-image offers.

You can read the full article: CSS `mask-image`: In-Depth Guide to Usage and Best Practices

.fade-image {
  width: 300px;
  height: 400px;
  background: url(https://medium.com/"./food.jpg") center/cover no-repeat;
  /* Apply a top-to-bottom gradient mask: fully opaque at top, transparent at bottom */
  mask-image: linear-gradient(to bottom, black 40%, transparent 100%);
  mask-size: 100% 100%;
  mask-repeat: no-repeat;
}

What Exactly is mask-image?

mask-image lets you control the visibility of parts of an element using images or gradients as masks. Areas covered by opaque mask pixels remain visible, while transparent areas become invisible. It's ideal for creating complex shapes or smooth transparency effects.

Why Use mask-image over clip-path?

While clip-path is great for simple shapes with sharp edges, mask-image shines when you need more sophisticated visual effects, like soft fades and intricate shapes. If you're creating something like a star-shaped photo or a gradient fade effect, mask-image is your tool.

Quick Example (React)

Here’s a practical example using React to toggle between different mask styles:Browser Compatibility

Modern browsers widely support CSS masks, but always include the WebKit prefix (-webkit-mask-image) to ensure compatibility with Safari and older browsers.

import React, { useState } from "react";
import "./styles.css";

function App() {
  const [maskShape, setMaskShape] = useState("circle");

  const handleShapeChange = (shape) => {
    setMaskShape(shape);
  };

  return (
    <div className="App">
      <div className="button-container">
        <button onClick={() => handleShapeChange("circle")}>Circle</button>
        <button onClick={() => handleShapeChange("rectangle")}>
          Rectangle
        </button>
        <button onClick={() => handleShapeChange("triangle")}>Triangle</button>
      </div>
      <div className="image-container">
        <svg width="0" height="0">
          <defs>
            <mask id="circle-mask" maskUnits="objectBoundingBox">
              <circle cx="400" cy="50" r="120" fill="#FFFFFF" />
              <circle cx="100" cy="50" r="120" fill="#FFFFFF" />
            </mask>
            <mask id="rectangle-mask" maskUnits="objectBoundingBox">
              <rect width="130" height="130" fill="#FFFFFF" />
              <rect width="130" height="130" y="120" x="120" fill="#FFFFFF" />
              <rect width="130" height="130" y="0" x="220" fill="#FFFFFF" />
              <rect width="130" height="130" y="120" x="320" fill="#FFFFFF" />
            </mask>
            <mask id="triangle-mask" maskUnits="objectBoundingBox">
              <polygon points="200,0 0,85 200,205" fill="#FFFFFF" />
              <polygon points="400,0 200,85 400,205" fill="#FFFFFF" />
            </mask>
          </defs>
        </svg>
        <img
          src="chessboard.webp"
          alt="Masked"
          className={`masked-image ${maskShape}`}
        />
      </div>
    </div>
  );
}

export default App;

.App {
  text-align: center;
}

.button-container {
  margin: 20px;
}

.image-container {
  display: inline-block;
  position: relative;
}

.masked-image {
  width: 500px;
  transition: mask-image 0.5s ease-in-out;
}

.masked-image.circle {
  -webkit-mask-image: url(#circle-mask);
  mask-image: url(#circle-mask);
}

.masked-image.rectangle {
  -webkit-mask-image: url(#rectangle-mask);
  mask-image: url(#rectangle-mask);
}

.masked-image.triangle {
  -webkit-mask-image: url(#triangle-mask);
  mask-image: url(#triangle-mask);
}

Dive Deeper

For an extensive exploration, practical comparisons, interactive examples, and best practices (including performance tips), check out the complete CSS mask-image guide.

References & Documentation

• MDN Web Docs
• W3C CSS Masking Specification

Creative Web Design with CSS mask-image in 3 Minutes was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.

Understanding core JavaScript concepts is essential for acing a junior developer interview. This article covers common interview questions, providing explanations and code snippets to illustrate each concept.

1. What is the difference between var, let, and const?

var declares a function-scoped or globally-scoped variable, while let and const are block-scoped. const also prevents reassignment of the variable. Variables declared with var can be re-declared in the same scope and attach to the global object when declared globally, which may cause unexpected behavior. In contrast, let and const throw errors when re-declared in the same block and remain block-scoped.

var globalVar = 'old';
if (true) {
  var globalVar = 'new'; // Re-declared in the same scope
  let blockLet = 'block';
  const blockConst = 'constant';
}
console.log(globalVar); // 'new'

Sources:

• MDN: var
• MDN: let
• MDN: const

2. Explain hoisting.

Hoisting is JavaScript’s behavior of moving declarations to the top of their scope before code execution. Function declarations and variable declarations using var are hoisted, whereas let and const are not initialized until the code executes. During hoisting, declarations are moved but assignments stay in place. Calling a variable before assignment returns undefined. Only function declarations are fully hoisted, while function expressions and arrow functions behave like variables.

console.log(a); // undefined
var a = 5;

Source:

• MDN: Hoisting

3. What are closures?

A closure occurs when a function retains access to its lexical scope even when executed outside that scope. Closures are commonly used for data privacy and creating factory functions. This ability to remember the surrounding scope allows functions to maintain private variables, enabling patterns like once functions, memoization, and currying.

function makeCounter() {
  let count = 0;
  return function () {
    count++;
    return count;
  };
}

const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2

Source:

• MDN: Closures

4. What is event bubbling?

Event bubbling is the propagation of events from the deepest target element upward through the DOM tree. You can stop propagation with event.stopPropagation(). Events first trigger on the innermost element, then bubble up to ancestors unless the handler stops propagation. The opposite phase is event capturing, which triggers handlers from the root down before the bubbling phase.

<div id="outer">
  <button id="inner">Click me</button>
</div>

const outer = document.getElementById('outer');
const inner = document.getElementById('inner');

outer.addEventListener('click', () => console.log('Outer clicked'));
inner.addEventListener('click', e => {
  console.log('Inner clicked');
  // e.stopPropagation(); // Uncomment to stop bubbling
});

Source:

• MDN: Event Bubbling

5. How do promises and async/await handle asynchronous code?

Promises represent the eventual result of an asynchronous operation. async/await simplifies promise-based code by allowing asynchronous logic to be written in a synchronous style. They provide methods like then and catch for chaining actions once the asynchronous task finishes or fails. When used with async functions, you can handle errors using try/catch, making asynchronous code easier to read.

function fetchData() {
  return new Promise(resolve => {
    setTimeout(() => resolve('Done'), 1000);
  });
}

async function run() {
  const result = await fetchData();
  console.log(result); // 'Done'
}

run();

Sources:

• MDN: Promise
• MDN: async function

6. What are the primitive data types in JavaScript?

JavaScript has seven primitive data types: string, number, bigint, boolean, undefined, symbol, and null. These types are immutable, meaning their values cannot be changed once created. Non-primitive types like objects and arrays are mutable and passed by reference.

const name = 'Jane';
const age = 30;
const big = 123n;
const active = true;
let unknown;
const id = Symbol('id');
const empty = null;

Source:

• MDN: Data types

7. How does this work in JavaScript?

this is determined by how a function is called. In the global context, this refers to the global object (window in browsers). Inside an object method, this refers to that object. Arrow functions do not have their own this; they inherit it from the surrounding scope. Methods like call, apply, and bind can explicitly set the this value.

const obj = {
  value: 42,
  regular() {
    console.log(this.value); // 42
  },
  arrow: () => {
    console.log(this.value); // undefined in most cases
  },
};

obj.regular();
obj.arrow();

Source:

• MDN: this

8. What is the difference between == and ===?

== compares values after performing type coercion, which can lead to unexpected results. === checks both value and type without coercion, making it the preferred choice for most comparisons.

0 == '0'; // true
0 === '0'; // false

Source:

• MDN: Equality comparisons

9. Explain the event loop in JavaScript.

The event loop handles asynchronous operations by coordinating the call stack and task queues. When the stack is empty, the loop processes messages from the queue, executing callbacks. Promises use the microtask queue, which has priority over the macrotask queue used by setTimeout.

console.log('start');
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('end');
// Output: start, end, promise, timeout

Source:

• MDN: Event loop

10. What is destructuring assignment?

Destructuring allows extracting values from arrays or properties from objects into distinct variables, making code more concise and readable.

const [first, second] = [1, 2];
const { name, age } = { name: 'Jane', age: 30 };

Source:

• MDN: Destructuring assignment

References

• MDN Web Docs — Comprehensive JavaScript documentation.
• JavaScript.info — Tutorials and explanations on core JavaScript concepts.
• JavaScript.info — Tutorials and explanations on core JavaScript concepts.

JavaScript Junior Interview Questions Explained was originally published in Javascript & Render on Medium, where people are continuing the conversation by highlighting and responding to this story.