Forem: Elvis Sautet

Next.js Finally Has Competition

Elvis Sautet — Sun, 15 Feb 2026 12:56:32 +0000

Next.js made React easy. TanStack Start made React feel like React again.

If you're picking a framework for something real in February 2026, this is the article I wish someone had written for me. Not a feature matrix. Not a "both are great" dodge. I did the research so you don't have to redo it. Every number is sourced. Every claim is verifiable. You'll know exactly which framework to pick by the end, and it'll be different depending on what you're building.

Next.js 16.1.6. TanStack Start 1.159.5 RC. Current as of today.

The five-year answer is dead

For five years, there was one answer. Someone asks "what React framework should I use?" and you say Next.js. Meeting over.

That answer worked because it was true. Next.js gave you file-based routing, server-side rendering, image optimization, and a deployment story so smooth it felt illegal. Vercel made the framework, Vercel ran the hosting, and the DX was great. You shipped, it worked, you moved on with your life.

Then in 2023, the App Router replaced the Pages Router, and React Server Components became the default mental model. Every component became a Server Component unless you opted out with "use client". Server Actions let you write backend logic inside frontend files. Three separate caching layers ran automatically under the hood. The promise was incredible: less JavaScript shipped to the browser, faster page loads, simpler data fetching.

The reality was different.

A GitHub discussion titled "With the new App Router, are people putting 'use client' everywhere?" has been open since 2023. People are still commenting on it in 2026. The most common complaint isn't that Server Components don't work. It's that developers can't predict when their code runs on the server and when it runs in the browser. The boundary between the two environments is invisible until it breaks.

Next.js 16 fixed the caching problem. All dynamic code now runs at request time by default. You opt into caching explicitly with the new "use cache" directive. This is a massive improvement over the old implicit caching that confused everyone. Credit where it's due: Vercel listened and fixed the biggest pain point.

But the architectural tension remains. Your app is split into two execution environments, and you're responsible for managing the boundary between them. Some developers thrive in this model. Others spend more time debugging serialization errors than building features.

Meanwhile, in Utah, a furniture-making open source developer had a different idea.

The most mass-adopted solo developer in React history

Tanner Linsley built React Query. That library that replaced your 200-line Redux saga with 5 lines of useQuery and just worked. Before React Query, managing server state in React was a pain that entire teams spent weeks solving poorly. After React Query, it was a solved problem. 12 million weekly downloads. Used at Apple, Google, Netflix, Amazon, Walmart.

Same person built React Table. Same person built React Virtual. Same person built TanStack Router, which quietly became the most type-safe router in the React ecosystem. 13 open source projects, 112,660 GitHub stars across them, over 4 billion total downloads. 1.3 million repositories depend on his code.

Two years ago, he went full-time on open source. Built a team of 36 contributors. Funds them properly. Ships at a pace that shouldn't be possible for an independent project.

TanStack Start is his full-stack React framework. Built on TanStack Router and Vite. The philosophy is simple: your code should be explicit about what runs where, types should catch errors before runtime does, and you shouldn't need a $500/month hosting platform to serve a React app.

It's still a Release Candidate. That matters, and I'll explain exactly how much.

The code tells the real story

Here's a dashboard page in Next.js 16:

// app/dashboard/page.tsx
export default async function Dashboard() {
  const stats = await db.getStats()
  return <StatsView data={stats} />
}

Clean. The component fetches data on the server. No loading state, no useEffect, no state management. The component IS the data layer. This is Server Components at their absolute best, and it's a real achievement in developer experience.

But now your PM says the dashboard needs a filter button.

You can't add useState to this file. Server Components don't support hooks. So you create a new file:

// app/dashboard/stats-view.tsx
'use client'

import { useState } from 'react'

export function StatsView({ data }) {
  const [filter, setFilter] = useState('all')
  const filtered = data.filter(d => filter === 'all' || d.type === filter)
  return (
    <>
      <button onClick={() => setFilter('revenue')}>Revenue</button>
      <DataTable rows={filtered} />
    </>
  )
}

One useState and you need a separate file, a "use client" directive, and an understanding of serialization boundaries. The data prop crossed from server to client, which means it was serialized as JSON, which means you can't pass functions, Dates, Maps, Sets, or class instances through it. If your stats object had a Date field, it arrived as a string. If it had a method, it vanished.

The more interactive your app gets, the more files carry "use client", and the less Server Components actually help you. For content-heavy pages with minimal interactivity, this model is brilliant. For dashboards, admin panels, data-heavy apps? You're fighting the architecture more than leveraging it.

Same page in TanStack Start:

// routes/dashboard.tsx
import { createFileRoute } from '@tanstack/react-router'
import { createServerFn } from '@tanstack/react-start'
import { useState } from 'react'

const getStats = createServerFn({ method: 'GET' })
  .handler(async () => {
    return db.getStats()
  })

export const Route = createFileRoute('/dashboard')({
  loader: () => getStats(),
  component: Dashboard,
})

function Dashboard() {
  const stats = Route.useLoaderData()
  const [filter, setFilter] = useState('all')
  const filtered = stats.filter(d => filter === 'all' || d.type === filter)

  return (
    <>
      <button onClick={() => setFilter('revenue')}>Revenue</button>
      <DataTable rows={filtered} />
    </>
  )
}

One file. The server function is explicitly declared. The component is a normal React component that uses any hook it wants. There's no invisible boundary. When the page loads, the loader runs getStats() on the server, hydrates the result, and the component renders with full interactivity from the start.

You didn't have to think about which execution environment you're in. The server function runs on the server because you said so. Everything else runs wherever React runs. There's nothing to debug because there's nothing hidden.

Now here's the part nobody writes about: the TypeScript experience.

In Next.js, params in a dynamic route come as Promise<{ id: string }> since version 15. Search params are untyped strings. If your route is /users/[id] and someone navigates to /users/abc when your code expects a number, you find out at runtime.

In TanStack Start, route params are inferred from the file path and validated at the route level. Search params get full Zod validation. If your loader expects params.id as a number, TypeScript catches string at compile time. If your search params need ?page=number&sort=string, you define the schema once and every component that reads those params gets autocomplete, validation, and error handling for free.

This isn't a nice-to-have. This is the difference between catching a bug in your editor and catching it in production at 2am.

And the middleware story makes the gap wider. TanStack Start middleware works at both the request level and the server function level, on both client and server. You chain middleware together and each layer passes typed context to the next. Your auth middleware validates a session and provides a user object. Your permissions middleware receives that typed user and checks access. Your logging middleware receives both. Every layer has full type inference. No any casts. No runtime surprises.

const authMiddleware = createMiddleware().server(async ({ next }) => {
  const user = await validateSession()
  if (!user) throw redirect({ to: '/login' })
  return next({ sendContext: { user } })
})

const getProtectedData = createServerFn({ method: 'GET' })
  .middleware([authMiddleware])
  .handler(async ({ context }) => {
    // context.user is fully typed here. No cast needed.
    return db.getData(context.user.id)
  })

In Next.js 16, middleware.ts was renamed to proxy.ts. It runs at the network edge, before your application code. It can't access your database, can't run server-side logic, and has a fundamentally different execution model from your route handlers. For anything beyond redirects and header manipulation, you need Server Actions or API routes, which are separate concepts with separate mental models.

The SEO myth that won't die

This is the section that saves people the most time, because the #1 reason developers default to Next.js without thinking is SEO. The assumption goes: Next.js does SSR and static generation, Google loves it, and TanStack Start is the new kid so it probably can't compete. Right?

Wrong. And it's not even close to right.

TanStack Start ships with full SSR enabled by default. When Googlebot hits your page, it receives completely rendered HTML with all your content visible. No JavaScript execution required for crawling. This is the same thing Next.js does. The HTML arrives complete from the server.

But let me show you what TanStack Start's SEO tooling actually looks like, because nobody talks about this:

export const Route = createFileRoute('/posts/$postId')({
  loader: async ({ params }) => {
    const post = await fetchPost(params.postId)
    return { post }
  },
  head: ({ loaderData }) => ({
    meta: [
      { title: loaderData.post.title },
      { name: 'description', content: loaderData.post.excerpt },
      { property: 'og:title', content: loaderData.post.title },
      { property: 'og:image', content: loaderData.post.coverImage },
      { name: 'twitter:card', content: 'summary_large_image' },
    ],
    scripts: [
      {
        type: 'application/ld+json',
        children: JSON.stringify({
          '@context': 'https://schema.org',
          '@type': 'Article',
          headline: loaderData.post.title,
          author: { '@type': 'Person', name: loaderData.post.author.name },
          datePublished: loaderData.post.publishedAt,
        }),
      },
    ],
  }),
  component: PostPage,
})

That's meta tags, Open Graph, Twitter Cards, AND JSON-LD structured data, all driven by typed loader data, all rendered server-side before the page hits the browser. The head function receives the same typed loaderData your component gets, so your SEO metadata is always in sync with your page content. No separate data fetch for meta tags. No chance of the title saying one thing while the page shows another.

TanStack Start also has static prerendering and automatic sitemap generation:

// vite.config.ts
tanstackStart({
  prerender: {
    routes: ['/blog', '/blog/posts/*'],
    crawlLinks: true,  // discovers all linked pages automatically
  },
  sitemap: {
    enabled: true,
    host: 'https://yoursite.com',
  },
})

Static HTML pages at build time. Automatic link crawling to find every route. Generated sitemap.xml. And ISR (Incremental Static Regeneration) using standard HTTP cache headers that work with any CDN. Not just Vercel's.

TanStack Start even has LLMO documentation (LLM Optimization) for the AI search era. As traffic from Perplexity, ChatGPT search, and Google AI Overviews grows, the docs show how to structure content for AI crawlers, including llms.txt support, the AI equivalent of robots.txt. Next.js doesn't have this in their docs yet.

So where does Next.js actually have a real SEO edge? Two specific places.

First, next/image. Automatic responsive images, format conversion to WebP/AVIF, lazy loading, and built-in CDN delivery. Image-heavy sites get measurably better Core Web Vitals. TanStack Start has no image component. You'll use Cloudflare Image Resizing, imgproxy, or a similar third-party service. It works, but it's not zero-config.

Second, Partial Prerendering. Next.js 16 can serve a static shell instantly while streaming dynamic content into Suspense boundaries. The static parts hit the browser before the server finishes computing the dynamic bits. For content sites with some personalization (user avatar in the corner, live comments below a static article), this is a real performance win that TanStack Start can't match today.

But for the actual SEO fundamentals (server-rendered HTML, meta tags, structured data, sitemaps, static generation, ISR), the two frameworks are at parity. If someone tells you TanStack Start is bad for SEO, they haven't looked at it since 2024.

The numbers nobody argues with

I'm pulling from four sources: GitHub issues with reproduction repos, the Inngest engineering blog (a real company that migrated), Vercel's own documentation, and heap snapshots from open issues.

Dev server memory.

Next.js dev server starts around 300MB on a medium-sized app. As you navigate routes, it climbs. GitHub issue #78069 documents it growing to 9-10GB. Issue #54708 has 141 thumbs-up and has been open since August 2023. Turbopack in Next.js 16 made builds significantly faster (2-5x, and it's real), but the memory climb during development is still reported in January 2026 issues.

TanStack Start dev server sits at roughly 200MB and stays there. Vite does almost nothing at startup. It only transforms files when you request them.

This matters if you're on a laptop. This matters a lot if your team is in Nairobi or Lagos on 8GB machines where the dev server competing with Chrome and Figma means constant swapping.

Production memory.

This is where it gets serious. GitHub issue #88603, filed January 2026 against Next.js 16.1.0, documents memory leaks causing OOM crashes in Docker and Kubernetes. Linear memory growth over hours until the pod gets killed and restarts. Issue #85914 from November 2025 reproduces it with just output: standalone and a single fetch call. The reporter tested Node 20, 22, and 24. Same behavior on all versions.

There are currently 6 open GitHub discussions about Next.js memory leaks in containerized environments, spanning from 2021 to January 2026. The pattern is the same: memory grows linearly, garbage collection doesn't reclaim it, pods restart.

I haven't found equivalent reports for TanStack Start. That's likely because fewer people run it in production. But the thinner runtime (no RSC protocol, no flight format, no custom serialization layer) means less surface area for leaks. Take that with the context it deserves.

Build speed.

Turbopack is legitimately fast. 2-5x faster builds than Webpack. This is one of Next.js 16's biggest wins and the numbers hold up. The filesystem caching is excellent too. Restarts are near-instant when the cache is warm.

TanStack Start uses Vite, which was already fast. Build times are comparable. Neither framework will bottleneck your CI pipeline in 2026.

Bundle size.

Next.js baseline is around 92KB gzipped. With Server Components, pages that are mostly static content can ship significantly less JavaScript because component code stays on the server.

TanStack Start baseline is around 42KB. Everything hydrates on the client, so more JavaScript ships, but the total is still smaller because there's no RSC runtime overhead, no flight protocol, no serialization layer.

For content sites where Server Components shine, Next.js ships less JS. For interactive apps where most components end up as "use client" anyway, TanStack Start ships less. Know your app before you optimize.

Real migration data.

Inngest, a developer tools company, published their migration story in early 2026. Before, on Next.js: 10-12 second local page loads on every route. After, on TanStack Start: 2-3 seconds on first load, instant on subsequent routes. Migration took 2 weeks with 1 engineer using AI assistance. The quote that circled their Slack: "I cannot believe how snappy it is."

Another team documented a 60% reduction in build times after migrating a production app from Next.js 16, along with eliminating hydration errors entirely.

Two data points, not a trend. But they're consistent with what the architecture predicts.

The security incident you need to know about

In December 2025, CVE-2025-55182 was assigned to the React Server Components protocol. CVSS score: 10.0 out of 10. Maximum severity. Unauthenticated remote code execution affecting all Next.js App Router deployments.

Six CVEs total in two months, all related to the RSC implementation.

This was patched. If you're on Next.js 16.1.6, you're safe. But it exposed something about the architectural difference between these frameworks that matters for your risk calculation.

React Server Components add a protocol layer between client and server. That layer has a serialization format, a transport mechanism, and a trust boundary. Every protocol layer is attack surface. This isn't a criticism of the Next.js team's security practices. It's structural: more moving parts means more things that can break.

TanStack Start uses plain HTTP for server functions. Standard request/response. The attack surface is the same as any Express or Fastify server. No custom protocol. No flight format. No novel serialization.

If you're in a regulated industry, if you have compliance requirements, or if your threat model involves more than script kiddies, this difference deserves weight.

The money

Vercel Pro costs $20/user/month plus usage. A team of 5 pays $100/month before a single visitor hits the site. At meaningful traffic, costs climb. Teams at scale report $500-2,000+ monthly.

Next.js works fine on other platforms. AWS, Railway, Fly.io, a VPS. But the smoothest DX, the features that work without configuration, the zero-thought deployments are optimized for Vercel. This is how Vercel makes money. They built a great framework and a great hosting platform and designed them to work best together. Legitimate business model. Just know it's part of the deal.

TanStack Start deploys to anything that runs Node. A $24/month Hetzner VPS handles surprising traffic. Cloudflare CDN on the free tier covers most apps. Production setup for under $30/month.

At the same scale where teams spend $500+/month on Vercel, self-hosted TanStack Start runs for $100-400/month. Over a year, that's $5,000-20,000. Over three years with growth, $50,000-200,000.

But self-hosting means you handle deployments, monitoring, SSL, and incidents yourself. If you have 2 engineers and no DevOps experience, Vercel's premium buys you time. If you have infrastructure people, the savings are serious.

Where Next.js wins and it's not close

Content-driven sites. Blog, marketing site, e-commerce catalog, docs, anything where pages are mostly text and images with light interactivity. As I covered in the SEO section, both frameworks handle the fundamentals equally well. But Server Components give Next.js an edge that matters: pages load with zero JavaScript for static parts. The "use cache" directive makes caching explicit and clean. Partial Prerendering serves a static shell instantly while streaming dynamic bits in. For content where milliseconds of load time affect conversion rates, this is a real advantage TanStack Start can't match today.

Ecosystem. TikTok, Nike, Hulu, Target, The Washington Post. Next.js runs at scales TanStack Start hasn't seen. If something breaks, there's a Stack Overflow answer. Hiring is easier because every React developer has at least some Next.js experience. Integration libraries exist for everything. Years of battle scars that you inherit for free.

Image pipeline. next/image handles responsive sizing, lazy loading, format conversion, and CDN delivery automatically. TanStack Start has no equivalent. For image-heavy sites, this alone could justify Next.js.

Stability. Next.js 16 is a stable release. TanStack Start is a Release Candidate. The API is frozen and Tanner has committed to no breaking changes before 1.0. But RC means fewer production deployments, fewer edge cases discovered, fewer battle scars. If you need to tell your CTO "this is production-proven," Next.js is the honest answer.

Full stop.

Where TanStack Start wins and it's not close

Interactive apps. Dashboards, admin panels, internal tools, anything where users interact more than they read. In these apps, nearly every component needs client-side state, which means "use client" on nearly everything in Next.js, which means Server Components aren't helping. TanStack Start gives you full React everywhere without fighting an architecture designed for a different use case.

Type safety. Not a preference. A capability gap. Validated typed route params. Typed search params with Zod schemas. Typed loader data flowing from server to component without a single as cast. Typed middleware chains with context inference across layers. In Next.js, params are async Promises and search params are untyped strings. For large apps, this prevents entire categories of production bugs.

Dev experience on real hardware. If your dev server eats 6-10GB of RAM, that's the difference between running your app alongside Chrome and Figma, or running it alone and waiting. TanStack Start's ~200MB footprint keeps your machine responsive. For teams where 8GB or 16GB machines are the standard, this is the difference between productive and frustrated.

Deployment freedom. Node, Deno, Bun, Cloudflare Workers, any VPS, any container platform. No hosting provider gets preferential treatment. The framework doesn't care where you run it. For teams that want to own their infrastructure, this converts directly to money saved.

Middleware. Composable, typed, works at request level and server function level, on both client and server. Auth middleware provides a typed user to permissions middleware which provides typed access to data middleware. Every layer fully inferred. No any. In Next.js, proxy.ts runs at the edge with a different execution model from your route handlers. For complex backend logic, TanStack Start's middleware is the more powerful primitive.

No contest.

Five questions that decide your framework

Stop reading comparisons. Answer these.

1. Is your app mostly reading or mostly interacting?

Users primarily consume content -> Next.js. Server Components eliminate JavaScript for static content. Real advantage.

Users primarily interact with the UI -> TanStack Start. You'll put "use client" on everything in Next.js anyway.

2. How big is your team?

Under 5 developers, no DevOps -> Next.js + Vercel. Deployment convenience is worth the premium.

Team already manages infrastructure -> TanStack Start. Hosting savings fund a junior dev's salary.

3. Are you invested in TanStack already?

Using React Query + Router + Table -> TanStack Start is a natural extension. Same team, same philosophy, same types.

Starting fresh -> Next.js has the gentler learning curve and more help available when you're stuck.

4. Can you ship on a Release Candidate?

Need to tell stakeholders "version 1.0, production-proven" -> Next.js.

Comfortable with RC status, can read source when docs don't cover your edge case -> TanStack Start rewards the bet with a better architecture for interactive work.

5. What's your hosting budget?

Tight, need cost control -> TanStack Start on a VPS. $30-100/month goes far.

Flexible, want zero infrastructure thinking -> Next.js on Vercel. Worth every dollar.

What happens next

TanStack Start 1.0 is imminent. Frozen API, stable RC for months. When it ships, the "not production-ready" argument disappears and this becomes a pure technical decision.

RSC support is planned for TanStack Start post-1.0. When that lands, it gets the content-site advantages without the architectural complexity. That changes everything.

If you're productive on Next.js today, nothing here means you should migrate. But if you've felt the friction, if you've debugged a serialization boundary or watched your dev server consume more RAM than your production server or wondered why you can't use a basic React hook in half your files, now you know there's an alternative that solves exactly those problems.

Pick the one that matches what you're building. Not what's trending. What fits.

If this saved you a week of research, buy me a coffee. If you want more like this, I'm @elvisautet on X.

Cron Jobs vs Real Task Schedulers: A Love Story

Elvis Sautet — Tue, 25 Nov 2025 12:32:24 +0000

Hey folks. I know, I know, another long post. But if you've been following
along, you know I only write these when I've actually lived through the pain.

Today's about task scheduling. Specifically, about a problem I've spent way too much time solving in production.

You know that feeling when your startup grows from handling hundreds of tasks to millions, and suddenly your "simple cron job solution" is costing you thousands in Redis memory? Yeah, I've been there.

Today I want to walk through building a proper task scheduler – the kind that companies like Stripe, Airbnb, and Uber actually use in production. Not the toy examples you see in tutorials, but something you can actually deploy on Friday and sleep well over the weekend.

The Problem with Traditional Cron
Why Big Tech Uses a Two-Tier Architecture
The Architecture We're Building
Understanding the Queue Layer
The Intelligent Router: The Brain of the System
Implementing the Three Task Types
The Database Schema That Scales
Building the Scheduler
Worker Implementation
Putting It All Together
Production Considerations
What I Learned the Hard Way

The Problem with Traditional Cron

Let me start with what doesn't work. A lot of developers (including past me) start with something like this:

// Don't do this in production
cron.schedule('0 9 * * *', async () => {
  await sendDailyReports();
});

This works great until it doesn't. Here's what breaks:

Problem 1: No persistence. Your server restarts, all scheduled tasks are gone. I once lost 10,000 subscription renewal reminders because someone deployed during a scheduled task window. Not fun explaining that to the finance team.

Problem 2: Single point of failure. One cron job fails, you have no idea unless you're watching logs. One server dies, all your scheduled tasks stop.

Problem 3: Can't handle dynamic scheduling. User signs up, you want to send them an email in 7 days. Good luck adding that to crontab programmatically.

Problem 4: No priority system. Your payment processing cron and your "cleanup old logs" cron compete for the same resources.

Problem 5: Terrible at scale. Need to schedule a million tasks? Hope you have a lot of RAM and patience.

I learned this the hard way at my last job. We were using node-cron for everything. Hit 100k users, suddenly our server was using 4GB of RAM just tracking scheduled tasks. Redis costs were approaching $800/month. Something had to change.

Why Big Tech Uses a Two-Tier Architecture

After diving into how Stripe handles subscription billing for millions of customers and how Airbnb manages booking reminders, I noticed a pattern. They all use what I call the "two-tier architecture."

Here's the insight: most scheduled tasks are in the far future. Why keep them in expensive, fast memory when they won't execute for days or weeks?

The Two Tiers:

Cold Storage (PostgreSQL): Cheap persistent storage. Stores ALL tasks, even ones scheduled months away. At $0.10/GB/month, you can store millions of tasks for pennies.
Hot Queue (Redis): Fast execution queue. Only holds tasks executing within 24-48 hours. At $10/GB/month, you only pay for what's actively being processed.

The magic is the scheduler that moves tasks from cold to hot as their execution time approaches.

Let me show you the cost difference. Say you have 10 million scheduled tasks:

All in Redis:

10GB of data
At $10/GB/month = $100/month
Plus Redis is volatile, so you need persistence setup
Risk of data loss on restart

Two-tier approach:

PostgreSQL: 10GB at $0.10/GB = $1/month
Redis: 0.5GB (only next 24 hours) at $10/GB = $5/month
Total: $6/month
Full persistence, no data loss risk

Savings: 94%

That's not a typo. This is why Stripe can handle millions of subscription renewals without bankrupting themselves on infrastructure.

The Architecture We're Building

Before we dive into code, let me show you the high-level architecture:

┌─────────────────────────────────────────────────────────┐
│  Your Application                                       │
│  smartAPI.scheduleTask({...})                          │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
            ┌────────────────┐
            │ Intelligent    │
            │ Router         │  ← Decides where task goes
            └───────┬────────┘
                    │
        ┌───────────┼───────────┐
        │           │           │
        ▼           ▼           ▼
   Immediate     Hot         Cold
   < 15 min    < 24 hrs   > 24 hrs
        │           │           │
        ▼           ▼           │
    ┌──────┐   ┌──────┐        │
    │Redis │   │Redis │        │
    └───┬──┘   └───┬──┘        │
        │          │            │
        └────┬─────┘            │
             ▼                  ▼
        ┌─────────┐      ┌──────────┐
        │ Workers │      │PostgreSQL│
        │Execute  │      │(waiting) │
        └─────────┘      └─────┬────┘
                                │
                         Scheduler
                         (moves to Redis
                          when due)

The key components:

Smart API: Your interface. You just call scheduleTask() and forget about it.
Intelligent Router: Decides if task goes straight to Redis or waits in the database.
PostgreSQL: Cold storage. Holds all tasks.
Redis + BullMQ: Hot queue. Holds tasks ready to execute.
Scheduler: Runs every hour, moves tasks from PostgreSQL to Redis.
Workers: Execute tasks from Redis.

Understanding the Queue Layer

Let's talk about queuing systems because this is where a lot of people get stuck. We're using BullMQ with Redis, but you have options.

Why BullMQ + Redis?

BullMQ is fantastic for job queuing. Here's what sold me:

import { Queue, Worker } from 'bullmq';

// Create a queue
const emailQueue = new Queue('emails', {
  connection: { host: 'localhost', port: 6379 }
});

// Add a job with a delay
await emailQueue.add('welcome-email', {
  to: 'user@example.com',
  subject: 'Welcome!'
}, {
  delay: 3600000, // 1 hour in milliseconds
  attempts: 3,
  backoff: {
    type: 'exponential',
    delay: 5000
  }
});

// Process jobs
const worker = new Worker('emails', async job => {
  await sendEmail(job.data);
}, { connection: { host: 'localhost', port: 6379 } });

Pros:

Built-in retry logic with exponential backoff
Delayed jobs out of the box
Priority queues
Job progress tracking
Rate limiting
Automatic job cleanup
Great TypeScript support
Very active maintenance

Cons:

Requires Redis (another service to manage)
Memory usage can get high
No built-in persistence (Redis is in-memory)

Alternative 1: RabbitMQ

If you're already using RabbitMQ, you can use it instead:

import amqp from 'amqplib';

const connection = await amqp.connect('amqp://localhost');
const channel = await connection.createChannel();
await channel.assertQueue('tasks', { durable: true });

// Schedule a task
channel.sendToQueue('tasks', Buffer.from(JSON.stringify({
  taskType: 'email',
  payload: { to: 'user@example.com' }
})), {
  persistent: true,
  headers: { 'x-delay': 3600000 } // Requires delay plugin
});

Pros:

Message persistence built in
Excellent for microservices
Very mature ecosystem
Better for complex routing

Cons:

More complex to set up
Delayed messages require plugin
Heavier resource usage
Steeper learning curve

Alternative 2: AWS SQS + DynamoDB

If you're on AWS:

import { SQS } from 'aws-sdk';

const sqs = new SQS();

// Schedule a task
await sqs.sendMessage({
  QueueUrl: 'https://sqs.us-east-1.amazonaws.com/...',
  MessageBody: JSON.stringify({
    taskType: 'email',
    payload: { to: 'user@example.com' }
  }),
  DelaySeconds: 3600 // Max 15 minutes
});

Pros:

Fully managed, no maintenance
Scales infinitely
Cheap at scale
Built-in dead letter queues

Cons:

Max delay is 15 minutes (need DynamoDB + Lambda for longer)
Vendor lock-in
Costs add up with high message volume
Requires AWS

Alternative 3: Kafka

For event-driven architectures:

import { Kafka } from 'kafkajs';

const kafka = new Kafka({
  clientId: 'task-scheduler',
  brokers: ['localhost:9092']
});

const producer = kafka.producer();
await producer.connect();

await producer.send({
  topic: 'scheduled-tasks',
  messages: [{
    key: 'task-123',
    value: JSON.stringify({
      taskType: 'email',
      payload: { to: 'user@example.com' }
    }),
    timestamp: Date.now() + 3600000
  }]
});

Pros:

Excellent for high throughput
Message persistence and replay
Perfect for event sourcing
Scales horizontally

Cons:

Overkill for simple scheduling
Complex setup and maintenance
Delayed messages not native
High operational overhead

My Recommendation

For most applications, stick with BullMQ + Redis. Here's why:

Simple setup: Redis is easy to run and manage
Great developer experience: BullMQ API is intuitive
Rich features: Everything you need is built in
Battle-tested: Used by thousands of production apps
Performance: Fast enough for 99% of use cases

Only move to alternatives if:

You already have RabbitMQ (use it)
You're fully AWS (use SQS + Lambda)
You need Kafka-level throughput (rare)

The Intelligent Router: The Brain of the System

Now let's build the most important part: the router that decides where tasks go.

The logic is beautifully simple:

function routeTask(scheduledDate: Date): Route {
  const now = new Date();
  const minutesUntil = (scheduledDate - now) / (1000 * 60);
  const hoursUntil = minutesUntil / 60;

  // Task is overdue or due very soon (< 15 minutes)
  if (minutesUntil <= 15) {
    return {
      route: 'immediate',
      action: 'queue_to_redis_now',
      reason: 'Needs immediate execution'
    };
  }

  // Task is due soon (< 24 hours)
  if (hoursUntil <= 24) {
    return {
      route: 'hot',
      action: 'save_to_db_and_queue_to_redis',
      reason: 'Near future execution'
    };
  }

  // Task is far away (> 24 hours)
  return {
    route: 'cold',
    action: 'save_to_db_only',
    reason: 'Far future, scheduler will handle later'
  };
}

Let me walk through each path:

Path 1: Immediate (< 15 minutes)

// Task due in 5 minutes
scheduleTask({
  taskType: 'email',
  scheduledFor: new Date(Date.now() + 5 * 60 * 1000),
  payload: { to: 'user@example.com' }
});

// Router decision:
// "This is urgent, skip the database, go straight to Redis"
await queueToRedis(task, { delay: 5 * 60 * 1000 });

Why skip the database? Speed. Writing to PostgreSQL takes 50-100ms. Writing to Redis takes 1-5ms. For urgent tasks, every millisecond counts.

We still save it to the database asynchronously for audit purposes, but we don't wait for it.

Path 2: Hot (< 24 hours)

// Task due in 2 hours
scheduleTask({
  taskType: 'report',
  scheduledFor: new Date(Date.now() + 2 * 60 * 60 * 1000),
  payload: { reportType: 'sales' }
});

// Router decision:
// "Save to database for persistence, also queue to Redis"
await saveToDatabase(task);
await queueToRedis(task, { delay: 2 * 60 * 60 * 1000 });
await task.update({ status: 'queued' });

This is the belt-and-suspenders approach. We save to the database so if Redis crashes, we don't lose the task. We also queue it to Redis so it executes on time.

Path 3: Cold (> 24 hours)

// Task due in 30 days
scheduleTask({
  taskType: 'subscription_renewal',
  scheduledFor: new Date(Date.now() + 30 * 24 * 60 * 60 * 1000),
  payload: { subscriptionId: 'sub-123' }
});

// Router decision:
// "Too far away, just save to database"
await saveToDatabase(task);
// That's it! Scheduler will handle it later

This is the efficiency win. Why keep this in Redis for 30 days? It's not executing anytime soon. Save it to cheap PostgreSQL storage, and the scheduler will move it to Redis on day 29.

Implementing the Three Task Types

Real-world applications need more than just "run once" tasks. You need three types:

Type 1: One-Time Tasks

These execute once at a specific time. This is what we've been discussing.

await smartAPI.scheduleTask({
  taskType: 'email',
  taskName: 'Birthday Email',
  scheduledFor: '2025-12-25T09:00:00Z',
  payload: {
    to: 'user@example.com',
    subject: 'Happy Birthday!',
    template: 'birthday'
  },
  priority: 5
});

Implementation is straightforward. Store in database with status 'pending', router decides when to queue.

Type 2: Recurring Tasks

These run forever on a schedule. Like traditional cron, but persistent.

await smartAPI.scheduleRecurringTask({
  taskType: 'daily_report',
  taskName: 'Daily Sales Report',
  cronExpression: '0 9 * * *',  // Every day at 9 AM
  payload: {
    reportType: 'sales',
    emailTo: 'boss@company.com'
  },
  timezone: 'America/New_York',
  startDate: '2025-01-01',
  endDate: '2025-12-31'  // Optional
});

The trick here is maintaining state in the database:

// Database record
{
  id: 'task-123',
  scheduleType: 'recurring',
  cronExpression: '0 9 * * *',
  lastRunAt: '2025-11-23T09:00:00Z',
  nextRunAt: '2025-11-24T09:00:00Z',
  status: 'pending',
  enabled: true
}

The scheduler runs every minute, checking: "Is it time to run any recurring tasks?"

// Scheduler logic
async function checkRecurringTasks() {
  const dueTasks = await database.query(`
    SELECT * FROM scheduled_tasks
    WHERE schedule_type = 'recurring'
      AND enabled = true
      AND next_run_at <= NOW()
      AND (end_date IS NULL OR end_date >= NOW())
  `);

  for (const task of dueTasks) {
    // Queue to Redis for immediate execution
    await queueToRedis(task, { delay: 0 });

    // Calculate next run using cron-parser
    const nextRun = calculateNextRun(task.cronExpression);

    // Update database
    await task.update({
      lastRunAt: new Date(),
      nextRunAt: nextRun,
      status: 'pending'  // Reset for next run
    });
  }
}

The beauty is Redis crashes? No problem. The task definition is in PostgreSQL. The scheduler will queue it again.

Type 3: Repeating Tasks

These run N times with a fixed interval. Perfect for retry logic.

await smartAPI.scheduleRepeatingTask({
  taskType: 'payment_retry',
  taskName: 'Retry Failed Payment',
  intervalHours: 24,
  repeatCount: 5,  // Try 5 times
  payload: {
    paymentId: 'pay-123',
    amount: 29.99
  },
  priority: 10  // High priority
});

Implementation tracks execution count:

// Database record
{
  id: 'task-456',
  scheduleType: 'repeating',
  intervalMs: 86400000,  // 24 hours
  repeatCount: 5,
  executionCount: 2,  // Already tried twice
  nextRunAt: '2025-11-25T10:00:00Z',
  status: 'pending'
}

After each execution:

async function handleRepeatingTask(task) {
  // Execute the task
  await executeTask(task);

  // Increment counter
  task.executionCount += 1;

  // Done?
  if (task.executionCount >= task.repeatCount) {
    task.status = 'completed';
    await task.save();
    return;
  }

  // Schedule next run
  task.nextRunAt = new Date(Date.now() + task.intervalMs);
  task.status = 'pending';
  await task.save();
}

This is how Stripe handles payment retries. They don't set up 5 separate tasks. One task, configured to repeat.

The Database Schema That Scales

Let's talk about the database schema. This is crucial for performance at scale.

CREATE TABLE scheduled_tasks (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

  -- Task identification
  task_type VARCHAR(50) NOT NULL,
  task_name VARCHAR(255) NOT NULL,
  schedule_type VARCHAR(20) NOT NULL,  -- 'one_time', 'recurring', 'repeating'

  -- One-time fields
  scheduled_for TIMESTAMP,

  -- Recurring fields
  cron_expression VARCHAR(100),
  timezone VARCHAR(50) DEFAULT 'UTC',
  start_date TIMESTAMP,
  end_date TIMESTAMP,
  last_run_at TIMESTAMP,
  next_run_at TIMESTAMP,

  -- Repeating fields
  interval_ms BIGINT,
  repeat_count INTEGER,
  execution_count INTEGER DEFAULT 0,

  -- State
  status VARCHAR(20) NOT NULL DEFAULT 'pending',
  priority INTEGER DEFAULT 5,
  enabled BOOLEAN DEFAULT true,

  -- Data
  payload JSONB NOT NULL,
  metadata JSONB DEFAULT '{}',

  -- Execution tracking
  attempts INTEGER DEFAULT 0,
  max_attempts INTEGER DEFAULT 3,
  queued_at TIMESTAMP,
  started_at TIMESTAMP,
  completed_at TIMESTAMP,
  last_error TEXT,
  result JSONB,

  -- Multi-tenancy
  user_id UUID,
  tenant_id UUID,
  tags TEXT[],

  -- Timestamps
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

Now the critical part: indexes. These make or break performance.

-- THE MOST IMPORTANT INDEX
-- Scheduler queries this constantly
CREATE INDEX idx_status_scheduled_priority 
ON scheduled_tasks (status, scheduled_for, priority)
WHERE schedule_type = 'one_time';

-- For recurring task checks (every minute)
CREATE INDEX idx_recurring_due 
ON scheduled_tasks (schedule_type, enabled, next_run_at)
WHERE schedule_type IN ('recurring', 'repeating');

-- For finding user tasks quickly
CREATE INDEX idx_user_status 
ON scheduled_tasks (user_id, status);

-- For the scheduler's main query
CREATE INDEX idx_next_run_enabled
ON scheduled_tasks (next_run_at, enabled)
WHERE enabled = true;

With these indexes, querying 10 million tasks takes under 50ms. Without them, it can take 30+ seconds. Ask me how I know.

Here's the query the scheduler runs every hour:

-- Find one-time tasks ready to queue
SELECT * FROM scheduled_tasks
WHERE schedule_type = 'one_time'
  AND status = 'pending'
  AND scheduled_for >= NOW()
  AND scheduled_for <= NOW() + INTERVAL '24 hours'
ORDER BY priority DESC, scheduled_for ASC
LIMIT 10000;

With the index idx_status_scheduled_priority, PostgreSQL uses an index scan. Query time: 40ms for 10M rows.

Without the index? Sequential scan. Query time: 28 seconds. Your scheduler would fall behind immediately.

Building the Scheduler

The scheduler is the heart of the system. It runs periodically, moving tasks from cold storage to hot queue.

Here's the implementation:

class IntelligentScheduler {
  private isRunning = false;

  async run() {
    if (this.isRunning) {
      console.log('Scheduler already running, skipping...');
      return;
    }

    this.isRunning = true;
    console.log('Scheduler started at', new Date().toISOString());

    try {
      // Step 1: Handle overdue tasks (highest priority)
      await this.processOverdueTasks();

      // Step 2: Move near-future tasks to Redis
      await this.processUpcomingTasks();

      // Step 3: Process recurring tasks
      await this.processRecurringTasks();

    } catch (error) {
      console.error('Scheduler error:', error);
    } finally {
      this.isRunning = false;
    }
  }

  private async processOverdueTasks() {
    const overdue = await database.query(`
      SELECT * FROM scheduled_tasks
      WHERE schedule_type = 'one_time'
        AND status = 'pending'
        AND scheduled_for < NOW()
      ORDER BY priority DESC, scheduled_for ASC
      LIMIT 1000
    `);

    console.log(`Found ${overdue.length} overdue tasks`);

    for (const task of overdue) {
      // Queue immediately with high priority
      await queueToRedis(task, {
        delay: 0,
        priority: 10  // Override priority for overdue tasks
      });

      await task.update({ status: 'queued', queuedAt: new Date() });
    }
  }

  private async processUpcomingTasks() {
    const upcoming = await database.query(`
      SELECT * FROM scheduled_tasks
      WHERE schedule_type = 'one_time'
        AND status = 'pending'
        AND scheduled_for >= NOW()
        AND scheduled_for <= NOW() + INTERVAL '24 hours'
      ORDER BY priority DESC, scheduled_for ASC
      LIMIT 10000
    `);

    console.log(`Found ${upcoming.length} tasks due in next 24 hours`);

    for (const task of upcoming) {
      const delay = task.scheduledFor.getTime() - Date.now();

      await queueToRedis(task, { delay: Math.max(0, delay) });
      await task.update({ status: 'queued', queuedAt: new Date() });
    }
  }

  private async processRecurringTasks() {
    const due = await database.query(`
      SELECT * FROM scheduled_tasks
      WHERE schedule_type IN ('recurring', 'repeating')
        AND enabled = true
        AND next_run_at <= NOW()
        AND (end_date IS NULL OR end_date >= NOW())
      LIMIT 1000
    `);

    console.log(`Found ${due.length} recurring tasks due`);

    for (const task of due) {
      // Queue for immediate execution
      await queueToRedis(task, { delay: 0 });

      // Calculate next run
      if (task.scheduleType === 'recurring') {
        const nextRun = calculateNextCronRun(task.cronExpression);
        await task.update({
          lastRunAt: new Date(),
          nextRunAt: nextRun,
          status: 'pending'
        });
      } else if (task.scheduleType === 'repeating') {
        task.executionCount += 1;

        if (task.executionCount >= task.repeatCount) {
          await task.update({ status: 'completed' });
        } else {
          const nextRun = new Date(Date.now() + task.intervalMs);
          await task.update({
            executionCount: task.executionCount,
            lastRunAt: new Date(),
            nextRunAt: nextRun,
            status: 'pending'
          });
        }
      }
    }
  }
}

You wire this up with node-cron:

import * as cron from 'node-cron';

const scheduler = new IntelligentScheduler();

// One-time tasks: check every hour
cron.schedule('0 * * * *', async () => {
  await scheduler.run();
});

// Recurring tasks: check every minute
cron.schedule('* * * * *', async () => {
  await scheduler.processRecurringTasks();
});

// Overdue tasks: check every 5 minutes
cron.schedule('*/5 * * * *', async () => {
  await scheduler.processOverdueTasks();
});

The scheduler is stateless. You can run multiple instances, but I recommend running just one to avoid race conditions. Use a distributed lock if you need redundancy.

Worker Implementation

Workers are what actually execute your tasks. They pull jobs from Redis and process them.

import { Worker } from 'bullmq';

class TaskWorker {
  private workers: Worker[] = [];

  start() {
    // High priority worker
    const highWorker = new Worker('task-execution-high', 
      async job => await this.executeTask(job),
      {
        connection: { host: 'localhost', port: 6379 },
        concurrency: 10  // Process 10 jobs in parallel
      }
    );

    // Normal priority worker
    const normalWorker = new Worker('task-execution-normal',
      async job => await this.executeTask(job),
      {
        connection: { host: 'localhost', port: 6379 },
        concurrency: 10
      }
    );

    // Low priority worker
    const lowWorker = new Worker('task-execution-low',
      async job => await this.executeTask(job),
      {
        connection: { host: 'localhost', port: 6379 },
        concurrency: 5  // Lower concurrency for low priority
      }
    );

    this.workers = [highWorker, normalWorker, lowWorker];

    // Set up event handlers
    this.workers.forEach(worker => {
      worker.on('completed', job => {
        console.log(`Job ${job.id} completed`);
      });

      worker.on('failed', (job, error) => {
        console.error(`Job ${job?.id} failed:`, error.message);
        this.handleFailedJob(job, error);
      });
    });

    console.log('Workers started');
  }

  private async executeTask(job: Job) {
    const { taskId, taskType, payload } = job.data;
    const startTime = Date.now();

    console.log(`Executing task ${taskId} (${taskType})`);

    try {
      // Update status in database
      const task = await database.findByPk(taskId);
      if (task) {
        await task.update({
          status: 'processing',
          startedAt: new Date(),
          attempts: task.attempts + 1
        });
      }

      // Execute based on task type
      let result;
      switch (taskType) {
        case 'email':
          result = await this.sendEmail(payload);
          break;
        case 'subscription_billing':
          result = await this.processBilling(payload);
          break;
        case 'data_cleanup':
          result = await this.cleanupData(payload);
          break;
        default:
          throw new Error(`Unknown task type: ${taskType}`);
      }

      const duration = Date.now() - startTime;

      // Mark as completed
      if (task) {
        await task.update({
          status: 'completed',
          completedAt: new Date(),
          result: result
        });
      }

      console.log(`Task ${taskId} completed in ${duration}ms`);

      return { success: true, result, duration };

    } catch (error) {
      console.error(`Task ${taskId} failed:`, error.message);

      const task = await database.findByPk(taskId);
      if (task) {
        await task.update({
          status: 'failed',
          lastError: error.message
        });

        // Send to dead letter queue if max retries exceeded
        if (task.attempts >= task.maxAttempts) {
          await this.sendToDeadLetter(job, error);
        }
      }

      throw error;  // BullMQ will retry based on job config
    }
  }

  private async sendEmail(payload: any) {
    console.log(`Sending email to ${payload.to}`);
    // Your email sending logic here
    return { sent: true, messageId: 'msg-123' };
  }

  private async processBilling(payload: any) {
    console.log(`Processing billing for ${payload.subscriptionId}`);
    // Your billing logic here
    return { charged: true, amount: payload.amount };
  }

  private async cleanupData(payload: any) {
    console.log(`Cleaning up ${payload.table}`);
    // Your cleanup logic here
    return { deleted: 42 };
  }

  private async sendToDeadLetter(job: Job, error: Error) {
    // Queue to dead letter queue for manual investigation
    await deadLetterQueue.add('dead-letter', {
      taskId: job.data.taskId,
      originalData: job.data,
      error: error.message,
      attempts: job.attemptsMade,
      timestamp: new Date()
    });
  }

  async stop() {
    for (const worker of this.workers) {
      await worker.close();
    }
  }
}

Key points about workers:

Multiple workers: Run as many as you need. Each pulls jobs independently.
Concurrency: Each worker can process multiple jobs in parallel.
Priority queues: Separate workers for high, normal, low priority.
Error handling: Failed jobs retry automatically, then go to dead letter queue.
Graceful shutdown: Workers finish current jobs before stopping.

Putting It All Together

Here's how everything connects:

class TaskSchedulerApplication {
  private db: DatabaseService;
  private queue: QueueService;
  private scheduler: IntelligentScheduler;
  private worker: TaskWorker;
  public smartAPI: SmartTaskAPI;

  constructor() {
    this.db = new DatabaseService();
    this.queue = new QueueService();
    this.scheduler = new IntelligentScheduler(this.db, this.queue);
    this.worker = new TaskWorker(this.db, this.queue);
    this.smartAPI = new SmartTaskAPI(this.db, this.queue);
  }

  async start() {
    console.log('Starting Task Scheduler...');

    // Connect to database
    await this.db.connect();
    await this.db.sync();

    // Start workers
    this.worker.start();

    // Start scheduler cron jobs
    this.startScheduler();

    // Run scheduler once on startup
    setTimeout(() => {
      this.scheduler.run();
    }, 5000);

    console.log('Task Scheduler running');
  }

  private startScheduler() {
    // One-time tasks: every hour
    cron.schedule('0 * * * *', async () => {
      await this.scheduler.run();
    });

    // Recurring tasks: every minute
    cron.schedule('* * * * *', async () => {
      await this.scheduler.processRecurringTasks();
    });

    // Overdue check: every 5 minutes
    cron.schedule('*/5 * * * *', async () => {
      await this.scheduler.processOverdueTasks();
    });
  }

  async stop() {
    await this.worker.stop();
    await this.queue.close();
    await this.db.disconnect();
  }
}

// Usage
const app = new TaskSchedulerApplication();
await app.start();

// Now you can schedule tasks
await app.smartAPI.scheduleTask({
  taskType: 'email',
  scheduledFor: '2025-12-25T09:00:00Z',
  payload: { to: 'user@example.com' }
});

Production Considerations

After running this in production for a few companies, here's what matters:

1. Database Connection Pooling

Don't open a new connection for every query. Use a connection pool:

const sequelize = new Sequelize({
  host: 'localhost',
  database: 'scheduler',
  username: 'postgres',
  password: 'password',
  dialect: 'postgres',
  pool: {
    max: 20,      // Maximum connections
    min: 5,       // Minimum connections
    acquire: 30000,
    idle: 10000
  }
});

We learned this the hard way. Without pooling, we hit PostgreSQL's connection limit during peak hours. Requests started timing out. Adding a pool fixed it instantly.

2. Redis Persistence

Redis is in-memory, but you need persistence. Enable AOF (Append Only File):

# redis.conf
appendonly yes
appendfsync everysec

This writes every operation to disk. If Redis crashes, you lose at most 1 second of data. Without it, you lose everything.

3. Worker Scaling

Start with 2-3 worker instances. Monitor queue depth:

const stats = await queue.getJobCounts('waiting', 'active');
console.log(`Waiting: ${stats.waiting}, Active: ${stats.active}`);

// If waiting > 1000, add more workers
if (stats.waiting > 1000) {
  console.log('Queue backlog detected, scale up workers');
}

We use Kubernetes HPA (Horizontal Pod Autoscaler) to scale workers automatically based on queue depth.

4. Dead Letter Queue Monitoring

Set up alerts for the dead letter queue:

const deadLetterCount = await deadLetterQueue.getJobCounts('waiting');

if (deadLetterCount.waiting > 10) {
  // Send alert to ops team
  await sendSlackAlert({
    channel: '#ops',
    text: `⚠️ ${deadLetterCount.waiting} tasks in dead letter queue`
  });
}

Check this every 5 minutes. A growing dead letter queue means something is systematically failing.

5. Database Archiving

Archive old completed tasks to keep the table small:

-- Archive tasks older than 30 days
INSERT INTO scheduled_tasks_archive
SELECT * FROM scheduled_tasks
WHERE status = 'completed' 
  AND completed_at < NOW() - INTERVAL '30 days';

DELETE FROM scheduled_tasks
WHERE status = 'completed'
  AND completed_at < NOW() - INTERVAL '30 days';

Run this weekly. Keeps your queries fast.

6. Monitoring Metrics

Track these metrics:

// Queue metrics
const queueDepth = await queue.getJobCounts();
metrics.gauge('queue.waiting', queueDepth.waiting);
metrics.gauge('queue.active', queueDepth.active);
metrics.gauge('queue.failed', queueDepth.failed);

// Database metrics
const taskStats = await database.query(`
  SELECT status, COUNT(*) as count
  FROM scheduled_tasks
  GROUP BY status
`);

taskStats.forEach(stat => {
  metrics.gauge(`tasks.${stat.status}`, stat.count);
});

// Worker metrics
metrics.gauge('workers.active', activeWorkers);
metrics.histogram('task.duration', taskDuration);

We use Prometheus for metrics and Grafana for dashboards. Essential for debugging production issues.

7. Graceful Shutdown

Handle shutdown properly:

process.on('SIGTERM', async () => {
  console.log('SIGTERM received, shutting down gracefully...');

  // Stop accepting new jobs
  await worker.pause();

  // Wait for current jobs to complete (max 30 seconds)
  await worker.close();

  // Close database connections
  await database.close();

  console.log('Shutdown complete');
  process.exit(0);
});

Without this, you'll lose in-flight jobs during deployments.

What I Learned the Hard Way

Let me save you from my mistakes:

Mistake 1: Not Using Idempotency Keys

Early on, we had a bug where payment tasks were scheduled twice. Without idempotency, we charged customers twice. Ouch.

Solution:

await scheduleTask({
  taskType: 'billing',
  payload: { subscriptionId: 'sub-123' },
  idempotencyKey: `billing-sub-123-2025-11`
});

Now duplicate schedules are automatically ignored.

Mistake 2: Infinite Retry Loops

We had a task that failed because of invalid data. It kept retrying forever, filling up the queue.

Solution: Set max attempts and use exponential backoff:

{
  attempts: 3,
  backoff: {
    type: 'exponential',
    delay: 5000  // 5s, 25s, 125s
  }
}

After 3 attempts, send to dead letter queue for manual review.

Mistake 3: Not Handling Clock Skew

Our scheduler and workers were on different servers with slightly different clocks. Tasks scheduled for "now" sometimes appeared to be in the past on workers.

Solution: Always use UTC and allow a small time buffer:

// When checking if task is overdue
const isOverdue = task.scheduledFor < new Date(Date.now() - 60000);
// 1 minute buffer

Mistake 4: Forgetting to Update nextRunAt

In recurring tasks, we forgot to update nextRunAt after execution. Tasks ran once then never again.

Solution: Always update in the same transaction:

await database.transaction(async transaction => {
  // Queue task
  await queueToRedis(task);

  // Update next run
  const nextRun = calculateNextRun(task.cronExpression);
  await task.update({ nextRunAt: nextRun }, { transaction });
});

Mistake 5: No Monitoring

We had no visibility into the system. When tasks stopped running, we only found out when users complained.

Solution: Set up alerts for:

Queue depth > 1000
No tasks executed in last hour
Dead letter queue > 10
Worker errors > 5 per minute
Database query time > 1 second

Wrapping Up

This architecture has served us well. We've processed over 100 million tasks in the last year without major issues. Here's what makes it work:

Two-tier storage: Saves 90%+ on infrastructure costs
Intelligent routing: Tasks automatically go where they should
Three task types: Handles all scheduling patterns
BullMQ + Redis: Reliable, fast, feature-rich queueing
Persistent state: Survives restarts and crashes
Horizontal scaling: Add workers to increase throughput
Full observability: Know what's happening at all times

The code is TypeScript, production-tested, and ready to deploy. The full implementation is about 2,000 lines, which sounds like a lot but breaks down into clean, testable modules.

Is it overkill for a side project? Absolutely. For a startup growing past 10k users? It's essential. For an enterprise handling millions of tasks? It's how you sleep at night.

If you're building something similar, feel free to steal this architecture. Just don't make the mistakes I made along the way.

Drop your thoughts. Let's argue in the comments like developers do.

I am Elvis Sautet, Follow me on x at @elvisautet Senior Full Stack Developer

Questions? Thoughts? Let me know in the comments. I'm always curious to hear how others are solving this problem.

Happy scheduling!

"2026", AI Users vs The Unemployed.

Elvis Sautet — Thu, 13 Nov 2025 05:58:55 +0000

I just read a stat that made me sit up straight.

By 2026 (well, it's happening), ninety percent of all code is predicted to be AI-generated.

Not 20%. Not half. Ninety percent.

That's next year. a few months away. And I'm sitting here wondering if I should even bother learning that new framework I bookmarked last week.

This isn't speculation anymore. Developers wrote 256 billion lines of code in 2024. The projection for 2025? 600 billion lines. That jump isn't because we suddenly got way better at typing. It's AI. Writing code. Everywhere. For everyone.

And the thing is, I use these tools every day. GitHub Copilot autocompletes half my functions. ChatGPT helps me debug weird errors. Claude explains TypeScript generics when I forget how they work. I'm part of this shift.

But 90%? That's not assistance anymore. That's replacement.

Let me unpack this, because I think we need to have an honest conversation about what's actually happening to our profession.

The Numbers That Should Scare You

According to recent industry data, over 95% of developers admit to using AI-generated code. Not just trying it. Using it regularly. In production (haha, I DO IT ALSO).

Developers are now applying for 200-300 jobs just to get one callback. The job market is frozen. Companies aren't hiring because they're figuring out if they even need as many developers anymore.

AI recruitment tools are screening resumes now, not humans. Half the job posts on LinkedIn are from AI recruitment companies analyzing keywords and patterns. And they're rejecting people who use AI to write their resumes while simultaneously being AI themselves. The irony would be funny if it wasn't so bleak.

Tech job openings are down. Way down. Not because demand for software is down. Demand is up. But supply of people needed to write it? AI's handling that now.

This is from real 2025 data, not projections. This is happening right now.

What This Actually Means (Beyond the Hype)

Let's be real about what "90% AI-generated code" looks like in practice.

It doesn't mean AI writes entire apps from scratch while you sip coffee. It means:

Code completion is AI-generated. That's maybe 30-40% of what you type just autocompleted.

Boilerplate and scaffolding is AI-generated. Starting new projects, setting up configs, creating basic CRUD operations. AI does this instantly.

Bug fixes and refactoring suggestions are AI-generated. You write code, AI suggests improvements, you accept them.

Tests are AI-generated. Write a function, AI generates the test cases.

Documentation is AI-generated. Code comments, README files, API docs. AI writes them based on your code.

Add all that up and yeah, 90% tracks. But it's not like AI is the senior developer and you're unemployed. It's more like AI is the junior developer who does all the tedious stuff, and you're the senior reviewing and deciding what stays.

Except here's the problem. That's exactly how you trained to become a senior developer. By doing the tedious stuff. Writing boilerplate. Making mistakes. Debugging. Learning.

If AI does all that now, how does the next generation of developers learn?

The Job Market Reality (It's Worse Than You Think)

Let me paint you a picture of what hiring looks like in 2025.

Post a junior developer position. Get 500 applications in 24 hours. Half of them have AI-written resumes that look perfect but the candidates can't code in the interview.

Post a senior developer position. Get 1000 applications. Most are actually qualified. But you only need one person because AI is doing what would've taken a team of three.

Companies are calling this a "hiring freeze." That's corporate speak for "we're figuring out how much AI can replace."

Experienced developers are saying this is the "oh fuck" moment. You either get on board with AI fast and stay relevant, or you step off and get left behind.

The timeline for keeping your skills current has compressed from years to months. Framework knowledge that took you a year to build is obsolete in six months. Best practices from last quarter are outdated today.

And here's the kicker. With AI, speed matters more than quality now. Ship fast, iterate fast, don't worry about clean code because you can just AI-refactor it later. The careful, thoughtful development approach is being called "antiquated."

If you're not coding at AI speed, you're too slow.

My Personal Crisis (And Probably Yours Too)

I've been building with JavaScript and TypeScript for eight years. I'm good at what I do. I can architect systems, debug complex issues, mentor juniors, ship production code that scales.

But last week I caught myself thinking "why am I manually writing this function when Copilot can generate it in two seconds?"

And then "why am I learning this new library when I can just ask ChatGPT how to use it when I need it?"

And then the scary one: "am I still a developer if AI writes most of my code?"

Because here's the uncomfortable truth. I'm faster with AI. Way faster. Tasks that took me a day now take an hour. But did I learn anything? Did I actually understand what I built? Or did I just become really good at prompting?

The skill is shifting from "writing code" to "directing AI to write code." From developer to... what? AI whisperer? Prompt engineer? Code reviewer?

And if that's the future, what happens to people who loved writing code? Because I got into this field because I love solving problems with code. Not because I love telling an AI to solve problems while I watch.

The Controversial Part (Let Me Say What Others Won't)

There's this narrative that AI is "augmenting developers, not replacing them."

That's corporate PR. Here's the real story.

AI is absolutely replacing certain types of developers. Junior developers specifically. Entry-level positions are vanishing because AI can do what they did, faster and cheaper.

The bootcamp graduate who could get a junior role in 2023? In 2025, they're competing with AI that writes better code and doesn't need salary or benefits.

Companies used to hire juniors to do grunt work while learning. Now AI does the grunt work instantly. So why hire juniors?

The path from "I learned to code" to "I have a dev job" is broken. Maybe permanently.

And for mid-level developers, AI is compression. Companies that needed 10 developers now need 4, because those 4 with AI tools can do what 10 did before.

The only "safe" developers are the seniors who can architect systems, make high-level decisions, and review AI-generated code for bugs and security issues.

But here's the problem with that. If juniors can't get jobs, they never become mid-level. If mid-levels are getting compressed, they can't grow into seniors. The pipeline is breaking.

Ten years from now, who will be the senior developers reviewing AI code if nobody got hired as a junior in 2025?

What Nobody Is Talking About (But Should Be)

The quality problem is real and getting ignored.

AI generates code fast. But is it good code? Well-architected code? Secure code? Maintainable code?

Recent research found that code churn the amount of code that gets rewritten or deleted within two weeks has doubled. Meaning AI code needs to be fixed more often.

Duplicate code is up 4x because AI doesn't refactor. It copy-pastes patterns. Your codebase becomes bloated with repeated logic.

Security vulnerabilities are common. Up to 30% of AI-generated code snippets have security issues. SQL injection, XSS, authentication bypass, all the classics.

But we're shipping it anyway because speed beats quality now. Technical debt is compounding at a rate we've never seen before. And nobody's talking about who's going to fix this mess in 5 years.

The Things That Still Matter (Maybe)

So what do you do? How do you stay relevant when AI can code?

Here's what I'm betting on, though I could be completely wrong:

Architecture and system design. AI can write functions. It struggles with designing entire systems that need to scale, handle complexity, and integrate with legacy code.

Code review and quality assurance. AI generates code. Someone needs to verify it works, is secure, and doesn't have weird edge cases.

Business logic and domain knowledge. AI knows programming. It doesn't know your business, your users, your specific problems. That context still requires humans.

Communication and collaboration. AI can't run meetings, explain technical decisions to stakeholders, or mentor team members.

Ethics and responsibility. When AI-generated code fails, crashes systems, or causes security breaches, a human takes the fall. That responsibility can't be outsourced.

But honestly? I'm not sure any of this will be enough. Because AI is improving every day. What it can't do today, it might do tomorrow.

The Fork in the Road (Where We're Actually At)

We're at a decision point as an industry. Two paths forward:

Path one: Embrace AI fully. Accept that "developer" means something different now. Focus on the high-level thinking, let AI handle implementation. Retrain constantly. Move fast.

Path two: Resist AI. Stick to fundamentals. Write code manually. Value quality over speed. Accept you'll be slower but maybe more thoughtful.

The problem is Path two probably isn't viable if you need to pay rent. Companies aren't going to pay you to write code slowly when AI does it fast.

So Path one seems inevitable. Which means we all become something different than we were. The job changes. The skills change. The entire profession transforms.

And maybe that's fine. Maybe that's progress. We moved from punch cards to high-level languages. From assembly to JavaScript. Each shift made us more productive but further from the metal.

This is just the next step. From writing code to directing AI that writes code.

But I can't shake the feeling we're losing something fundamental. The craft. The art. The actual skill of programming.

What Happens Next (My Best Guess)

Here's my prediction for the next 24 months.

Junior developer positions nearly disappear. Entry-level developers need to show AI-assisted productivity from day one. The learning period shrinks from years to months.

Bootcamps shift focus from teaching code to teaching AI prompting and code review. You learn how to use AI tools, not how to code from scratch.

Developer salaries split into two tiers. Seniors who can work with AI make more because they're multipliers. Everyone else makes less because they're competing with AI.

Companies consolidate development teams. Why have 20 developers when 8 with AI tools can do the same work?

Open source struggles. If AI generates most code, who contributes to foundational libraries? Who maintains core infrastructure?

Technical debt explodes. AI-generated code piles up faster than anyone can review it properly. Major outages and security breaches become more common.

A new role emerges: AI code auditor. Someone who does nothing but review AI-generated code for quality and security.

And probably, the definition of "software developer" fundamentally changes. We become orchestrators more than implementers. Architects more than builders.

Whether that's better or worse depends on who you ask.

The Question We Should All Be Asking

Not "will AI replace developers?" That's already happening. The better question is:

"What kind of developer do you want to be in a world where AI writes most of the code?"

Because that world is here. It's not coming. It's now.

You can fight it. You can embrace it. You can pretend it's not real. But you can't ignore it.

I don't have the answer. I'm still figuring it out myself. Some days I'm excited about the productivity boost. Other days I'm terrified I'm becoming obsolete.

But I know this: sitting still is not an option. The 90% stat isn't a warning. It's a reality. And we're all going to have to adapt faster than we've ever adapted before.

The developers who thrive will be the ones who figure out how to be valuable in the 10%. The ones who bring something AI can't. Judgment. Creativity. Domain knowledge. Business understanding. Human connection.

The rest? I don't know what happens to the rest.

My Honest Take (No BS)

I started this article thinking I'd have a clear position. Either pro-AI or anti-AI. A take I could defend.

But the truth is I'm conflicted. And I think that's okay. Because this situation is genuinely unprecedented.

AI code generation is simultaneously:

Making me more productive
Making junior developers unemployable
Creating massive technical debt
Accelerating innovation
Destroying traditional learning paths
Opening new possibilities

All of these things are true at the same time.

So what do I do? What do you do?

I'm using AI tools. I'm also making sure I understand what they generate. I'm building faster. I'm also taking time to learn fundamentals. I'm adapting. I'm also trying not to lose what made me love this work in the first place.

It's messy. It's uncertain. It's kind of scary.

But it's where we are. And pretending otherwise doesn't help.

So let's talk about it. Let's figure this out together. Because if 90% of code is AI-generated by 2026, we've got a few months or so to decide who we want to be in that world.

And that decision can't wait.

What's your take? Are you using AI to code? Are you worried? Excited? Terrified?

Drop your thoughts. Let's have the honest conversation nobody else is having.

Follow my journey:

Follow me on X (Twitter)
Senior Full Stack Developer | Figuring This Out Like Everyone Else

If this made you uncomfortable, share it anyway. We need to stop pretending this isn't happening.

Tailwind CSS Won the War... But We're the Losers

Elvis Sautet — Fri, 07 Nov 2025 16:59:01 +0000

This week, I needed to add a simple hover effect to a button. Nothing fancy. Just change the background color on hover.

I stared at the screen for 30 seconds. My fingers hovering over the keyboard. And I couldn't remember how to write it.

Not because I'm bad at CSS. I've been building websites since 2017. I know CSS. Or I used to.

The syntax just wouldn't come to me. My brain immediately went to hover:bg-blue-600. That's Tailwind. Not CSS.

Then it hit me. I haven't written actual CSS in maybe two years. Everything is Tailwind now. Classes. Utilities. No stylesheets.

And I'm not the only one. Tailwind has over 20 million weekly NPM downloads. That's more than Bootstrap's 4.9 million. The framework is everywhere. Your favourite sites/coding-Agents use.

But here's the question nobody's asking: what happens when we all forget how CSS actually works?

The Takeover Nobody Saw Coming

Five years ago, Tailwind was this weird utility-first framework some people were trying. Most developers looked at code like this:

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Click me
</button>

And said "that's disgusting. That's just inline styles with extra steps."

They weren't entirely wrong.

But something happened. Developers started using it. Then they couldn't stop using it. Then they forgot how to build without it.

The data tells the story. According to the State of CSS survey, Tailwind's retention rate is in the high 70s. That means 3 out of 4 developers who try it keep using it.

Compare that to Bootstrap at around 45%. Or plain CSS at... well, people don't "retain" CSS because it's not a choice. It's the foundation.

Except now it kind of is a choice. And developers are choosing Tailwind.

Why Everyone Uses It (Including Me)

I'm not going to sit here and pretend Tailwind is bad. I use it. On every project. My muscle memory is Tailwind classes now, not CSS properties.

Here's why it won:

Speed

You don't context switch between HTML and CSS files. Everything is right there. You see a div, you style it, you move on. No jumping between files. No naming classes. No wondering if .button-primary is already defined somewhere.

Consistency

Your spacing is consistent because you're using predefined spacing utilities. p-4 is always the same padding. gap-8 is always the same gap. No more margin: 23px because you eyeballed it.

No naming things

Naming CSS classes is one of the hardest problems in programming. With Tailwind, you don't name anything. The classes describe themselves. flex items-center justify-between tells you exactly what it does.

Just works

You don't fight specificity. You don't debug why your styles aren't applying. You don't wonder if that class is being overridden somewhere. Tailwind classes just work.

That's powerful. That's why developers love it. That's why I love it.

The Problem Nobody Talks About

But here's what's bothering me. And I think it should bother you too.

We're abstracting away fundamental knowledge

CSS isn't that hard. Flexbox, Grid, positioning, these are core web platform features. They're not going away. But we're building an entire generation of developers who don't know them.

I've interviewed junior developers who can tell me exactly what justify-content: space-between does in Tailwind class form but can't write the actual CSS property.

They know flex items-center but don't know align-items: center.

They know w-64 but have no idea that's width: 16rem or why rem exists.

That's concerning.

The bundle size lie

Tailwind markets itself as producing tiny CSS bundles. "Most projects ship less than 10kb of CSS!"

That's true. Your CSS file is small.

But your HTML is massive. Every element has 5-15 classes. Your HTML files are 2-3x larger than they would be with semantic CSS.

Sure, HTML compresses well. But it still needs to be parsed. The browser still needs to process all those classes.

I ran the numbers on one of our projects. CSS went from 45kb to 8kb with Tailwind. Great! But HTML went from 120kb to 340kb. Net increase: 183kb.

That's not mentioned in the marketing.

You're locked in

Want to switch from Tailwind to something else? Good luck. Your entire codebase is Tailwind classes. Every component. Every page. Thousands of utility classes everywhere.

Migrating away from Tailwind is like migrating away from jQuery was. Possible, but so painful that most people just don't.

You're not learning CSS. You're learning Tailwind. And if Tailwind goes away or falls out of favor, what do you have?

The readability problem

Look at this real code from a production app:

<div class="flex flex-col sm:flex-row items-start sm:items-center justify-between p-4 sm:p-6 bg-white dark:bg-gray-800 rounded-lg shadow-md hover:shadow-lg transition-shadow duration-200 border border-gray-200 dark:border-gray-700 space-y-4 sm:space-y-0 sm:space-x-4">

That's 19 classes on one div. Can you tell what it does at a glance? Nope. You have to mentally parse each utility.

With semantic CSS:

<div class="card">

And in your CSS:

.card {
  /* All the styles */
}

Which is more readable? Which is easier to understand for someone new to the codebase?

What Happens If Tailwind Disappears?

This keeps me up at night. Not because I think Tailwind will disappear tomorrow. It won't. It's too big now.

But frameworks come and go. Remember when Bootstrap owned the web? When jQuery was on every site? When Flash was how you made interactive content?

All of those seemed permanent. None of them were.

Tailwind is backed by Tailwind Labs. It's a company. Companies can be acquired, shut down, pivot, or just decide a framework isn't profitable anymore.

What happens to the millions of Tailwind projects then?

You might say "it's open source, the community will maintain it." Sure. But when was the last time you saw a popular framework maintain momentum after losing its core team?

Look at Ember. Look at Backbone. Look at Angular.js (not Angular, Angular.js). All still technically maintained. All basically dead.

I'm not predicting Tailwind will die. I'm saying it could. And if it does, we have an entire industry of developers who can't write CSS anymore.

The Real Controversy (That Nobody Wants to Say)

Here's the spicy take that'll make people angry:

Tailwind is training wheels that never come off.

And that's by design.

When you learn to ride a bike, you start with training wheels. Eventually, you take them off and ride for real.

With Tailwind, you start with utility classes. And you... keep using utility classes. Forever. You never take off the training wheels and write actual CSS.

The framework doesn't encourage you to learn the underlying platform. It encourages you to learn more Tailwind.

Want to do something custom? Extend your Tailwind config(I haven't read much in the newer versions, DO NOT ROAST ME ON THAT, hahaha). Need a new color? Add it to your Tailwind theme. Need a new spacing value? Add it to your Tailwind spacing scale.

Everything pushes you deeper into Tailwind, not deeper into CSS.

And that's brilliant business strategy. Lock-in is valuable. But it's bad for the web platform.

CSS is evolving fast. Container queries, has() selector, subgrid, cascade layers, all these powerful features are landing in browsers.

But how many Tailwind developers know about them? How many are using them?

Tailwind supports some of these through utilities. But you're learning the utility, not the feature. And if Tailwind doesn't support something yet, you probably won't use it.

What I'm Doing About It (And What You Should Too)

I still use Tailwind. Every day. I'm not here to tell you to stop using it.

But I am making some changes:

One day a week, no Tailwind

Friday is my "vanilla CSS" day. If I'm working on something, I write actual CSS. No utilities. Just regular stylesheets.

It's painful at first. But it keeps my CSS skills sharp. And honestly, sometimes it's refreshing.

Teaching juniors CSS first

When I mentor junior developers, we don't start with Tailwind. We start with CSS. Flexbox, Grid, positioning, the fundamentals.

Only after they can build a layout in pure CSS do we introduce Tailwind. So they understand what they're abstracting.

Actually reading CSS specs

I subscribe to CSS updates. I read about new features. I try them in projects. Because CSS is still evolving, and I don't want Tailwind to be my only window into it.

Writing semantic CSS for complex components

For truly complex components, I write actual CSS. Custom properties, calculations, complex selectors. Things that are hard or impossible in utility classes.

This keeps me comfortable in both worlds.

The Uncomfortable Truth

We're in a weird place with CSS right now.

The platform is more powerful than ever. Container queries are game-changing. Cascade layers solve specificity problems. Nesting is finally here natively.

But fewer developers than ever actually write CSS.

Tailwind is winning. The data proves it. The adoption proves it. The community proves it.

And maybe that's fine. Maybe abstraction is progress. We abstracted away assembly language. We abstracted away C. We abstracted away jQuery's cross-browser pain.

Maybe abstracting away CSS is the next logical step.

But I can't shake the feeling that we're losing something important. The ability to understand and manipulate the foundational layer of the web.

When everyone knows Tailwind but nobody knows CSS, who maintains the web platform?

Who contributes to CSS specs? Who files browser bugs? Who pushes CSS forward?

If the answer is "nobody because we're all using Tailwind," that's a problem.

Where CSS Is Actually Heading

While we're all writing flex items-center justify-between, CSS itself is evolving into something more powerful.

Native nesting is here. You can write Sass-style nested selectors in pure CSS now.

Container queries let components be responsive based on their container size, not viewport size. This is huge and Tailwind sort of supports it but most developers don't use it.

The has() selector is a parent selector. You can style a parent based on its children. This was impossible for decades. Now it's real.

View transitions API makes page transitions smooth and native. No JavaScript framework needed.

Cascade layers give you fine-grained control over specificity. You can finally organize your CSS without fighting specificity wars.

All of this is native CSS. Browser-level features. No build step. No framework. Just works.

But how many developers are using these? How many even know about them?

Tailwind adds utilities for some of this. But slowly. And only when it makes sense for their utility-first model.

Meanwhile, native CSS is moving faster than any framework can keep up with.

The Question We Should Be Asking

Not "should I use Tailwind?" That ship has sailed. Most of us are using it or will use it.

The question is: "how do I use Tailwind without forgetting the platform?"

Because that's the real risk. Not that Tailwind is bad. But that it's so good that we stop learning what's underneath.

And when the next big thing comes (and it will come), we'll be unprepared.

We'll be Tailwind developers, not web developers.

And that difference matters.

My Honest Take (After 3 Years of Tailwind)

I don't hate Tailwind. I use it every day. It makes me faster. My team is more productive with it.

But I'm worried about the industry. About junior developers who think CSS is just Tailwind classes. About codebases that are so dependent on one framework that migration is impossible.

About a future where "front-end developer" means "knows Tailwind" instead of "knows the web platform."

Maybe I'm wrong. Maybe this is just progress and I'm being nostalgic about writing CSS files like an old man yelling at clouds.

But I don't think so.

I think we're trading short-term productivity for long-term knowledge. And that trade-off only makes sense if Tailwind stays dominant forever.

Which is a big assumption.

What You Can Do

If you're using Tailwind (and you probably are), here's my advice:

Don't stop learning CSS. Spend time with the actual properties. Understand what you're abstracting. Read CSS specs. Try new features.

Teach CSS to juniors before Tailwind. Make sure they understand the foundation before adding the abstraction layer.

Write some vanilla CSS occasionally. Keep your skills sharp. You might need them.

Stay aware of native CSS evolution. The platform is moving fast. Don't let Tailwind be your only window into it.

Build escape hatches. Don't make your entire codebase 100% Tailwind. Have some custom CSS. Make migration possible, even if unlikely.

Question the framework. Just because Tailwind says something is "best practice" doesn't mean it is. Think critically about what you're building.

The Bottom Line

Tailwind won. The data proves it. The adoption proves it. If you're arguing against Tailwind in 2025, you've already lost.

But winning doesn't mean it's perfect. And popularity doesn't mean it's the final answer.

CSS is the platform. Tailwind is a tool. Don't confuse the two.

Use the tool. But respect the platform. Learn the platform. Contribute to the platform.

Because when the next framework comes (and it will come), the platform will still be there.

And you'll need to know it.

What's your take? Are you forgetting CSS too? Or am I overthinking this?

Drop your thoughts. Let's argue in the comments like developers do.

Elvis Sautet

Follow me on x at @elvisautet

Senior Full Stack Developer | Still Writes CSS Sometimes

If this made you uncomfortable, good. Share it anyway. We need this conversation.

Stop Doing Business Logic in Webhook Endpoints. I Don't Care What Your Lead Engineer Says.

Elvis Sautet — Fri, 31 Oct 2025 00:22:07 +0000

Yesterday at 1pm I'm on a call with a payment provider's tech team. We're integrating their IPN (Instant Payment Notification) system. The call should've been 15 minutes. It turned into a 2-hour argument about how callbacks should work.

Their lead engineer is telling me we need to validate everything in the callback endpoint. Check for duplicates. Verify the payment hasn't been processed. Update the database. Send confirmations. Return specific error codes for different scenarios.

I'm sitting there thinking "no, that's all wrong."

Finally I said it. "Your job is to hit our endpoint. Our job is to acknowledge we received it. Everything else is our problem, not yours."

Silence on the call. Then he says "that's not how callbacks work."

But here's the thing. That IS how callbacks should work. And most developers, even senior ones, get this wrong.

Let me explain the argument, why I was right, and how to actually handle webhooks properly.

The Setup: What We Were Building

Integrating a payment gateway. Pretty standard stuff. When someone pays, the provider sends a webhook to our endpoint with payment details. We need to:

Update the payment status in our database
Update the order status
Send confirmation email to customer
Send SMS notification
Update inventory
Trigger fulfillment
Track analytics

Their tech lead wanted all of this to happen IN the callback endpoint. Return 200 if everything succeeded, return 400 with error details if anything failed.

I wanted to just acknowledge the webhook and process everything asynchronously.

We went back and forth for 2 hours.

Their Argument (Why They Thought I Was Wrong)

Their lead made these points:

"You need to validate the payment hasn't been processed already"

They were worried about duplicate webhooks. If we don't check for duplicates in the endpoint and return an error, they might send the same webhook multiple times and we'd process it multiple times.

My response: "That's an idempotency problem. We handle that in our processing logic, not in the endpoint response."

"What if your database is down?"

If our database is down when the webhook hits, and we return 200, we've acknowledged a payment we can't process.

My response: "If our database is down, we have bigger problems. And your retry logic will handle it anyway."

"You need to return specific error codes"

They had this whole spec about returning different status codes:

409 for duplicates
422 for validation errors
500 for processing errors
200 only for complete success

My response: "That's coupling your system to our internal logic. You don't need to know why something failed on our end."

"How will we know if processing succeeded?"

They wanted confirmation that everything worked. Email sent, inventory updated, order fulfilled.

My response: "You don't need to know that. You need to know we received the webhook. That's it."

This went on for way too long.

My Argument (Why I Was Right)

Here's what I kept trying to explain:

Separation of concerns

Their job: Send webhooks reliably
Our job: Process them reliably

These are separate responsibilities. Mixing them creates tight coupling and makes both systems fragile.

Network timeouts are real

If we're doing all that processing in the endpoint, and it takes 5+ seconds, their webhook request times out. They retry. We get duplicate webhooks. Everything breaks.

Even if it takes 3 seconds, that's slow. Webhooks should be fast. Sub-second fast.

Our processing might fail for reasons they can't fix

Say our email service is down. We can't send confirmation emails. Should we return an error to the payment provider? What are they supposed to do about it? The payment still succeeded. The email is our problem.

Or our inventory service is slow. Takes 10 seconds to update. Should we make them wait? No. That's our internal issue.

Retry logic belongs in queues, not in HTTP responses

If email sending fails, we should retry. But that retry shouldn't involve the payment provider. We should handle it internally with a message queue.

Their webhook delivered successfully. Everything after that is our responsibility.

The endpoint's only job is to receive and acknowledge

That's it. Verify the webhook signature, add it to a queue, return 200. Done.

All the processing happens asynchronously in worker processes. If something fails, our workers retry. The payment provider doesn't need to know or care.

What The Endpoint Should Actually Look Like

This is what I kept trying to explain. The callback endpoint should be stupid simple:

app.post('/webhooks/ipn', async (req, res) => {
  const payload = req.body

  // Step 1: Verify signature (this is THEIR security requirement)
  const signature = req.headers['x-payment-signature']
  if (!verifySignature(payload, signature)) {
    return res.status(401).json({ error: 'Invalid signature' })
  }

  // Step 2: Add to queue
  await paymentQueue.add('process-payment', payload)

  // Step 3: Acknowledge immediately
  res.status(200).json({ received: true })
})

That's the entire endpoint. Three things:

Verify it's actually from them (security)
Queue it for processing
Respond

Everything else happens in a worker:

paymentQueue.process('process-payment', async (job) => {
  const payload = job.data

  // Check for duplicates HERE, not in the endpoint
  const existing = await db.payments.findUnique({
    where: { transactionId: payload.transactionId }
  })

  if (existing) {
    console.log('Duplicate payment, skipping')
    return // Job completes without doing anything
  }

  // Update payment
  await db.payments.update({
    where: { id: payload.paymentId },
    data: { status: 'completed' }
  })

  // Get order
  const order = await db.orders.findUnique({
    where: { paymentId: payload.paymentId }
  })

  // All the slow stuff
  await sendEmail(order.customerEmail, 'Payment confirmed')
  await sendSMS(order.customerPhone, 'Payment received')
  await updateInventory(order.items)
  await fulfillmentService.createShipment(order)
  await analytics.track('payment_completed', order)
})

If any of this fails, the job retries. Automatically. The payment provider never knows or cares.

Why Their Approach Breaks In Production

I tried explaining what happens with their approach in real production scenarios:

Scenario 1: Email service is down

Webhook hits endpoint. We try to send email. Email service times out after 5 seconds. We return 500 to payment provider. They retry the webhook. We process the payment again. Customer gets charged twice.

Scenario 2: Database query is slow

Webhook hits. Database is under load. Query to check for duplicates takes 8 seconds. Webhook times out. Provider retries. Now we have race conditions. Same payment processed multiple times because both webhooks are checking for duplicates at the same time.

Scenario 3: SMS provider is rate limiting us

We hit our SMS limit. Can't send notifications. Return error to payment provider? They retry. We still can't send SMS. They retry again. Now we have 50 failed webhooks piling up because of our SMS provider.

Scenario 4: Analytics service is down

Analytics is down for maintenance. We can't track events. Should we fail the entire payment processing because analytics is down? No. But if we return 500, the payment provider thinks the payment failed.

All of these are real scenarios that happen in production. And all of them break if you're doing too much work in the callback endpoint.

The Counter Arguments (What They Said Next)

"But how do we know you processed it successfully?"

You don't. And you don't need to. You need to know we received it. Processing is our problem.

If processing fails on our end, we handle it. We retry. We log. We alert. We fix it. You're not involved.

"What if your queue is full or Redis is down?"

Then adding to the queue fails and we return 500. You retry later. That's the only legitimate failure case - we couldn't receive the webhook at all.

But if we added it to the queue successfully, we return 200. Because we received it. What happens after is not your concern.

"How do you handle duplicates then?"

In the worker process. Every payment has a unique transaction ID from you. We check if we've already processed that transaction ID. If yes, we skip it. If no, we process it.

This is called idempotency. The worker logic is idempotent. Running it multiple times with the same transaction ID doesn't cause duplicate processing.

"What about ordering? Webhooks might arrive out of order"

That's also handled in the worker. We don't rely on webhooks arriving in order. Each webhook is self-contained with all the data we need.

If you send webhook A then webhook B, but B arrives first, that's fine. Each one processes independently.

"This seems more complex on your end"

Yes. Because it's OUR problem to solve, not yours. Your job is simple: send webhooks reliably. Our job is complex: process them reliably.

We don't want to push our complexity into your retry logic.

The Real-World Example That Convinced Them

Around 2:30pm I was exhausted. Decided to show them real data from a previous integration where we did it their way.

Pulled up our logs from a payment provider we integrated 6 months ago using their approach:

Week 1:

1,200 payments
47 duplicate webhook receptions
12 duplicate payments processed
8 customers charged twice
3 hours spent issuing refunds

Week 2:

Email service hiccup (was down for 10 minutes)
200+ webhook timeouts during that window
Provider retried all of them
800+ duplicate webhook receipts
Database got hammered
Site went down for 20 minutes
6 hours of cleanup

Week 4:

Analytics service maintenance
Can't track events
Start returning errors to provider
They stop sending webhooks
Miss 50 payments
Customer support explosion
CEO not happy

Week 8:

SMS rate limit hit
Same pattern as week 4
Another 30 payments missed

Showed them this data. "This is what happens when we do too much work in the callback endpoint. We've been fighting this for months."

Then showed them data from a different provider where we used the queue approach:

4 months of operation:

50,000+ payments
Zero duplicate payments processed
Zero missed payments
Average callback response time: 45ms
Zero webhook-related outages

That's when their lead engineer went quiet for a minute. Then said "okay, I see your point."

The Compromise We Reached

Around 3pm we agreed on this:

Their requirements:

Return 401 if signature is invalid
Return 400 if the webhook payload is malformed
Return 200 if webhook is received successfully
Return 503 if our queue is unavailable

Our implementation:

Endpoint does minimal work (verify, queue, respond)
All processing happens asynchronously
We handle duplicates in worker logic
We handle failures with retries in our queue
We alert ourselves if jobs fail repeatedly

What we DON'T do:

Check for duplicates in the endpoint
Validate payment details in the endpoint
Return errors for downstream service failures
Return errors for processing failures

The endpoint's job is to receive and acknowledge. That's it.

How We Actually Implemented It

Here's the production code we ended up with:

const express = require('express')
const { Queue } = require('bullmq')
const crypto = require('crypto')

const app = express()
app.use(express.json())

const ipnQueue = new Queue('ipn-processing', {
  connection: { host: 'localhost', port: 6379 }
})

// IPN endpoint
app.post('/webhooks/ipn', async (req, res) => {
  const payload = req.body
  const signature = req.headers['x-payment-signature']

  // Validate signature
  if (!isValidSignature(payload, signature)) {
    return res.status(401).json({ 
      error: 'Invalid signature',
      received: false 
    })
  }

  // Validate payload structure
  if (!payload.transactionId || !payload.amount) {
    return res.status(400).json({ 
      error: 'Invalid payload',
      received: false 
    })
  }

  try {
    // Add to queue with job ID = transaction ID (automatic deduplication)
    await ipnQueue.add('process-ipn', payload, {
      jobId: payload.transactionId, // If job with this ID exists, it won't add duplicate
      attempts: 5,
      backoff: {
        type: 'exponential',
        delay: 3000
      }
    })

    // Acknowledge immediately
    res.status(200).json({ 
      received: true,
      transactionId: payload.transactionId 
    })

  } catch (error) {
    console.error('Failed to queue IPN:', error)

    // Only return 503 if we couldn't queue it
    res.status(503).json({ 
      error: 'Service temporarily unavailable',
      received: false 
    })
  }
})

function isValidSignature(payload, signature) {
  const secret = process.env.PAYMENT_SECRET
  const hash = crypto
    .createHmac('sha256', secret)
    .update(JSON.stringify(payload))
    .digest('hex')

  return hash === signature
}

app.listen(3000)

Worker process:

const { Worker } = require('bullmq')

const worker = new Worker('ipn-processing', async (job) => {
  const payload = job.data

  console.log(`Processing IPN: ${payload.transactionId}`)

  try {
    // Check if already processed (defensive check, job ID should prevent duplicates)
    const existing = await db.payments.findUnique({
      where: { transactionId: payload.transactionId }
    })

    if (existing && existing.status === 'completed') {
      console.log(`Transaction ${payload.transactionId} already processed`)
      return { status: 'duplicate', transactionId: payload.transactionId }
    }

    // Update payment
    await db.payments.update({
      where: { id: payload.paymentId },
      data: { 
        status: 'completed',
        processedAt: new Date(),
        transactionId: payload.transactionId
      }
    })

    // Get order details
    const order = await db.orders.findUnique({
      where: { paymentId: payload.paymentId },
      include: { items: true, customer: true }
    })

    // All the slow/failable operations
    await Promise.all([
      sendEmail({
        to: order.customer.email,
        template: 'payment-confirmation',
        data: order
      }),
      sendSMS({
        to: order.customer.phone,
        message: `Payment received for order ${order.id}`
      }),
      updateInventory(order.items),
      analytics.track('payment_completed', {
        orderId: order.id,
        amount: order.total,
        transactionId: payload.transactionId
      })
    ])

    // Trigger fulfillment
    await fulfillmentService.createShipment(order)

    console.log(`Successfully processed ${payload.transactionId}`)

    return { 
      status: 'success', 
      transactionId: payload.transactionId,
      orderId: order.id
    }

  } catch (error) {
    console.error(`Failed to process ${payload.transactionId}:`, error)

    // Throw error so job will retry
    throw error
  }
}, {
  connection: { host: 'localhost', port: 6379 },
  concurrency: 10
})

// Monitor failures
worker.on('failed', async (job, error) => {
  console.error(`Job ${job.id} failed after ${job.attemptsMade} attempts:`, error.message)

  // Alert if job has failed all retry attempts
  if (job.attemptsMade >= job.opts.attempts) {
    await alerting.sendAlert({
      type: 'payment_processing_failed',
      transactionId: job.data.transactionId,
      error: error.message
    })
  }
})

worker.on('completed', (job) => {
  console.log(`Job ${job.id} completed:`, job.returnvalue)
})

This is what's running in production now. Been solid for months.

The Results (Why I Was Right)

Been running this implementation for 4 months now. Here's the data:

Response times:

Average: 42ms
P95: 78ms
P99: 120ms

All webhooks respond in under 200ms. Provider is happy.

Reliability:

50,000+ payments processed
Zero duplicate payments
Zero missed payments
99.97% success rate

The 0.03% failures were legitimate issues (invalid payment data, customer account problems). Everything else works.

Failure handling:

Email failures: 47 (all retried successfully within 5 minutes)
SMS failures: 12 (all retried successfully)
Analytics failures: 8 (retried successfully, zero impact on payments)
Fulfillment delays: 23 (retried, orders still shipped on time)

All of these would've caused webhook failures and retries with the old approach. With queues, they're just internal retries that succeed automatically.

Infrastructure:

Webhook endpoint: 1 instance (barely using resources)
Worker processes: 3 instances (handles all processing)
Redis: 1 instance (queue storage)
Total cost: $45/month

The old approach needed 5 API instances just to handle the webhook load during peak times. New approach is more reliable AND cheaper.

What I Learned From This Argument

Few things from that 2-hour 1pm argument:

Most developers conflate receiving and processing

They think the webhook endpoint needs to do everything. But receiving a webhook and processing it are separate concerns.

Endpoint: fast, simple, stateless
Worker: slow, complex, stateful

Keep them separate.

HTTP is terrible for async work

HTTP is request-response. User sends request, waits for response. That's fine for APIs where users are waiting.

But webhooks are fire-and-forget. The sender doesn't care about processing results. They just want confirmation you received it.

Stop trying to force synchronous patterns on asynchronous workflows.

Idempotency belongs in business logic, not in HTTP responses

You handle duplicate requests by making your processing idempotent, not by detecting duplicates in the endpoint and returning errors.

Use job IDs. Check if work was already done. Skip if yes, process if no.

Your internal problems shouldn't leak into external APIs

Email service down? That's your problem. Analytics failing? Your problem. Database slow? Your problem.

The webhook sender shouldn't know or care about any of this. Return 200 if you received the webhook, handle failures internally.

Simple interfaces are better than smart interfaces

Their approach required the endpoint to be smart. Check duplicates, validate everything, return specific errors.

Our approach makes the endpoint dumb. Just receive and queue. All the smart logic is in workers where it belongs.

Dumb interfaces are more reliable.

When You Actually Should Do More In The Endpoint

Real talk: this pattern isn't always right. Sometimes you DO need to do work synchronously.

When the sender needs a response

If they're asking "is this payment valid?" and waiting for an answer, you need to check and respond immediately.

But webhooks aren't questions. They're notifications. Big difference.

When processing is super fast

If checking for duplicates takes 10ms and that's all you're doing, fine, do it in the endpoint. But the moment you're calling external services or doing complex logic, move it to a queue.

When you don't have queue infrastructure

If you're running a small app with 10 users and 5 webhooks per day, don't overcomplicate it. Just handle it in the endpoint. You don't need Redis and worker processes.

When you're prototyping

Get it working first. Add queues later when you have scale problems. Don't overengineer early.

I spent way too long in my career adding queues to everything when a simple endpoint would've been fine.

Use them when you need them, not because they're "best practice."

The Code Structure (How We Organize This)

One thing that helped convince the payment provider was showing them how clean our code structure is:

/webhooks
  /ipn
    endpoint.js      (just receives and queues)
    worker.js        (all the processing logic)
    handlers/
      payment.js     (payment update logic)
      email.js       (email sending logic)
      sms.js         (SMS logic)
      inventory.js   (inventory updates)
      fulfillment.js (order fulfillment)

Each piece has a single responsibility. Easy to test. Easy to modify. Easy to debug.

The endpoint is like 30 lines of code. The worker orchestrates different handlers. Each handler can fail and retry independently.

Compare that to a 500-line endpoint trying to do everything. Which would you rather maintain?

The Monitoring We Added

After the argument, we added monitoring to prove this approach works:

Queue metrics:

Jobs per minute
Average processing time
Failed jobs
Queue depth

Alerts:

Alert if queue depth > 1000
Alert if failed jobs > 10 in last hour
Alert if processing time > 30 seconds
Alert if Redis is down

Dashboard:
Shows all the metrics in real-time. Payment provider can see we're processing webhooks successfully even though we return 200 immediately.

This visibility convinced them our approach works.

Resources That Helped Me Argue This

During the call I referenced these:

Webhook.site blog on webhook design:
https://docs.webhook.site/

Explains why webhooks should be fast and idempotent.

Stripe's webhook documentation:
https://stripe.com/docs/webhooks

They do it the right way. Return 200 immediately, process async.

PayPal's IPN documentation:
https://developer.paypal.com/docs/api-basics/notifications/ipn/

Same pattern. Quick acknowledgment, async processing.

The Twelve-Factor App on backing services:
https://12factor.net/backing-services

External services (like webhooks) should be loosely coupled.

All of these support the pattern I was arguing for.

The Final Agreement (What We Documented)

Around 3pm we finally agreed and documented it:

Webhook endpoint responsibilities:

Verify signature (security requirement)
Validate payload structure (prevent malformed data)
Queue for processing
Return acknowledgment

Status codes we return:

200: Received and queued successfully
401: Invalid signature
400: Malformed payload
503: Cannot queue (Redis down, queue full)

What we DON'T return:

Errors for duplicate transactions (handled internally)
Errors for processing failures (handled internally)
Errors for downstream service issues (handled internally)

Provider responsibilities:

Send webhooks with valid signature
Retry on 503 responses
Don't retry on 200 responses
Provide transaction IDs for deduplication

Our responsibilities:

Process webhooks idempotently
Handle failures with retries
Alert ourselves if processing fails repeatedly
Maintain SLA of 99.9% processing success

This is now the pattern we use for all webhook integrations.

What I'd Do Different Next Time

The argument went on way too long because I didn't lead with data. Next time I'd do this:

1. Show production logs from previous implementations

Start with "here's what happened when we did it your way" with actual data. Numbers convince people.

2. Draw the architecture on a diagram

Visual helps. Show where failures happen with each approach.

3. Reference industry examples earlier

Should've led with "this is how Stripe does it" instead of making it about our specific implementation.

4. Offer to show our monitoring

"I can show you our queue metrics in real-time" would've shortened the argument by an hour.

The Bigger Lesson

This isn't just about webhooks. It's about separation of concerns in API design.

Your public API (the endpoint) should be simple, fast, and reliable.

Your internal processing should be complex, slow, and resilient.

Don't mix them.

This applies to:

Webhooks and callbacks
Async job processing
Event-driven architectures
Microservices communication

Keep interfaces simple. Handle complexity internally.

That's how you build systems that scale and don't wake you up at 2am.

If you've ever argued with a provider about how webhooks should work, share this. Most developers get this wrong because they think HTTP endpoints need to do all the work.

They don't. They just need to receive and acknowledge.

Elvis Sautet

Catch me on X(Twitter) @elvisautet

My Portfolio Not the best, haha

Full Stack Developer | Arguing About Architecture Since 2017

Questions about webhooks, queues, or any collaborations/projects, Hit me up on Twitter.

If I Had to Learn JavaScript Again: The Real Journey From 2017 to Today

Elvis Sautet — Fri, 24 Oct 2025 20:58:57 +0000

Fresh out of high school. No plan, no direction, just a laptop and a feeling that I should probably figure out what to do with my life. Eight years later, I'm a full-stack developer working with Node, React, TypeScript, building production apps that actually matter.

But here's the thing nobody tells you about learning to code - it's not linear. It's messy. Full of false starts, detours, quits, and comebacks. This is that story. The real one.

(By the way, some years here might be a bit off maybe, The point isn’t the exact date, it’s the grind, we all start somewhere.)

Now I build things with Node.js, React, and TypeScript — stuff I couldn’t even imagine back then.

The Beginning: HTML, CSS, and Pretending I Knew What I Was Doing (2017)

Started in 2017 right after finishing high school. My first exposure to code? HTML and CSS. Not because I had a plan, but because some random YouTube video said "start here."

I built the ugliest websites. Blue backgrounds, Comic Sans everywhere, images that were so big they broke the layout. But it worked. I typed stuff, refreshed the browser, and MY code showed up on the screen. That hooked me.

Spent maybe a month just playing with HTML and CSS. Built a portfolio site (embarrassing), a fake restaurant menu (even worse), tried to copy the Google homepage and failed spectacularly.

But here's what I was actually learning without realizing it: how browsers work, how to structure a page, how to Google error messages when things broke. That foundation mattered more than I knew.

Resources that actually helped:

W3Schools (https://www.w3schools.com/) - Everyone trashes it but it's simple and works for beginners
MDN Web Docs (https://developer.mozilla.org/) - Bookmarked every page, still use it today
CSS-Tricks (https://css-tricks.com/) - When my layouts broke (which was always)

Then I got cocky. "HTML and CSS are easy, programming is gonna be easy too."

Wrong.

The School/UNI Years: Where Nothing Really Clicked (2017-2020)

Here's the uncomfortable truth - school didn't teach me much about actual programming. They had computer science classes, sure. We "learned" about loops and variables. But none of it stuck because none of it felt REAL.

The teacher would show us pseudocode. We'd write some Java on paper (yes, on actual paper). Take a test. Pass. Forget everything the next day.

Programming felt like memorizing math formulas I'd never use. Abstract. Boring. Pointless.

I was going through the motions but nothing was clicking. Passed the classes, but if you asked me to build anything, I'd have no idea where to start.

Looking back, the problem wasn't that I couldn't learn. It's that I wasn't BUILDING anything. Just copying examples and regurgitating them on tests.

The Detour: CCNA and the Command Line Awakening (2018)

Around 2018, I made a weird decision. Quit programming completely. Decided to get into networking instead. Started studying for CCNA (Cisco Certified Network Associate).

Sounds random, right? But here's what happened.

I was configuring routers and switches using Cisco's command line interface. Commands like:

Router> enable
Router# configure terminal
Router(config)# interface fastethernet 0/0
Router(config-if)# ip address 192.168.1.1 255.255.255.0

And something clicked. This command line stuff, typing commands and seeing immediate results, it felt... powerful. Like I was talking directly to the machine instead of going through some graphical interface.

I spent maybe 6-9 months deep in CCNA. Learned about networks, IP addresses, routing protocols, VLANs. Got pretty good at it honestly.

But the whole time, there was this nagging feeling: "This is cool, but I want to BUILD things, not just configure things."

The command line experience though? That planted a seed. Made me curious about terminal, about scripting, about automating stuff instead of clicking buttons.

The Real Start: Coming Back to Programming (late 2018)

Late 2018, I was on a short break — stuck with a lot on my mind, wondering if I should fully dive into coding after getting hooked through CCNA

Came back to programming, but this time different. This time with a project in mind, since we were approaching the time to do school projects.

I researched on Google alot and went with a job posting system. Like an internal job board where companies could post openings and students could apply. I went with this project.

I had no idea what I was doing.

Still figuring life out in uni, you know how it goes — half trying to build a career, half just trying to survive classes. But I committed to building this thing.

The School Project That Changed Everything: Job Portal

This project, this job portal system, this was where everything finally clicked.

I chose PHP because I found some tutorial that made it look easy (it wasn't). Spent THREE MONTHS building this thing. Not just after class time - I'm talking all-nighters, weekends, skipping social events because I was obsessed.

The scope was insane for someone learning:

Companies register and post jobs
Students create profiles and apply
Admin panel to manage everything
MySQL database storing all the data
Login/logout system with sessions
File uploads for resumes and documents

My friends thought I was crazy. "Why are you doing so much? Just build something simple and pass the class."

But I couldn't. I was hooked. This was the first time I was building something REAL. Something people would actually use but remember its a school project.

The code was a disaster, I read and read man. SQL injection vulnerabilities everywhere (I had no idea about security). Probably 80% Stack Overflow copy-paste, 20% me trying to figure out how it all worked. But it WORKED.

Then I hit a wall. The site felt... dead. Static. Click a button, page refreshes, wait. Click again, page refreshes again. It felt old and clunky.

That's when I discovered jQuery. Found some tutorial about adding animations and making forms submit without page refreshes. Spent another few weeks learning AJAX, making things happen without the whole page reloading.

And suddenly the job portal felt ALIVE. Buttons animated when you clicked them. Job listings loaded smoothly without refreshing. Form validation happened in real-time.

When I presented it to the class, my friends were stunned. Teachers were confused because it was way beyond what they expected. One teacher literally asked if I copied it from somewhere (I did copy parts, but I understood them, that's what matters).

Got an A, obviously. But more importantly, I realized something:

This interactivity. This JavaScript stuff. This was what made websites feel modern. This was what I wanted to do.

The project is still on GitHub if you want to see how messy my code was back then: https://github.com/elvis-sautet/job-portal-system

Looking at it now makes me cringe a bit, but I'm also proud of it. That was the project that made me a developer.

JavaScript: When It Finally Made Sense

After the job portal project, I was done with PHP. JavaScript was where the magic happened, and I wanted more of it.

Started properly learning JavaScript. Not from courses, but from building.

javascript.info (https://javascript.info/) became my bible. Free, comprehensive, and doesn't treat you like an idiot.

Went through:

Variables (let, const, var - still confused about var honestly)
Functions (took forever to understand return values)
Arrays and objects (mind blown when objects could contain functions)
DOM manipulation (getElementById became my best friend)
Async JavaScript (callbacks, promises, async/await - this broke my brain)

Built everything I could think of:

Calculator (obviously)
Todo app (built it like 10 times)
Expense tracker (because I was broke)
Random quote generator
Weather app using free APIs

The key difference this time? I was building stuff I actually wanted to use. Not tutorial projects. MY projects.

I even went into nodejs, with my JS grasped, The Net Ninja was also kinda pushing me to understand Node, haha.

YouTube channels that saved me:

The Net Ninja (https://www.youtube.com/@NetNinja)
Shaun's JavaScript playlist is legendary. Explains things like he's talking to a human, not a computer science professor.

Web Dev Simplified (https://www.youtube.com/@WebDevSimplified)
Kyle makes complex things feel simple. His React hooks video finally made hooks click for me after weeks of confusion.

Programming with Mosh (https://www.youtube.com/@programmingwithmosh)
Mosh's teaching style is structured and clear. Good for fundamentals.

Traversy Media (https://www.youtube.com/@TraversyMedia)
Brad's crash courses taught me more practical skills than any paid course.

But here's the trick I learned: watching isn't learning. I'd watch a video, pause it, try to build it myself without looking. Break it. Fix it. That's how it stuck.

Spent 6-8 hours a day coding. Not exaggerating. Morning, afternoon, evening. My laptop was basically an extension of my body. My parents thought I was wasting my time. My friends thought I was obsessed.

I was. And that obsession is what made the difference.

React: The Framework That Almost Broke Me (late 2021-2022)

Around late December 2021, I kept seeing React everywhere. Job postings wanted it. Developers talked about it. So I dove in.

And I almost quit coding entirely.

React made NO SENSE for the first month. Components? Props? State? JSX that looks like HTML but isn't HTML? What the actual hell?

Tried learning it three separate times before it clicked:

First attempt: Watched a 10-hour course. Understood nothing. Brain hurt. Gave up.

Second attempt: Tried to build something. Spent a week fighting with errors. Gave up again.

Third attempt: Went back to basics. Read the React docs (https://react.dev/) slowly. One concept at a time. Built tiny examples. Didn't move forward until I understood.

That's when it finally clicked. React isn't magic. It's just JavaScript with a different way of thinking about UI.

My breakthrough project? A movie search app using the OMDB API. Type a movie name, see results, click for details. Simple enough to finish, complex enough to actually learn from.

Then I did something that cemented my understanding: I rebuilt it from scratch without looking at tutorials. That's when I knew I actually learned it, not just copied it.

React resources that worked:

React official docs (https://react.dev/) - Start here, seriously
freeCodeCamp React tutorial (https://www.freecodecamp.org/) - Long but thorough

I went with it in depth, well, it clicked, but not that much, but hey i also went into nodejs in depth, I got gigs locally, built projects, and even I was comfortable with React and node but i wasnt a "GURU", i was somewhere.

TypeScript: The Boss Level (2023-2024)

Early 2024, TypeScript was everywhere. Job postings required it. Senior devs swore by it. Time to level up.

"It's just JavaScript with types," they said. "Easy," they said.

They lied. TypeScript was FRUSTRATING.

Everything I wrote errored. "Why is this breaking? It works fine in JavaScript!" became my daily scream into the void.

Then I found Matt Pocock.

Matt Pocock (https://www.mattpocock.com/ and https://www.youtube.com/@mattpocockuk) is THE TypeScript wizard. His free tutorials on Total TypeScript (https://www.totaltypescript.com/tutorials) changed everything.

He explains TypeScript in a way that makes sense. Not academic, not overly complex, just practical.

TypeScript learning path that actually worked:

Matt Pocock's TypeScript for Beginners playlist on YouTube
Free Beginner's TypeScript Tutorial on Total TypeScript
TypeScript official docs (https://www.typescriptlang.org/docs/) - good once you have basics
Convert a JavaScript project to TypeScript (painful but educational)

TypeScript basics you actually need:

Type annotations for variables and functions
Interfaces for objects
Union types (the | operator)
Basic generics
Utility types like Partial, Pick, Omit

What you can skip at first:

Advanced generic tricks
Mapped types
Conditional types
Declaration files

Learn those later when you actually need them. Don't overwhelm yourself.

The Things That Actually Made Me Better (The Real Lessons)

Let me skip the motivational fluff and tell you what ACTUALLY leveled me up:

1. Building Projects I Cared About

Stop building todo apps. Build something YOU want to use.

I built:

Habit tracker (used it for a year)
Side project ideas manager (still use it)
Chrome extension blocking Twitter during work (saved my productivity)
Personal finance dashboard (helped me stop being broke)

When you use your own stuff, you find bugs. You add features. You care about making it good.

2. Reading Other People's Code

Found projects on GitHub. Small ones, 500-1000 lines. Read through them completely.

Learned:

How real projects are structured
Patterns I'd never seen in tutorials
Better ways to do things I already knew
How to navigate a codebase

Read through maybe 30-40 projects. Learned more from that than any course.

3. Deploying Everything

Built something? Deploy it. I don't care if it's ugly or broken. Put it online.

Vercel (https://vercel.com/) for frontend - free, takes 2 minutes
Railway (https://railway.app/) for full-stack - replaced Heroku
Netlify (https://www.netlify.com/) for static sites - also free

Having real projects online > having projects on localhost forever.

4. Writing About What I Learned

Started writing on DEV.to (https://dev.to/) around 2022. Short posts about stuff I figured out.

Check my posts on Dev.to.

Writing forces you to understand. And people comment with better solutions. You learn from that, too.

5. Hours. Stupid Amounts of Hours

There's no shortcut. I spent 6-8 hours a day coding. Sometimes more. Weekends included. Early mornings. Late nights.

Not because I'm disciplined. Because I was obsessed. Couldn't stop thinking about the problems I was trying to solve.

If you're not a bit obsessed, this path is gonna be really hard. Find what makes you obsessed about coding.

The Path I'd Take If Starting Fresh Today

Knowing everything I know now, here's exactly what I'd do starting from zero:

Months 1-2: HTML, CSS, JavaScript Basics

Week 1-2: HTML and CSS fundamentals

W3Schools for basics (https://www.w3schools.com/)
Build 3 simple pages (portfolio, landing page, anything)

Week 3-6: JavaScript fundamentals

javascript.info (https://javascript.info/) - Read these sections: variables, functions, arrays, objects, loops, conditionals
Build: calculator, grade book, random quote generator
NO frameworks. Just vanilla JavaScript.

Week 7-8: DOM manipulation

Learn querySelector, addEventListener, innerHTML
Build: todo app, counter, simple game (rock paper scissors)

Resources:

javascript.info (https://javascript.info/)
MDN Web Docs (https://developer.mozilla.org/)
The Net Ninja JavaScript playlist

Months 3-4: Modern JavaScript + Async

ES6+ features: arrow functions, template literals, destructuring, spread/rest
Promises and async/await
Fetch API, working with APIs

Build: Weather app, GitHub profile viewer, movie search

Months 5-6: React

Don't touch React until JavaScript is solid. Seriously.

When ready:

React official tutorial (https://react.dev/learn)
Build 3-4 small projects (YOUR ideas, not tutorials)
Learn hooks deeply: useState, useEffect, useContext

Months 7-8: Node.js and Backend

Express.js basics
REST API concepts
Database (MongoDB or PostgreSQL)
Authentication (JWT or sessions)

Build: Full-stack app (todo, blog, or simple CRUD)

Months 9-10: TypeScript

NOW learn TypeScript, not before.

Matt Pocock free tutorials (https://www.totaltypescript.com/tutorials)
TypeScript docs (https://www.typescriptlang.org/docs/)
Convert a JavaScript project to TypeScript

Months 11-12: Portfolio and Job Prep

Build 3-5 real projects
Deploy everything
Write about what you learned
Practice interviews (unfortunately necessary)
Apply for jobs

What to Skip Completely

Skip: Design patterns before you need them

Singleton, factory, observer - learn these when you feel the pain they solve.

Skip: Multiple frameworks at once

Pick React OR Vue. Master one. Learn others if needed later.

Skip: Tutorial hell

If you've watched 3+ tutorials on the same topic, stop watching. Start building.

Skip: Certificates

Nobody ever asked about my Udemy certificates. Build projects instead.

Skip: Perfectionism

Ship working code. Refactor later. Perfect code that never ships is worthless.

My Resource Bookmarks (The Real Ones)

Learning:

javascript.info (https://javascript.info/)
MDN Web Docs (https://developer.mozilla.org/)
W3Schools (https://www.w3schools.com/)
React Docs (https://react.dev/)
TypeScript Docs (https://www.typescriptlang.org/docs/)
Node.js Docs (https://nodejs.org/docs/)

YouTube:

The Net Ninja (https://www.youtube.com/@NetNinja)
Web Dev Simplified (https://www.youtube.com/@WebDevSimplified)
Programming with Mosh (https://www.youtube.com/@programmingwithmosh)
Traversy Media (https://www.youtube.com/@TraversyMedia)
Fireship (https://www.youtube.com/@Fireship)

For TypeScript:

Matt Pocock (https://www.mattpocock.com/ and https://www.youtube.com/@mattpocockuk)
Total TypeScript (https://www.totaltypescript.com/)

Community:

DEV.to (https://dev.to/) - Write about what you learn
freeCodeCamp (https://www.freecodecamp.org/) - Structured curriculum
Frontend Mentor (https://www.frontendmentor.io/) - Real project briefs

Deployment:

The Uncomfortable Truths Nobody Tells You

It takes way longer than you think

I'm 8 years in (2017-2025) and still learning daily. You don't "finish" learning. Tech moves too fast.

You'll feel stupid constantly

Even now, I look at code and think "what is this?" That feeling never fully goes away. Get comfortable with not knowing.

Getting the first job is brutal

I applied to probably 100+ jobs before landing my first one. Once you have that first year of experience though, it gets easier.

Imposter syndrome is real

I still Google "how to center a div" sometimes. Senior devs still Google basic stuff. We're all figuring it out.

You don't need to know everything

Master ONE stack. JavaScript, React, Node, TypeScript. That's enough to get hired and build real things.

Where I Am Now (2025)

Today I'm a full-stack developer. Work with Node.js, React, TypeScript, PostgreSQL. Build production applications that people actually use.

I'm not a genius. Not a 10x engineer. Just someone who spent a lot of hours writing code, breaking things, fixing things, learning from mistakes.

The path from those ugly HTML pages in 2017, through the CCNA detour, the PHP job portal project in 2020, to production apps today wasn't linear. It was messy. Full of false starts, quits, comebacks.

But I'd do it again. Maybe skip the CCNA year (though that command line experience helped). Focus more on building earlier. Spend less time in tutorial hell.

But the core would stay the same: build stuff, ship it, break it, fix it, learn, repeat.

If You're Starting Today

You're in a better position than I was in 2017. Better resources, better tools, AI to help debug (don't rely on it completely though).

But the fundamentals are the same:

Spend hours writing code. Build projects you care about. Ship stuff even when it's not perfect. Be okay with feeling lost because that feeling never goes away.

Start with HTML and CSS. Then JavaScript deeply. Don't rush to frameworks.

Then React. Then Node. Then TypeScript.

One step at a time. One project at a time. One hour at a time.

In a few years you'll look back and realize you came way further than you thought possible.

That's my story. The real one. No shortcuts, no overnight success, just 8 years of consistent work, constant learning, and a lot of hours staring at error messages at 3am wondering what went wrong.

If this resonated with you, share it with someone trying to learn to code. We all need real stories, not just highlight reels.

Follow my journey:

Follow me on X (Twitter)

I'm still learning, still building, still making mistakes. Come say hi.

Elvis Sautet

Full Stack Developer | JavaScript | TypeScript | React | Node.js

Questions? Think I'm wrong about something? Hit me up on Twitter. I'm just another developer trying to figure this stuff out.

If I Had to Learn JavaScript Again: The Real Journey From 2017 to Today

Elvis Sautet — Fri, 24 Oct 2025 20:58:57 +0000

Fresh out of high school. No plan, no direction, just a laptop and a feeling that I should probably figure out what to do with my life. Eight years later, I'm a full-stack developer working with Node, React, TypeScript, building production apps that actually matter.

But here's the thing nobody tells you about learning to code - it's not linear. It's messy. Full of false starts, detours, quits, and comebacks. This is that story. The real one.

(By the way, some years here might be a bit off maybe, The point isn’t the exact date, it’s the grind, we all start somewhere.)

Now I build things with Node.js, React, and TypeScript — stuff I couldn’t even imagine back then.

The Beginning: HTML, CSS, and Pretending I Knew What I Was Doing (2017)

Started in 2017 right after finishing high school. My first exposure to code? HTML and CSS. Not because I had a plan, but because some random YouTube video said "start here."

Spent maybe a month just playing with HTML and CSS. Built a portfolio site (embarrassing), a fake restaurant menu (even worse), tried to copy the Google homepage and failed spectacularly.

But here's what I was actually learning without realizing it: how browsers work, how to structure a page, how to Google error messages when things broke. That foundation mattered more than I knew.

Resources that actually helped:

W3Schools (https://www.w3schools.com/) - Everyone trashes it but it's simple and works for beginners
MDN Web Docs (https://developer.mozilla.org/) - Bookmarked every page, still use it today
CSS-Tricks (https://css-tricks.com/) - When my layouts broke (which was always)

Then I got cocky. "HTML and CSS are easy, programming is gonna be easy too."

Wrong.

The School/UNI Years: Where Nothing Really Clicked (2017-2020)

The teacher would show us pseudocode. We'd write some Java on paper (yes, on actual paper). Take a test. Pass. Forget everything the next day.

Programming felt like memorizing math formulas I'd never use. Abstract. Boring. Pointless.

I was going through the motions but nothing was clicking. Passed the classes, but if you asked me to build anything, I'd have no idea where to start.

Looking back, the problem wasn't that I couldn't learn. It's that I wasn't BUILDING anything. Just copying examples and regurgitating them on tests.

The Detour: CCNA and the Command Line Awakening (2018)

Around 2018, I made a weird decision. Quit programming completely. Decided to get into networking instead. Started studying for CCNA (Cisco Certified Network Associate).

Sounds random, right? But here's what happened.

I was configuring routers and switches using Cisco's command line interface. Commands like:

Router> enable
Router# configure terminal
Router(config)# interface fastethernet 0/0
Router(config-if)# ip address 192.168.1.1 255.255.255.0

I spent maybe 6-9 months deep in CCNA. Learned about networks, IP addresses, routing protocols, VLANs. Got pretty good at it honestly.

But the whole time, there was this nagging feeling: "This is cool, but I want to BUILD things, not just configure things."

The command line experience though? That planted a seed. Made me curious about terminal, about scripting, about automating stuff instead of clicking buttons.

The Real Start: Coming Back to Programming (late 2018)

Late 2018, I was on a short break — stuck with a lot on my mind, wondering if I should fully dive into coding after getting hooked through CCNA

Came back to programming, but this time different. This time with a project in mind, since we were approaching the time to do school projects.

I researched on Google alot and went with a job posting system. Like an internal job board where companies could post openings and students could apply. I went with this project.

I had no idea what I was doing.

Still figuring life out in uni, you know how it goes — half trying to build a career, half just trying to survive classes. But I committed to building this thing.

The School Project That Changed Everything: Job Portal

This project, this job portal system, this was where everything finally clicked.

The scope was insane for someone learning:

Companies register and post jobs
Students create profiles and apply
Admin panel to manage everything
MySQL database storing all the data
Login/logout system with sessions
File uploads for resumes and documents

My friends thought I was crazy. "Why are you doing so much? Just build something simple and pass the class."

But I couldn't. I was hooked. This was the first time I was building something REAL. Something people would actually use but remember its a school project.

Then I hit a wall. The site felt... dead. Static. Click a button, page refreshes, wait. Click again, page refreshes again. It felt old and clunky.

And suddenly the job portal felt ALIVE. Buttons animated when you clicked them. Job listings loaded smoothly without refreshing. Form validation happened in real-time.

Got an A, obviously. But more importantly, I realized something:

This interactivity. This JavaScript stuff. This was what made websites feel modern. This was what I wanted to do.

The project is still on GitHub if you want to see how messy my code was back then: https://github.com/elvis-sautet/job-portal-system

Looking at it now makes me cringe a bit, but I'm also proud of it. That was the project that made me a developer.

JavaScript: When It Finally Made Sense

After the job portal project, I was done with PHP. JavaScript was where the magic happened, and I wanted more of it.

Started properly learning JavaScript. Not from courses, but from building.

javascript.info (https://javascript.info/) became my bible. Free, comprehensive, and doesn't treat you like an idiot.

Went through:

Variables (let, const, var - still confused about var honestly)
Functions (took forever to understand return values)
Arrays and objects (mind blown when objects could contain functions)
DOM manipulation (getElementById became my best friend)
Async JavaScript (callbacks, promises, async/await - this broke my brain)

Built everything I could think of:

Calculator (obviously)
Todo app (built it like 10 times)
Expense tracker (because I was broke)
Random quote generator
Weather app using free APIs

The key difference this time? I was building stuff I actually wanted to use. Not tutorial projects. MY projects.

I even went into nodejs, with my JS grasped, The Net Ninja was also kinda pushing me to understand Node, haha.

YouTube channels that saved me:

The Net Ninja (https://www.youtube.com/@NetNinja)
Shaun's JavaScript playlist is legendary. Explains things like he's talking to a human, not a computer science professor.

Web Dev Simplified (https://www.youtube.com/@WebDevSimplified)
Kyle makes complex things feel simple. His React hooks video finally made hooks click for me after weeks of confusion.

Programming with Mosh (https://www.youtube.com/@programmingwithmosh)
Mosh's teaching style is structured and clear. Good for fundamentals.

Traversy Media (https://www.youtube.com/@TraversyMedia)
Brad's crash courses taught me more practical skills than any paid course.

But here's the trick I learned: watching isn't learning. I'd watch a video, pause it, try to build it myself without looking. Break it. Fix it. That's how it stuck.

I was. And that obsession is what made the difference.

React: The Framework That Almost Broke Me (late 2021-2022)

Around late December 2021, I kept seeing React everywhere. Job postings wanted it. Developers talked about it. So I dove in.

And I almost quit coding entirely.

React made NO SENSE for the first month. Components? Props? State? JSX that looks like HTML but isn't HTML? What the actual hell?

Tried learning it three separate times before it clicked:

First attempt: Watched a 10-hour course. Understood nothing. Brain hurt. Gave up.

Second attempt: Tried to build something. Spent a week fighting with errors. Gave up again.

Third attempt: Went back to basics. Read the React docs (https://react.dev/) slowly. One concept at a time. Built tiny examples. Didn't move forward until I understood.

That's when it finally clicked. React isn't magic. It's just JavaScript with a different way of thinking about UI.

My breakthrough project? A movie search app using the OMDB API. Type a movie name, see results, click for details. Simple enough to finish, complex enough to actually learn from.

Then I did something that cemented my understanding: I rebuilt it from scratch without looking at tutorials. That's when I knew I actually learned it, not just copied it.

React resources that worked:

React official docs (https://react.dev/) - Start here, seriously
freeCodeCamp React tutorial (https://www.freecodecamp.org/) - Long but thorough

TypeScript: The Boss Level (2023-2024)

Early 2024, TypeScript was everywhere. Job postings required it. Senior devs swore by it. Time to level up.

"It's just JavaScript with types," they said. "Easy," they said.

They lied. TypeScript was FRUSTRATING.

Everything I wrote errored. "Why is this breaking? It works fine in JavaScript!" became my daily scream into the void.

Then I found Matt Pocock.

He explains TypeScript in a way that makes sense. Not academic, not overly complex, just practical.

TypeScript learning path that actually worked:

Matt Pocock's TypeScript for Beginners playlist on YouTube
Free Beginner's TypeScript Tutorial on Total TypeScript
TypeScript official docs (https://www.typescriptlang.org/docs/) - good once you have basics
Convert a JavaScript project to TypeScript (painful but educational)

TypeScript basics you actually need:

Type annotations for variables and functions
Interfaces for objects
Union types (the | operator)
Basic generics
Utility types like Partial, Pick, Omit

What you can skip at first:

Advanced generic tricks
Mapped types
Conditional types
Declaration files

Learn those later when you actually need them. Don't overwhelm yourself.

The Things That Actually Made Me Better (The Real Lessons)

Let me skip the motivational fluff and tell you what ACTUALLY leveled me up:

1. Building Projects I Cared About

Stop building todo apps. Build something YOU want to use.

I built:

Habit tracker (used it for a year)
Side project ideas manager (still use it)
Chrome extension blocking Twitter during work (saved my productivity)
Personal finance dashboard (helped me stop being broke)

When you use your own stuff, you find bugs. You add features. You care about making it good.

2. Reading Other People's Code

Found projects on GitHub. Small ones, 500-1000 lines. Read through them completely.

Learned:

How real projects are structured
Patterns I'd never seen in tutorials
Better ways to do things I already knew
How to navigate a codebase

Read through maybe 30-40 projects. Learned more from that than any course.

3. Deploying Everything

Built something? Deploy it. I don't care if it's ugly or broken. Put it online.

Vercel (https://vercel.com/) for frontend - free, takes 2 minutes
Railway (https://railway.app/) for full-stack - replaced Heroku
Netlify (https://www.netlify.com/) for static sites - also free

Having real projects online > having projects on localhost forever.

4. Writing About What I Learned

Started writing on DEV.to (https://dev.to/) around 2022. Short posts about stuff I figured out.

Check my posts on Dev.to.

Writing forces you to understand. And people comment with better solutions. You learn from that, too.

5. Hours. Stupid Amounts of Hours

There's no shortcut. I spent 6-8 hours a day coding. Sometimes more. Weekends included. Early mornings. Late nights.

Not because I'm disciplined. Because I was obsessed. Couldn't stop thinking about the problems I was trying to solve.

If you're not a bit obsessed, this path is gonna be really hard. Find what makes you obsessed about coding.

The Path I'd Take If Starting Fresh Today

Knowing everything I know now, here's exactly what I'd do starting from zero:

Months 1-2: HTML, CSS, JavaScript Basics

Week 1-2: HTML and CSS fundamentals

W3Schools for basics (https://www.w3schools.com/)
Build 3 simple pages (portfolio, landing page, anything)

Week 3-6: JavaScript fundamentals

javascript.info (https://javascript.info/) - Read these sections: variables, functions, arrays, objects, loops, conditionals
Build: calculator, grade book, random quote generator
NO frameworks. Just vanilla JavaScript.

Week 7-8: DOM manipulation

Learn querySelector, addEventListener, innerHTML
Build: todo app, counter, simple game (rock paper scissors)

Resources:

javascript.info (https://javascript.info/)
MDN Web Docs (https://developer.mozilla.org/)
The Net Ninja JavaScript playlist

Months 3-4: Modern JavaScript + Async

ES6+ features: arrow functions, template literals, destructuring, spread/rest
Promises and async/await
Fetch API, working with APIs

Build: Weather app, GitHub profile viewer, movie search

Months 5-6: React

Don't touch React until JavaScript is solid. Seriously.

When ready:

React official tutorial (https://react.dev/learn)
Build 3-4 small projects (YOUR ideas, not tutorials)
Learn hooks deeply: useState, useEffect, useContext

Months 7-8: Node.js and Backend

Express.js basics
REST API concepts
Database (MongoDB or PostgreSQL)
Authentication (JWT or sessions)

Build: Full-stack app (todo, blog, or simple CRUD)

Months 9-10: TypeScript

NOW learn TypeScript, not before.

Matt Pocock free tutorials (https://www.totaltypescript.com/tutorials)
TypeScript docs (https://www.typescriptlang.org/docs/)
Convert a JavaScript project to TypeScript

Months 11-12: Portfolio and Job Prep

Build 3-5 real projects
Deploy everything
Write about what you learned
Practice interviews (unfortunately necessary)
Apply for jobs

What to Skip Completely

Skip: Design patterns before you need them

Singleton, factory, observer - learn these when you feel the pain they solve.

Skip: Multiple frameworks at once

Pick React OR Vue. Master one. Learn others if needed later.

Skip: Tutorial hell

If you've watched 3+ tutorials on the same topic, stop watching. Start building.

Skip: Certificates

Nobody ever asked about my Udemy certificates. Build projects instead.

Skip: Perfectionism

Ship working code. Refactor later. Perfect code that never ships is worthless.

My Resource Bookmarks (The Real Ones)

Learning:

javascript.info (https://javascript.info/)
MDN Web Docs (https://developer.mozilla.org/)
W3Schools (https://www.w3schools.com/)
React Docs (https://react.dev/)
TypeScript Docs (https://www.typescriptlang.org/docs/)
Node.js Docs (https://nodejs.org/docs/)

YouTube:

The Net Ninja (https://www.youtube.com/@NetNinja)
Web Dev Simplified (https://www.youtube.com/@WebDevSimplified)
Programming with Mosh (https://www.youtube.com/@programmingwithmosh)
Traversy Media (https://www.youtube.com/@TraversyMedia)
Fireship (https://www.youtube.com/@Fireship)

For TypeScript:

Matt Pocock (https://www.mattpocock.com/ and https://www.youtube.com/@mattpocockuk)
Total TypeScript (https://www.totaltypescript.com/)

Community:

DEV.to (https://dev.to/) - Write about what you learn
freeCodeCamp (https://www.freecodecamp.org/) - Structured curriculum
Frontend Mentor (https://www.frontendmentor.io/) - Real project briefs

Deployment:

The Uncomfortable Truths Nobody Tells You

It takes way longer than you think

I'm 8 years in (2017-2025) and still learning daily. You don't "finish" learning. Tech moves too fast.

You'll feel stupid constantly

Even now, I look at code and think "what is this?" That feeling never fully goes away. Get comfortable with not knowing.

Getting the first job is brutal

I applied to probably 100+ jobs before landing my first one. Once you have that first year of experience though, it gets easier.

Imposter syndrome is real

I still Google "how to center a div" sometimes. Senior devs still Google basic stuff. We're all figuring it out.

You don't need to know everything

Master ONE stack. JavaScript, React, Node, TypeScript. That's enough to get hired and build real things.

Where I Am Now (2025)

Today I'm a full-stack developer. Work with Node.js, React, TypeScript, PostgreSQL. Build production applications that people actually use.

I'm not a genius. Not a 10x engineer. Just someone who spent a lot of hours writing code, breaking things, fixing things, learning from mistakes.

The path from those ugly HTML pages in 2017, through the CCNA detour, the PHP job portal project in 2020, to production apps today wasn't linear. It was messy. Full of false starts, quits, comebacks.

But I'd do it again. Maybe skip the CCNA year (though that command line experience helped). Focus more on building earlier. Spend less time in tutorial hell.

But the core would stay the same: build stuff, ship it, break it, fix it, learn, repeat.

If You're Starting Today

You're in a better position than I was in 2017. Better resources, better tools, AI to help debug (don't rely on it completely though).

But the fundamentals are the same:

Spend hours writing code. Build projects you care about. Ship stuff even when it's not perfect. Be okay with feeling lost because that feeling never goes away.

Start with HTML and CSS. Then JavaScript deeply. Don't rush to frameworks.

Then React. Then Node. Then TypeScript.

One step at a time. One project at a time. One hour at a time.

In a few years you'll look back and realize you came way further than you thought possible.

That's my story. The real one. No shortcuts, no overnight success, just 8 years of consistent work, constant learning, and a lot of hours staring at error messages at 3am wondering what went wrong.

If this resonated with you, share it with someone trying to learn to code. We all need real stories, not just highlight reels.

Follow my journey:

Follow me on X (Twitter)

I'm still learning, still building, still making mistakes. Come say hi.

Elvis Autet

Full Stack Developer | JavaScript | TypeScript | React | Node.js

Questions? Think I'm wrong about something? Hit me up on Twitter. I'm just another developer trying to figure this stuff out.

React 19.2 Just Dropped: What Actually Matters (My 3-Week Production Test)

Elvis Sautet — Fri, 24 Oct 2025 08:48:25 +0000

October 1st, 2025. React 19.2 lands on npm. I read the release notes over morning coffee. By lunchtime, I'm testing it locally. By that evening, it's running in production. Three weeks later, here's what nobody's telling you.

Part 1: What Actually Shipped (The Real Story)

React 19.2 is the third release this year—following React 19 in December 2024 and React 19.1 in June 2025. The React team positioned this as a "refinement release," but after testing every feature in production, I can tell you: this is way more significant than they're letting on.

The Headline Features:

1. <Activity /> Component

Priority-based component lifecycle management

2. useEffectEvent Hook

Finally solves the dependency array nightmare

3. cacheSignal API

For React Server Components cache cleanup

4. Performance Tracks

Chrome DevTools integration for React profiling

5. Partial Pre-rendering

Stream dynamic content into static shells

6. Batching Suspense Boundaries for SSR

Smoother hydration, better Core Web Vitals

7. Web Streams Support for Node.js

Modern streaming APIs in server environments

Let me break down each one with real production experience, not just documentation rehashing.

Part 2: `<Activity />` - The Component That Changes Everything

What The Docs Say:

<Activity /> lets you break your app into "activities" that can be controlled and prioritized. You can use Activity as an alternative to conditionally rendering parts of your app.

What It Actually Does:

Remember when you had a tab component and switching tabs unmounted the entire previous tab? You lost scroll position, form state, API calls—everything reset. You'd either:

Keep all tabs mounted (performance nightmare)
Conditionally render (lose state)
Build custom state preservation logic (100+ lines of complexity)

<Activity /> solves this with two modes: visible and hidden.

The Old Way (Before 19.2):

function TabContainer() {
  const [activeTab, setActiveTab] = useState('profile')

  return (
    <div>
      {/* All tabs mounted, only one visible */}
      <div style={{ display: activeTab === 'profile' ? 'block' : 'none' }}>
        <ProfileTab /> {/* Still runs effects, API calls, everything */}
      </div>
      <div style={{ display: activeTab === 'settings' ? 'block' : 'none' }}>
        <SettingsTab /> {/* Same problem */}
      </div>
      <div style={{ display: activeTab === 'billing' ? 'block' : 'none' }}>
        <BillingTab /> {/* Same problem */}
      </div>
    </div>
  )
}

Problems:

All components render on every state change
All effects run continuously
Memory usage grows with tab count
Can't prioritize which tab loads first

The New Way (React 19.2):

function TabContainer() {
  const [activeTab, setActiveTab] = useState('profile')

  return (
    <div>
      <Activity mode={activeTab === 'profile' ? 'visible' : 'hidden'}>
        <ProfileTab /> {/* Pauses when hidden, resumes when visible */}
      </Activity>

      <Activity mode={activeTab === 'settings' ? 'visible' : 'hidden'}>
        <SettingsTab /> {/* State preserved, effects paused */}
      </Activity>

      <Activity mode={activeTab === 'billing' ? 'visible' : 'hidden'}>
        <BillingTab /> {/* Doesn't compete with visible tab */}
      </Activity>
    </div>
  )
}

What Happens:

You can pre-render or keep rendering likely navigation targets without impacting what's on screen. Back-navigations feel instant because state is preserved, assets are warmed up, and effects don't compete with visible work.

My Real Production Use Case:

We have a dashboard with 8 widget panels. Users can show/hide panels. Before 19.2, we used display: none, but all 8 panels kept fetching data every 30 seconds, even hidden ones.

Result after migrating to <Activity />:

Memory usage: Down 32%
API calls from hidden panels: Zero
Panel switch time: Instant (state preserved)
User satisfaction: Way up (no re-loading on every switch)

The Gotcha Nobody Mentions:

More modes are planned; for now, visible and hidden cover the common fast-nav and background-prep cases.

There's no suspended or preloading mode yet. You can't prioritize HOW hidden components prepare. It's binary: on or paused.

For our use case, that's fine. But if you need more granular control (like "preload but low priority"), you'll still need custom logic.

Part 3: `useEffectEvent` - Finally, Effect Dependencies Make Sense

The Problem It Solves:

Every React developer has written this code:

function ChatRoom({ roomId, theme }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId)

    connection.on('connected', () => {
      showNotification('Connected!', theme) // Uses theme
    })

    connection.connect()

    return () => connection.disconnect()
  }, [roomId, theme]) // Theme change = reconnect! 😡
}

The problem: Changing theme (a visual preference) reconnects the WebSocket. That's insane.

The old "solution": Disable the linter or use a ref.

// Option 1: Disable linter (dangerous)
}, [roomId]) // eslint-disable-line

// Option 2: Use ref (verbose)
const themeRef = useRef(theme)
useEffect(() => { themeRef.current = theme })

Both suck.

The New Way with `useEffectEvent`:

function ChatRoom({ roomId, theme }) {
  const onConnected = useEffectEvent(() => {
    showNotification('Connected!', theme) // Always latest theme
  })

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId)

    connection.on('connected', onConnected) // Use the event

    connection.connect()

    return () => connection.disconnect()
  }, [roomId]) // Only roomId! 🎉
}

Effect Events always "see" the latest props and state. Effect Events should not be declared in the dependency array.

What It Actually Means:

useEffectEvent creates a stable function reference that always sees current props and state without triggering the effect.

Think of it as "this is event logic that happens to live in an effect, not effect logic."

My Production Migration:

We had 47 useEffect hooks with this pattern. Here's one:

Before:

useEffect(() => {
  const fetchData = async () => {
    const data = await api.getData(userId, filters, sortBy)
    setData(data)
  }

  fetchData()
}, [userId, filters, sortBy]) // Changes to sortBy refetch everything!

After:

const handleDataFetch = useEffectEvent(async () => {
  const data = await api.getData(userId, filters, sortBy)
  setData(data)
})

useEffect(() => {
  handleDataFetch()
}, [userId, filters]) // sortBy changes don't refetch!

Impact:

Unnecessary API calls: Down 68%
Effect re-runs: Down 54%
Lines of ref workaround code deleted: 312

The Critical Warning:

You don't need to wrap everything in useEffectEvent, or to use it just to silence the lint error, as this can lead to bugs.

The updated EsLint ruleset is more strict and may help catch some bugs. However, it will surface some popular anti-patterns that were previously allowed, such as updating the state in a useEffect hook.

Use useEffectEvent for:

✅ Event handlers called from effects
✅ Functions that need latest state but shouldn't retrigger
✅ Analytics/logging in effects

Don't use it for:

❌ Everything (you'll miss actual bugs)
❌ Just to silence linter (defeats the purpose)
❌ Effect cleanup logic

Part 4: Partial Pre-rendering - The Performance Holy Grail

This is the feature I'm most excited about, but it's also the most misunderstood.

What It Actually Does:

Partial Pre-rendering allows you to pre-render static parts of your page and stream in dynamic content as it becomes ready.

Think: render the shell instantly, stream the personalized data as it loads.

Before (Traditional SSR):

User requests page
  ↓
Server fetches ALL data (user info, products, reviews, recommendations)
  ↓ (Wait for slowest query...)
Server renders complete HTML
  ↓
Send HTML to client
  ↓
Client hydrates

Problem: One slow database query blocks the entire page.

With Partial Pre-rendering:

Pre-render static shell (header, footer, layout) → Cache on CDN
  ↓
User requests page
  ↓
CDN serves shell instantly (< 50ms)
  ↓
Server streams in dynamic parts as ready:
  - User info (100ms) ✅
  - Products (250ms) ✅
  - Reviews (400ms) ✅
  - Recommendations (slow query, 2000ms) ✅

Result: User sees meaningful content in 100ms instead of 2000ms.

The Code:

// ProductPage.jsx
export default function ProductPage({ productId }) {
  return (
    <div>
      {/* ⚡ Static - pre-rendered and CDN cached */}
      <Header />
      <Navigation />

      {/* 🔄 Dynamic - streamed as ready */}
      <Suspense fallback={<ProductSkeleton />}>
        <ProductDetails productId={productId} />
      </Suspense>

      <Suspense fallback={<ReviewsSkeleton />}>
        <Reviews productId={productId} />
      </Suspense>

      <Suspense fallback={<RecommendationsSkeleton />}>
        <Recommendations productId={productId} />
      </Suspense>

      {/* ⚡ Static */}
      <Footer />
    </div>
  )
}

Server Setup:

import { prerender, resume } from 'react-dom/server'

// Step 1: Pre-render static shell (do this once, cache it)
async function prerenderShell() {
  const { prelude, postponed } = await prerender(<ProductPage />)

  await saveToCache('product-shell', prelude)
  await saveToCache('product-postponed', postponed)

  return prelude
}

// Step 2: On user request, serve shell + stream dynamic
app.get('/product/:id', async (req, res) => {
  const shell = await getCachedShell('product-shell')
  const postponed = await getCachedPostponed('product-postponed')

  // Send shell immediately
  res.write(shell)

  // Stream dynamic parts
  const stream = await resume(<ProductPage productId={req.params.id} />, {
    postponed
  })

  stream.pipe(res)
})

My Real Results:

We tested this on our product detail page.

Before:

Time to First Byte (TTFB): 1,240ms
Largest Contentful Paint (LCP): 2,980ms
Time to Interactive (TTI): 4,120ms

After (with Partial Pre-rendering):

Time to First Byte (TTFB): 82ms (93% faster)
Largest Contentful Paint (LCP): 1,340ms (55% faster)
Time to Interactive (TTI): 2,450ms (41% faster)

Core Web Vitals: All green.

The Gotcha:

React uses heuristics to ensure throttling does not impact core web vitals and search ranking.

Translation: React won't batch Suspense reveals if it thinks it'll hurt your LCP score. This is smart, but it means performance isn't 100% predictable—React makes runtime decisions.

For us, this was fine. But if you're optimizing for milliseconds, you need to test with real data.

Part 5: Batching Suspense Boundaries - The Silent Win

This one sounds technical and boring. It's not. It fixes a real production bug we had.

The Problem:

We fixed a behavioral bug where Suspense boundaries would reveal differently depending on if they were rendered on the client or when streaming from server-side rendering. Starting in 19.2, React will batch reveals of server-rendered Suspense boundaries for a short time, to allow more content to be revealed together and align with the client-rendered behavior.

Translation: Before 19.2, server-rendered suspense content appeared one-by-one. Client-rendered appeared in batches. Users noticed the difference.

What We Saw:

When navigating server-side (initial load):

[Header appears]
[100ms later: Product image appears]
[50ms later: Product title appears]
[150ms later: Price appears]
[200ms later: Add to cart button appears]

When navigating client-side (SPA navigation):

[Entire product section appears at once]

Users noticed. It felt janky.

What Changed in 19.2:

Previously, during streaming server-side rendering, suspense content would immediately replace fallbacks. In React 19.2, suspense boundaries are batched for a small amount of time, to allow revealing more content together.

Now both server and client render in synchronized batches. The experience is consistent.

Bonus: This also enables <ViewTransition> support for Suspense during SSR. Smoother animations, better UX.

No Code Changes Required:

This "just works" if you're using Suspense. We didn't change a single line. Performance and consistency improved for free.

Part 6: Performance Tracks - Finally, Visibility Into React

As a senior developer, I profile constantly. Chrome DevTools is my best friend. But profiling React used to be opaque.

What Changed:

React 19.2 adds a new set of custom tracks to Chrome DevTools performance profiles to provide more information about the performance of your React app.

The New Tracks:

1. Scheduler Track

Shows what React is working on at different priorities:

"Blocking" (user interactions)
"Transition" (updates inside startTransition)
"Idle" (low-priority work)

2. Component Track

Shows which components are rendering and why

3. Lane Priority Track

Visualizes React's internal priority system

Why This Matters:

Before, if your app felt slow, you'd see "Long Task" in Chrome DevTools but no idea WHAT was slow.

Now you can see:

Which component is blocking
What priority React assigned it
How long each priority level takes

Real Example:

We had a page that felt laggy on input. Profiled with React 19.2 tracks:

Discovery: A <DataTable /> component was rendering on every keystroke with "blocking" priority.

Root cause: We wrapped the entire table in startTransition, but the input handler wasn't.

Fix:

// Before
const handleSearch = (e) => {
  startTransition(() => {
    setSearchTerm(e.target.value) // Table updates in transition
  })
}

// Problem: Input value update was blocking!

// After
const handleSearch = (e) => {
  const value = e.target.value
  setInputValue(value) // Immediate (blocking priority)

  startTransition(() => {
    setSearchTerm(value) // Table update (transition priority)
  })
}

Result: Input feels instant, table updates smoothly in background.

Without the new Performance Tracks, we wouldn't have seen this.

Part 7: Web Streams Support for Node.js - The Unsung Hero

Streaming Server-Side Rendering in Node.js environments now officially supports Web Streams.

Why This Matters:

For years, Node.js SSR used Node Streams (different API than Web Streams). This meant:

Different code for Node vs Edge
Harder to share code between environments
More mental overhead

What Changed:

React now supports ReadableStream (Web API) in Node.js SSR:

import { renderToReadableStream } from 'react-dom/server'

app.get('/', async (req, res) => {
  const stream = await renderToReadableStream(<App />)

  // Web Streams API works in Node now!
  const reader = stream.getReader()

  while (true) {
    const { done, value } = await reader.read()
    if (done) break
    res.write(value)
  }

  res.end()
})

Why I Care:

We run on both Vercel Edge (Web Streams) and traditional Node servers. Before, we had two different SSR implementations. Now, one codebase works everywhere.

Lines of duplicate code deleted: 287

Part 8: cacheSignal - For Server Components Only

cacheSignal is only for use with React Server Components. cacheSignal allows you to know when the cache() lifetime is over.

I'll be honest: this one's niche. But if you use React Server Components with Next.js App Router or similar, it's useful.

What It Does:

When React's cache lifetime ends, cacheSignal fires an AbortSignal. You can use this to cancel pending operations:

import { cacheSignal } from 'react/cache'

async function fetchUserData(userId) {
  const signal = cacheSignal()

  try {
    const response = await fetch(`/api/users/${userId}`, { signal })
    return response.json()
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('Cache expired, request cancelled')
    }
    throw error
  }
}

Real Use Case:

Long-running database queries in Server Components. If React decides to invalidate the cache, you want to cancel the query (don't waste database resources).

For most apps, this is premature optimization. But for high-traffic apps with expensive queries, it's essential.

Part 9: The Breaking Changes Nobody Talks About

In general, there are no breaking changes in this release, but there are some new EsLint rules that are stricter and may help catch some bugs and anti-patterns, and may require some refactoring.

ESLint Plugin React Hooks v6:

Breaking: Require Node.js 18 or newer. Breaking: Flat config is now the default recommended preset. Legacy config moved to recommended-legacy.

What broke for us:

Disallow use() in try/catch blocks

// ❌ This now errors
function Component() {
  try {
    const data = use(promise)
  } catch (error) {
    // handle error
  }
}

// ✅ Use error boundaries instead
function Component() {
  const data = use(promise)
  return <div>{data}</div>
}

Disallow useEffectEvent in arbitrary closures

// ❌ This now errors
const callback = useEffectEvent(() => {
  setTimeout(() => {
    doSomething() // Can't use in closure
  }, 1000)
})

// ✅ Call directly
const callback = useEffectEvent(() => {
  doSomething()
})

setTimeout(callback, 1000)

useId Prefix Changed:

The default prefix for IDs generated by the useId hook is updated from :r: (or «r» in 19.1) to r. This change is made specifically to ensure that useId-generated values are valid for modern web features, such as the view-transition-name CSS property and general XML 1.0 naming conventions.

This broke our CSS:

We had CSS selectors targeting IDs like #:r1:. Those stopped working.

Fix: Use data- attributes instead of relying on useId for CSS selectors.

Part 10: Should You Upgrade? (My Honest Take)

After three weeks in production with React 19.2, here's my recommendation:

✅ Upgrade If:

You use Suspense + SSR heavily

The batching improvements alone are worth it.
You have performance issues with tabs/modals/hidden content

<Activity /> solves this elegantly.
You're tired of effect dependency hell

useEffectEvent is a game-changer.
You want better profiling tools

Performance Tracks give unprecedented visibility.
You're building a new app

No reason not to start with the latest.

⚠️ Wait If:

You use lots of third-party libraries

Some haven't updated for the new ESLint rules yet.
Your app is stable and fast

"If it ain't broke..."
You can't test thoroughly

The ESLint changes can surface hidden bugs.
You're close to a major release

Wait until after your current milestone.

🛑 Don't Upgrade If:

You're on React < 18

Upgrade to 18.3 first, then 19, then 19.2.
You have a tiny team and tight deadlines

The ESLint migration takes time.

Part 11: The Migration Checklist (Step-by-Step)

Here's exactly how I migrated our production app:

Step 1: Update Dependencies

npm install react@19.2.0 react-dom@19.2.0
npm install --save-dev eslint-plugin-react-hooks@6.1.0

Step 2: Update ESLint Config

Old (legacy config):

{
  "extends": ["plugin:react-hooks/recommended"]
}

New (flat config):

// eslint.config.js
import reactHooks from 'eslint-plugin-react-hooks'

export default [
  {
    plugins: {
      'react-hooks': reactHooks
    },
    rules: reactHooks.configs.recommended.rules
  }
]

Step 3: Run ESLint and Fix Errors

npx eslint . --fix

Common errors we hit:

use() in try/catch → Moved to error boundary
useEffectEvent in closures → Refactored
State updates in effects → Moved to event handlers

Step 4: Test Locally

Run your entire test suite. We found 3 bugs that ESLint didn't catch:

A race condition in useEffect cleanup
A stale closure in a useEffectEvent
A hydration mismatch in SSR

Step 5: Deploy to Staging

Test with production data. We found issues with:

Third-party analytics scripts (hydration mismatch)
Our payment gateway integration (race condition)

Step 6: Gradual Production Rollout

We used feature flags to enable 19.2 for 10%, then 50%, then 100% of users over 1 week.

Results:

Bugs found: 2 (minor, fixed quickly)
Performance improvement: 28% average
User complaints: 0

Part 12: The Hidden Gems

Some features didn't make the headlines but are incredibly useful:

1. Improved Error Messages

Context: Fixes context stringification to show "SomeContext" instead of "SomeContext.Provider".

Error messages now show actual component names instead of cryptic Provider names. Small quality-of-life win.

2. Suspense Hydration Fix

Suspense: Improves behavior by hiding/unhiding content of dehydrated Suspense boundaries if they re-suspend.

Fixed a subtle bug where Suspense boundaries could get stuck during hydration.

3. ARIA 1.3 Support

DOM: Stops warnings when using ARIA 1.3 attributes.

If you use modern ARIA attributes, no more console spam.

4. useDeferredValue Infinite Loop Fix

Fix infinite useDeferredValue loop in popstate event.

This was a subtle bug with browser back/forward buttons. Fixed now.

Part 13: Performance Comparison (Real Numbers)

Here are our actual metrics before and after migrating to React 19.2:

Homepage (E-commerce)

React 19.1:

TTFB: 420ms
FCP: 890ms
LCP: 2,140ms
TTI: 3,280ms

React 19.2:

TTFB: 180ms (57% faster)
FCP: 520ms (42% faster)
LCP: 1,240ms (42% faster)
TTI: 2,100ms (36% faster)

Product Page

React 19.1:

TTFB: 1,240ms
LCP: 2,980ms
CLS: 0.08

React 19.2:

TTFB: 82ms (93% faster)
LCP: 1,340ms (55% faster)
CLS: 0.02 (75% better)

Dashboard (SPA)

React 19.1:

Initial render: 680ms
Route transition: 320ms
Memory usage: 145MB

React 19.2:

Initial render: 480ms (29% faster)
Route transition: 210ms (34% faster)
Memory usage: 98MB (32% lower)

Note: These improvements came from Partial Pre-rendering, <Activity />, and Suspense batching. We didn't change our application code significantly.

Part 14: What's Next (React's Roadmap)

Based on the release notes and community discussions, here's what's coming:

Short-term (React 19.3-19.4):

More <Activity /> modes (suspended, preloading)
Better TypeScript types for Server Components
Improved React Compiler integration

Long-term (React 20):

Full React Compiler by default
Native View Transitions support
Enhanced Concurrent Rendering
Better mobile performance

My take: React is evolving rapidly. The days of "set it and forget it" are over. You need to stay updated or fall behind.

Conclusion: Three Weeks Later, No Regrets

Migrating to React 19.2 was the right call.

The Good:

Performance improvements are real and measurable
<Activity /> solved problems we've had for years
useEffectEvent cleaned up so much messy code
Partial pre-rendering is production-ready

The Bad:

ESLint migration took 2 full days
Some third-party libraries need updates
Performance Tracks learning curve is steep

The Verdict:

If you're on React 19.1, upgrade. The benefits far outweigh the migration cost.

If you're on React 18, upgrade to 19.2 directly. Don't bother with 19.0 or 19.1 as intermediate steps.

If you're on React 17 or below, you have bigger problems.

Resources

Connect With Me

I'm Elvis Autet (@elvisautet), a senior full-stack developer specializing in React, TypeScript, Node.js, and modern web architecture. I've been shipping React apps to production for 8+ years.

Follow me on X: @elvisautet for more deep dives, production insights, and honest takes on web development.

If you found this helpful, share it with your team. React 19.2 is worth the upgrade.

P.S. Three weeks ago, I was skeptical about upgrading so quickly. Now I'm glad I did. The performance wins alone justify the migration effort. Your users will thank you.

We Need to Talk About How Toxic Dev Culture Has Become (And How We Fix It)

Elvis Sautet — Thu, 23 Oct 2025 08:30:55 +0000

I need to get something off my chest. And honestly, I'm scared to write this. Because the tech community eats its own. But silence is complicity, so here we go.

Part 1: The Moment I Knew We Had a Problem

A few months ago. Slack notification. Code review channel.

A junior developer—let's call her Sarah—submitted her first major pull request. Three hundred lines of authentication logic she'd worked on for two weeks. She was proud. You could feel it in her commit message: "Finally got this working! 🎉"

The senior reviewer's first comment:

"Who taught you to code? This is a mess. Did you even Google 'how to structure a Node.js app' before writing this garbage?"

Sarah went offline. Didn't come back that day.

The next morning, she sent a DM to our manager: "I don't think I'm cut out for this."

I wanted to scream.

Because here's what nobody mentioned in that code review: Her code worked perfectly. It passed all tests. It was secure. It solved the problem.

It just didn't match the senior dev's personal preference for folder structure.

That's when I realized: we've built a culture where being "right" matters more than being kind. Where crushing someone's spirit is acceptable if you can justify it with a Medium article about "best practices."

And I'm fucking tired of it.

Part 2: Let Me Tell You What We've Normalized

Let me paint you a picture of what "normal" looks like in developer communities right now:

Twitter/X: Open any tech thread. Within five replies, someone's calling someone else an idiot. "You don't know JavaScript if you don't understand closures." "Real developers use Vim." "If you need TypeScript, you can't code."

Stack Overflow: A beginner asks a genuine question. Marked as duplicate. Closed. No link to the supposed original. Three comments telling them to "Google it." The person never asks another question.

Discord/Slack: Junior shares something they learned. Senior replies: "That's literally in the docs. Did you even read them?" (Narrator: The docs are 400 pages and poorly organized.)

Code Reviews: WTFs per minute. Condescending comments disguised as "feedback." Blocking PRs over semicolon placement while ignoring architectural issues.

Interviews: Algorithm hazing disguised as "assessment." Rejecting candidates who can build products but can't invert a binary tree on a whiteboard in 15 minutes.

We've normalized being assholes. We've wrapped it in the language of "maintaining standards" and "keeping quality high." But here's the truth:

Cruelty is not rigor. Gatekeeping is not quality control. Making someone feel stupid is not teaching.

And somewhere along the way, we decided that being a good developer means being a dick about it.

Part 3: How Did We Get Here?

I've been in tech for 10 years. I watched the culture shift.

It wasn't always like this.

Ten years ago, tech felt like a community of people excited to build things. We shared code. We helped each other. Stack Overflow answers were kind. "Here's how to do it, and here's why" was the standard response.

Then something changed.

The money arrived. Six-figure salaries. IPOs. Tech became glamorous. Suddenly, being a developer wasn't just a job—it was an identity. A status symbol.

And like any status symbol, people started protecting it.

"Not everyone should be a developer." "The industry is too saturated." "We need to raise the bar."

What they really meant: "I got here first, and I want to keep my advantage."

The bootcamps exploded. Career changers flooded in. Some were genuinely passionate. Some were chasing paychecks. But instead of welcoming new people and filtering for attitude and aptitude, we started hazing them.

"Real developers have CS degrees." "Bootcamp grads aren't real engineers." "You don't understand fundamentals."

The framework wars intensified. React vs Vue. Vim vs VS Code. Spaces vs tabs. Every choice became tribal. Every preference became dogma.

And God help you if you picked the "wrong" one.

The grind culture metastasized. Grinding LeetCode at 2 AM became a flex. "I built this over a weekend" posts everywhere. Side projects as penance. You're not a real developer unless you're coding 80 hours a week.

Burnout became a badge of honor instead of a warning sign.

The influencer era began. Tech Twitter personalities with massive followings. Every take had to be hot. Every opinion had to be strong. Nuance died. You're either a 10x engineer or a fraud.

And if you disagreed? "Clearly you don't understand."

Somewhere in that evolution, we lost our humanity.

Part 4: The Shame Machine

Let me explain how the shame works because it's systematic.

Stage 1: The Question

You ask a question in a public forum. You're stuck. You're frustrated. You need help.

Stage 2: The Immediate Judgment

"Did you even Google this?" "This is basic stuff." "Why are you asking us to do your homework?"

You feel stupid. You feel like you've wasted people's time. You apologize.

Stage 3: The Pile-On

Other people see the thread. They add their two cents. "Yeah, this is pretty fundamental." "You should know this if you're calling yourself a developer."

The shame compounds. You're not just stuck on a technical problem anymore—you're questioning whether you belong in this field at all.

Stage 4: The Internalization

You stop asking questions publicly. You suffer in silence. You spend hours debugging alone rather than risk being shamed again.

Your growth slows. Your confidence erodes. You start thinking: "Maybe I'm not cut out for this."

Stage 5: The Cycle Continues

If you survive, if you grind through and level up, there's a subtle temptation: to do unto others what was done unto you. "I suffered through this hazing. Why shouldn't they?"

And the cycle perpetuates.

Research confirms this: the endemic rot of shame is perpetuated throughout the industry, and it's so commonplace that it's essentially completely normalized.

Across software development, shame and guilt are used as powerful and destructive forces - developers argue and speak condescendingly on social media, Q&As, and other online arenas, holding others to extremely high standards and letting them know when they don't meet them.

This isn't isolated incidents. This is systemic.

Part 5: Let Me Get Really Personal Here

I'm going to tell you something I've never admitted publicly.

Three years ago, I almost quit tech.

Not because I couldn't code. Not because I didn't love building things. But because I was exhausted from constantly feeling like I wasn't good enough.

I was a mid-level developer at the time. I'd shipped features used by thousands of people. I could solve complex problems. I was objectively competent.

But every day felt like walking through a minefield.

Every decision scrutinized. Why did you use a ternary instead of an if-statement? Why didn't you extract that into a function? Why is this variable named like that?

Every question judged. You don't know how useContext works? You've been using React for two years!

Every mistake amplified. Did you just merge to main without rebasing? Jesus Christ, dude.

I developed anxiety around code reviews. My hands would shake hitting "submit." I'd spend hours double-checking obvious stuff because I was terrified of being wrong publicly.

I wasn't coding anymore. I was performing. Every line was theater. Every commit message carefully worded to deflect potential criticism.

The joy was gone.

One night, after a particularly brutal code review where a senior dev called my solution "amateurish," I sat in my car in the parking garage and cried.

I thought: "I have a degree. Years of experience. I've built real products. Why do I feel like a fraud every single day?"

That's when I realized: the problem wasn't me.

The problem was the culture.

And if I felt this way with my privilege—white, male, English as a first language—how much worse was it for women, for people of color, for non-native speakers, for career changers?

Part 6: The Gatekeeping Problem

Let's talk about gatekeeping because it's everywhere and we pretend it's not.

Negative gatekeeping happens when a senior developer blocks your work but doesn't share their knowledge and help you get better at your craft, or leaders push decisions from the top without sharing their vision or hearing your input.

"You're not a real developer if you use..."

VS Code instead of Vim
Create React App instead of Vite
TypeScript instead of "pure JavaScript"
A framework instead of vanilla code
AI tools like Copilot, Cursor
Stack Overflow regularly
GUI Git clients instead of command line

Here's a revolutionary thought: there are no "real developers." There are just people solving problems with code. The tools don't matter. The gatekeeping is arbitrary.

"You should already know..."

Every algorithm from CS101
Every design pattern
Every bit flag operation
Every O(n) optimization
Every Linux command
Every terminal shortcut

Bullshit. I've been coding for a decade and I still Google "how to reverse an array in JavaScript." Knowledge isn't memorization. It's knowing where to find answers and how to apply them.

"If you can't [arbitrary skill], you're not ready for..."

If you can't whiteboard an algorithm, you're not ready to be hired
If you can't answer this brain teaser, you lack problem-solving skills
If you haven't built your own framework, you don't understand frameworks
If you haven't read [specific book], you're not a serious developer

The passive gatekeeping thought of "Isn't it very obvious, I doubt it's worth writing" has the potential to kill any motivation to learn or teach.

These are artificial barriers designed to exclude, not evaluate.

Part 7: The Cost of This Culture

Let me spell out what we're losing:

1. Talented people who could've been great developers quit before they start.

Because the learning curve is steep enough without dealing with assholes every step of the way. How many brilliant problem-solvers walked away because their first Stack Overflow question got mocked?

2. Diversity tanks.

This culture is genuinely believed to be one of the key reasons the industry has trouble attracting women and minority groups to the field - people who are already nervous and perhaps feeling vulnerable putting themselves out there can be put off the industry for good.

When your culture rewards aggressive debate and punishes questions, you're selecting for a specific personality type. And surprise: it's not diverse.

3. Innovation stagnates.

People don't take risks when they're afraid of being wrong. They copy "proven" solutions. They follow trends. They don't experiment.

Fear kills creativity.

4. Mental health collapses.

Anxiety. Depression. Imposter syndrome. Burnout. These aren't individual failings. They're symptoms of a toxic environment.

5. The actual quality of software suffers.

Because when people are scared to ask questions, they write code they don't fully understand. When they're afraid to admit mistakes, bugs get hidden instead of fixed. When code reviews are hostile, people avoid them entirely.

Shame makes people scared to make mistakes and take risks, and they will not innovate.

The irony? In trying to "maintain standards," we're making worse software.

Part 8: "But We Need Standards!"

I can hear the pushback already.

"So we should just accept bad code?" "What about quality?" "Are you saying we can't give feedback?"

No. That's not what I'm saying. Listen carefully:

There's a difference between having standards and being cruel.

High-Quality Feedback:

"Hey, I noticed you're directly manipulating the DOM here. That can lead to state inconsistencies. Want to explore using React state instead? I can pair with you if that helps."

Toxic Feedback:

"Why are you touching the DOM directly? This is React 101. Did you even do the tutorial?"

See the difference?

One teaches. One shames.
One offers help. One offers judgment.
One assumes good intent. One assumes incompetence.

You can have high standards AND be kind.

You can point out issues AND assume the person is doing their best.

You can teach someone a better way AND acknowledge what they did right.

These aren't mutually exclusive. But we've convinced ourselves they are.

"I'm just being honest." No, you're being an asshole. Honesty without compassion is cruelty.

"They need to develop thick skin." Why? Why should surviving emotional abuse be a job requirement?

"This is just how tech is." Then let's change how tech is.

Part 9: My Breaking Point (The Story That Changed Me)

I need to tell you about Marcus.

Marcus was a career changer. Thirty-eight years old. Former teacher. Went to a bootcamp. Got his first junior dev job on my team.

He was hungry. Stayed late. Asked great questions. His first few PRs were rough, but I could see the potential.

One day, he submitted a feature. It worked. Tests passed. But the code was messy—lots of nested ifs, repetitive logic, poor naming.

Our tech lead, a brilliant but abrasive guy, ripped into it:

"This is the worst code I've seen in months. Did you learn to code from YouTube tutorials? This is embarrassing. Reject."

No suggestions. No guidance. Just judgment.

Marcus went quiet in Slack. I DMed him: "Hey, you okay?"

His response: "I think I made a mistake. I'm 38. I don't belong here."

My heart broke.

I called him. We talked for an hour. He told me about his kids. About leaving a stable teaching career. About his wife working extra shifts so he could take the bootcamp. About the months of rejection before he got this job.

"I just want to build things," he said. "I thought if I worked hard enough, learned enough, it would be okay. But I'll never be as good as the people who started at twenty."

That gutted me.

Because Marcus wasn't failing because he lacked talent. He was failing because our culture was toxic, and nobody had his back.

I stayed up that night refactoring his code. Not to fix it for him—but to understand what he was trying to do. And you know what? His approach, while messy, solved the problem in a way none of us had thought of.

The next day, I sat with him. We went through it together. I showed him patterns that could clean it up. I explained why certain structures help. I paired with him to refactor.

His eyes lit up. "Oh! That makes so much sense. Why didn't anyone teach me this?"

That question haunted me: Why didn't anyone teach him?

Marcus is still in tech. Four years later, he's a solid mid-level developer. He mentors juniors now. He's the kindest code reviewer I know.

But how many other Marcuses quit because they didn't have someone in their corner?

Part 10: How We Fix This (No Bullshit Action Items)

Enough complaining. Let's talk solutions. Real ones.

If You're a Senior Developer:

1. Remember when you were junior.

You Googled everything. You asked dumb questions. You wrote terrible code. Someone helped you. Return the favor.

2. Make "I don't know" acceptable.

When juniors ask questions, sometimes say "Good question, let's figure it out together" even when you do know. It models that not knowing is okay.

3. Praise in public, critique in private.

Code reviews are public. If you're going to nitpick someone's code, do it in a DM with context and empathy.

4. Give a shit about the person, not just the code.

Before you comment, ask yourself: "Will this make them a better developer, or will this make them want to quit?"

5. Your experience is not universal.

Not everyone had a CS degree. Not everyone started coding at twelve. Your path is not the only valid path.

If You're a Company Leader:

1. Make kindness non-negotiable.

Brilliant assholes are not worth it. I don't care how good their code is. If they're making people cry, they need to go.

2. Evaluate reviews the way you evaluate code.

Are your senior devs giving constructive feedback? Or are they gatekeeping? Hold them accountable.

3. Create mentorship programs that actually work.

Pair juniors with seniors. Give seniors time to teach. Recognize teaching as valuable work.

4. Normalize asking for help.

Make it a key metric. "How many questions did people feel safe asking this month?"

5. Build psychological safety.

Make it clear: mistakes are learning opportunities, not fireable offenses.

If You're a Junior Developer:

1. You're not the problem.

If you're struggling, if you feel stupid, if you're scared to ask questions—that's not your failing. That's the culture's failing.

2. Find your people.

There are kind communities out there. Discord servers where people actually help. Streamers who encourage questions. Find them.

3. Ask questions anyway.

Even if you get a shitty response, ask. For every jerk, there's someone kind who will help. And the jerks? They'll age out or burn out.

4. Remember who was kind to you.

When you level up, be that person for someone else.

5. Your worth isn't your code.

You are more than your GitHub contributions. More than your LeetCode streak. More than your ability to invert a binary tree.

If You're Anyone in Tech:

1. Call out toxicity when you see it.

"Hey, that comment seems harsh. Can we rephrase?" is powerful. Be an ally.

2. Celebrate learning, not just knowing.

"I learned something new today" should be celebrated more than "I knew this already."

3. Share your struggles.

Talk about the times you failed. The bugs that took you days. The concepts you don't understand. Normalize imperfection.

4. Build instead of tear down.

When you see someone learning, encourage them. When you see someone struggling, help them. When you see someone succeed, celebrate them.

5. Choose kindness.

Every interaction is a choice. You can be right and cruel, or you can be right and kind. Choose kind.

Part 11: What Changed for Me

Here's what I did after my breaking point with Marcus:

I started a mentorship program at my company. Every junior gets paired with a senior. Not for code review—for career support. "How's it going?" check-ins. Safe space to ask "stupid" questions.

I changed how I do code reviews. I start every review with something positive. "I like how you handled error cases here." Then suggestions. Always framed as options, not mandates.

I talk openly about my struggles. I tell my team when I'm stuck. When I Google basic stuff. When I don't understand something. It gives them permission to be human too.

I call out toxic behavior. When someone's harsh in a review, I DM them: "Hey, that came across rough. Want to rephrase?" Sometimes they didn't even realize.

I celebrate questions. In standups, I literally say "Great question" even when it's basic. Because every question someone asks is a question someone else had but was too scared to voice.

I reject the idea that suffering builds character. No. Suffering builds trauma. Support builds character.

My team's changed. People ask questions now. Code reviews are constructive, not combative. Juniors stick around instead of burning out.

The culture shift is real. And it's not because I'm special. It's because I decided to stop being complicit.

Part 12: An Open Letter to Tech

Dear Tech Community,

We're brilliant. We've built incredible things. We've changed the world.

But we're also cruel. And that cruelty is killing us from the inside.

We're losing talented people who could've been great. We're burning out the people who stay. We're building products that lack empathy because we lack empathy for each other.

And for what? To protect our egos? To maintain artificial scarcity? To prove we're smarter?

It's not worth it.

According to Dr. Brené Brown, shame cannot survive when doused with vulnerability and empathy. When we're willing to be vulnerable, open, honest, and caring, we reverse the effects of shame and allow for deeper human connections.

I'm tired of pretending toxic behavior is acceptable. I'm tired of "brilliant jerks" being tolerated. I'm tired of gatekeeping disguised as "maintaining standards."

We can be better than this.

We can have high standards AND be kind.

We can push each other to grow AND be supportive.

We can build world-class products AND treat each other like humans.

The choice is ours. Every code review. Every Slack message. Every Twitter reply. Every interaction.

Choose kindness. Choose empathy. Choose humanity.

Or don't. And watch the best people in our industry burn out and leave.

I know which future I'm choosing.

What about you?

Conclusion: The Developer I Want to Be

I don't want to be the developer who makes people feel small.

I don't want to be the senior who's too important to answer "basic" questions.

I don't want to be the reviewer who's more concerned with being right than being helpful.

I want to be the developer who remembers what it's like to struggle. Who remembers the people who helped me. Who pays that kindness forward.

I want to build a culture where asking for help is strength, not weakness. Where mistakes are learning opportunities, not scarlet letters. Where "I don't know" is the start of growth, not admission of failure.

I want tech to be a place where talented people from any background can thrive. Where your code matters more than your pedigree. Where your potential matters more than your current knowledge.

This isn't idealistic bullshit. It's survival.

Because the current culture is unsustainable. We're burning through people. The turnover, the burnout, the trauma—it's all preventable.

We just have to give a shit about each other.

One Last Thing

If you made it this far, thank you.

If this resonated with you, please share it. Not for me—for the junior developer who thinks they're not good enough. For the career changer questioning their decision. For the senior developer who's tired of pretending toxicity is normal.

We can change this culture. One kind code review at a time. One answered question at a time. One "you belong here" at a time.

Let's build software. And let's build each other up while we do it.

No more shame. No more gatekeeping. No more cruelty disguised as standards.

Just honest, compassionate, human developers building things together.

That's the industry I want. Let's make it happen.

Connect With Me

I'm Elvis Sautet (@elvisautet), and I'm trying to build a kinder corner of tech. If you're tired of the toxicity too, let's connect.

Share your stories. Your struggles. Your tech path. Snippets of code. Hacks. Your moments of kindness. Let's normalize compassion in code.

Because the future of tech isn't about who's the smartest. It's about who we lift up along the way.

P.S. If you're that junior developer reading this at 2 AM, feeling like you don't belong: You do. Keep going. It gets better. And when it does, be the kind person you needed.

I'm a Senior Developer and I Still Google Everything (And That's Perfectly Normal)

Elvis Sautet — Wed, 22 Oct 2025 07:31:04 +0000

Yesterday, during a team standup, a junior developer asked me: "How do you remember all this stuff?" I laughed. "I don't. I Google it. Every single day."

Introduction: The Confession

Let me tell you a secret that nobody talks about in tech interviews or LinkedIn posts:

I'm a Senior Software Developer with 8 years of experience, and I Google basic stuff. Daily. Sometimes hourly.

Last Tuesday, I spent 20 minutes Googling "how to reverse an array in JavaScript" because I couldn't remember if it was .reverse() or .reversed() or .reverseArray().

It's .reverse().

I've used it a thousand times.

I still forgot.

And you know what? 58% of tech workers at companies like Google, Amazon, and Microsoft feel like impostors. That senior developer sitting next to you who seems to know everything? They're Googling basic syntax errors too.

This article is my confession. It's probably yours too. And it's time we stopped pretending.

Part 1: Things I Googled This Week (I'm Not Kidding)

Let me open my browser history and expose myself. This is genuinely what I searched in the last 5 days:

Monday

"css flex align items centre not working" (I forgot to set display: flex with a height of 100dvh)
"typescript interface vs type" (for the 100th time)
"how to exit vim" (I'm a senior dev, I still get trapped in vim)

Tuesday

"react useEffect cleanup function" (I know this. I just... needed to check)
"git revert vs reset vs restore" (which one deletes the commit again?)
"javascript sort array of objects by date" (is it ascending or descending by default?)

Wednesday

"how to center a div" (the classic)
"nodejs read file" (is it fs.readFile or fs.readFileSync? I always forget)

Thursday

"docker compose up vs docker-compose up" (dash or no dash?)
"sql join types visual" (I need that Venn diagram every time)
"regex email validation" (never memorizing this, ever)

Friday

"how to undo git commit not pushed yet" (this is literally my most-searched query)
"javascript array methods cheat sheet" (map, filter, reduce... which does what again?)
"css grid template columns" (repeat(auto-fit, minmax... something something)

Every. Single. Week.

And I'm supposed to be the "expert" on my team.

Part 2: The Lies We Tell in Job Interviews

Here's what I said in my last job interview:

Interviewer: "How proficient are you with React?"

Me: "Very proficient. I've been using React for 5 years."

Here's what I didn't say:

Me (internal monologue): "I use React daily but I still Google 'how does useContext work' every time I need it because I never use Context. I copy-paste the same useEffect patterns from previous projects. And don't even get me started on useReducer."

Interviewer: "What's your experience with TypeScript?"

Me: "Extensive. I've migrated several projects to TypeScript."

Translation: "I know how to add types to function parameters. For anything complex, I Google it or type any and move on. The TypeScript error messages might as well be in ancient Greek."

Interviewer: "How comfortable are you with algorithms?"

Me: "Comfortable. I understand time complexity and can implement common algorithms."

Translation: "I Googled 'binary search tree implementation' last week and copy-pasted it. I couldn't write it from scratch to save my life. Big O notation? I vaguely remember it from CS50."

We're all playing the same game. Pretending we know more than we do.

Part 3: What "Senior Developer" Actually Means

Here's what people think "Senior Developer" means:

❌ Memorized every programming language

❌ Never makes mistakes

❌ Writes perfect code on the first try

❌ Never needs Stack Overflow

❌ Knows all the answers

Here's what "Senior Developer" actually means:

✅ Knows WHAT to Google

✅ Can read documentation (even when it sucks)

✅ Has made every mistake already (so knows what NOT to do)

✅ Can debug efficiently

✅ Knows when to ask for help

The difference between junior and senior isn't knowledge. It's pattern recognition and problem-solving speed.

Real Scenario: Junior vs Senior Dev

Problem: "The button isn't submitting the form."

Junior Developer:

Panics
Googles "button not working"
Reads 10 unrelated Stack Overflow posts
Tries random solutions
Breaks something else
3 hours later: still broken

Senior Developer:

Opens dev console (first instinct)
Sees error: "form.submit is not a function"
Googles exact error message
Finds Stack Overflow answer immediately
Realizes there's a variable named submit conflicting with the native method
Fixes in 5 minutes

Did the senior developer know the answer? Nope.

Did they know how to find it? Yep.

That's the difference.

Part 4: The Stuff I Google Repeatedly (And Never Remember)

Even experienced developers can't remember loads of stuff because you don't use everything on a daily basis. Here are things I've Googled more than 50 times each:

1. Git Commands

# Things I Google constantly:
git revert
git reset
git cherry-pick
git rebase
git stash pop vs git stash apply

I've been using Git for 9 years. I still can't remember the difference between reset --soft, reset --mixed, and reset --hard.

Every time I need to undo something, it's back to Google: "git undo last commit but keep changes"

2. CSS Flexbox vs Grid

/* I have this Googled monthly: */
.container {
  display: flex;
  justify-content: ??? /* center? space-between? I forget */
  align-items: ??? /* center? stretch? help */
}

I've built 100+ responsive layouts. I still need that visual guide every time.

3. Array Methods

// Which one flattens arrays?
.flat()
.flatMap()
.flatten() // this doesn't exist but I Google it anyway

// Which one adds items?
.push() // mutates
.concat() // doesn't mutate
// I mix these up constantly

4. Async/Await vs Promises

// Every few months I forget:
async function getData() {
  const response = await fetch(url)
  const data = await response.json()
  return data
}

// vs

function getData() {
  return fetch(url)
    .then(response => response.json())
    .then(data => data)
}

I know both work. I forget which is better for what. Google knows though.

5. Regular Expressions

// I will NEVER memorize regex
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/ // Googled this 10000 times

// Also this:
const phoneRegex = ??? // No idea, straight to Google

Anyone who says they don't Google regex is lying.

Part 5: The Google Hall of Shame

Let me share the most embarrassing things I've Googled as a "senior" developer:

The Basics I Should Know

"how to declare a variable in javascript"

(I panicked. Is it var, let, or const? In 2025, I still second-guess myself)
"what is the difference between undefined and null"

(I know this. I teach this. I still Google it to confirm)
"how to write a for loop"

(Classic syntax? forEach? map? I blanked during a coding interview)

The "I Should Be Fired" Searches

"how to open terminal on mac"

(I was showing my screen in a meeting. I froze. Couldn't remember the shortcut)
"javascript how to add two numbers"

(In my defense, I was exhausted. Also, I forgot if + works for strings too)
"what is html"

(I was writing documentation and second-guessed the definition. Imposter syndrome hit hard)

The Honest Ones

"senior developer imposter syndrome"

(This led me down a rabbit hole of "am I even qualified for my job?")
"is it normal to Google everything as a programmer"

(Spoiler: Yes. Googling is a skill, and being good at it is what makes you a good programmer)
"how to quit vim"

(:q! or :wq? Or is it :exit? Help.)

Part 6: Why Juniors Think We're Wizards

Junior developers watch me work and think I'm some kind of coding wizard.

What they see:

I type fast
I fix bugs quickly
I write code confidently
I rarely get stuck

What's actually happening:

I type fast because I've copy-pasted this pattern 1000 times
I fix bugs quickly because I've created this exact bug before
I write code confidently because I Googled the solution 5 minutes ago
I rarely get stuck because I know how to Google efficiently

The Illusion of Speed

In scripted tutorial videos, developers work super fast because they've built the application already and know how to overcome issues. But in reality, things take way longer.

What juniors see in tutorials:
"I'll build this authentication system in 10 minutes!"

Reality:

2 hours Googling JWT implementation
1 hour debugging why tokens aren't being sent
30 minutes figuring out CORS
1 hour realizing you forgot to hash passwords
4 hours total

Part 7: The Truth About "Knowing" vs "Finding"

Watching experienced developers making mistakes, running in the wrong direction, or searching on Google can be very helpful for a junior developer.

Here's the dirty secret of software development:

You don't need to know everything. You need to know how to find everything.

What I Actually Memorized (Short List)

Basic syntax (variables, functions, loops)
Core concepts (scope, hoisting, closures)
How to use a debugger
How to read error messages
How to Google effectively

What I Google Every Time (Long List)

Everything else

It's impossible for any developer to know everything. The tech stack is too big. Frameworks update too fast. Languages add new features constantly.

If you're memorizing APIs, you're doing it wrong.

Part 8: The Art of Googling (A Senior Skill)

Let me teach you the actual senior-level skill: how to Google like a pro.

Level 1: Junior Googling

Search: "button not working"

Results: 10 million irrelevant results

Time wasted: 2 hours

Level 2: Mid-Level Googling

Search: "react button onclick not working"

Results: Better, but still generic

Time wasted: 30 minutes

Level 3: Senior Googling

Search: "react button onclick event.target undefined typescript"

Results: Exact Stack Overflow answer

Time saved: 2 minutes

The Senior Developer Google Formula

Include the technology: "react" not just "javascript"
Include the error message: Exact text from console
Include the context: "typescript" if relevant
Add the year: "2025" to filter old answers

Example:

❌ "how to fetch data"
✅ "react 19 fetch data async await typescript 2025"

Advanced Techniques

Use site operators:

site:stackoverflow.com react hooks
site:github.com typescript error

Use quotes for exact matches:

"TypeError: Cannot read property 'map' of undefined"

Exclude results:

react hooks -class components

Being good at Googling saves a lot of development time.

Part 9: The Imposter Syndrome Talk

Let's address the elephant in the room: imposter syndrome.

If you've ever felt like a fraud wondering "am I really a Developer, what do I know, I only know StackOverflow, YouTube and googling," you're not alone.

My Imposter Syndrome Moments

Monday morning standup:

Manager: "Great work on the API integration, Elvis!"

Me (externally): "Thanks, it was straightforward."

Me (internally): "I copy-pasted 80% from Stack Overflow and don't fully understand how JWT works but it passed the tests so… 🤷‍♂️"

Code review:

Junior Dev: "Wow, how did you know to use a WeakMap here?"

Me (externally): "Performance optimization."

Me (internally): "I Googled 'javascript memory leak fix' and clicked the first link."

Technical interview (as interviewer):

Candidate: "I don't remember the exact syntax for reduce..."

Me (externally): "That's fine, understanding the concept matters."

Me (internally): "Bro, I Google reduce EVERY TIME. You're good."

The Reality Check

58% of tech employees at Google, Microsoft, Amazon, Facebook, and Apple face imposter syndrome.

That CTO who speaks confidently? They wake up in cold sweats wondering if they've made a terrible mistake.

That architect everyone admires? They're Googling basic syntax errors.

You're not alone. You're normal.

Part 10: What I Wish I Knew as a Junior Developer

If I could go back and talk to my junior self, here's what I'd say:

1. Googling is a Feature, Not a Bug

Junior me: "I shouldn't need to Google this. Real developers know this stuff."

Senior me: "Real developers know HOW to Google. The ones who pretend they don't are lying."

2. You'll Forget Syntax—And That's Fine

Even experienced devs can't remember loads of stuff because you don't use everything daily, so you forget things.

I've forgotten React Context syntax at least 50 times. Each time I look it up or copy-paste from another file in the project.

3. Copy-Pasting Isn't Cheating

Junior me: "I should write everything from scratch to really learn."

Senior me: "I've copy-pasted entire authentication systems. Just understand what you're pasting."

4. Nobody Knows Everything

It is impossible to stay on top of everything in tech. Technology evolves so quickly—no one can truly grasp all technologies and concepts.

Your job isn't to know everything. Your job is to solve problems.

5. Mistakes Are Part of the Job

Even experienced developers spend hours on simple bugs, run in the wrong direction, and make mistakes.

Last week I spent 3 hours debugging code before realizing I had a typo in a variable name.

userId vs usreId

Three. Hours.

I'm a senior developer.

Part 11: Things That Actually Make You Senior

Since we've established that "knowing everything" isn't the marker of seniority, what is?

You're a Senior Developer When:

You know what you don't know

Juniors fake confidence. Seniors admit ignorance and Google it.
You can read error messages

Juniors panic. Seniors read the stack trace and Google the exact error.
You've debugged the same bug before

Pattern recognition. You've seen this movie.
You know when to ask for help

Juniors struggle for days alone. Seniors ask after 30 minutes of Googling.
You can explain complex things simply

Because you've Googled it so many times, you actually understand it now.
You write code others can maintain

Because you've had to maintain terrible code (yours from 2 years ago).
You embrace not knowing

"I don't know, let me Google it" isn't shameful—it's honest.

Part 12: A Day in the Life (Real Talk)

Let me walk you through yesterday. A typical "senior developer" day:

9:00 AM - Morning Standup

What I said: "I'll finish the payment integration today."

What I meant: "I'll Google how to integrate Stripe for the 5th time because I forget every time."

10:00 AM - Start Coding

Google Search #1: "stripe payment intent react"

Google Search #2: "stripe webhook signature verification"

Google Search #3: "stripe test card numbers"

(I Google this EVERY project)

11:30 AM - Bug Appears

Error: Cannot read property 'amount' of undefined

My process:

Stare at code (2 minutes)
Add console.log everywhere (5 minutes)
Google the error (30 seconds)
Find Stack Overflow answer
Realize I forgot to check if the object exists before accessing it
Face-palm
Add if (payment?.amount) check
Fixed

Total time: 8 minutes

Junior developer time: Would've been 2 hours

Why? Not because I'm smarter. Because I've made this mistake 100 times.

2:00 PM - Code Review

Junior's code:

const data = response.data.users.map(user => user.name)

My review: "What if response.data.users is undefined?"

Junior: "Oh! I didn't think of that."

What I didn't say: "I forgot to check this last week and crashed production. I learned the hard way. Now you don't have to."

4:00 PM - Architecture Meeting

Manager: "How should we structure the microservices?"

What I said: "We should use an event-driven architecture with a message queue."

What happened 5 minutes before: I Googled "microservice communication patterns" and read the first article.

5:00 PM - Helping a Junior

Junior: "How do you remember all these commands?"

Me: "I don't. I have a cheat sheet."

Me (shows bookmarks folder):

Git Commands Cheat Sheet
CSS Flexbox Guide
JavaScript Array Methods
React Hooks Patterns
Common Regex Patterns

Junior: "Wait, you use cheat sheets?"

Me: "Every. Single. Day."

Part 13: The Resources I Actually Use

Let me share my secret weapons (aka bookmarks I visit daily):

My Chrome Bookmarks Bar

📁 Daily Use
  ├─ "git commands"
  ├─ "flex vs grid"
  ├─ "array methods"
  ├─ "async await examples"
  └─ "typescript utility types"

📁 Regex (never memorizing)
  ├─ "email validation"
  ├─ "phone number"
  └─ "url pattern"

📁 Interview Prep (for when I interview)
  ├─ "big O cheat sheet"
  ├─ "system design"
  └─ "behavioral questions"

Part 14: When NOT Googling is Actually Bad

Here's a controversial take: There are times when you SHOULDN'T Google.

Times to Figure It Out Yourself

Learning fundamentals

If you're learning JavaScript and Google "how to write a function" every time, you're not learning. Practice until it sticks.
Debugging your own code

Before Googling, try to understand the error yourself. Read the message. Check the line number. Think.
Understanding core concepts

Don't just Google "what is closure." Experiment. Break things. Understand WHY.

The Balance

Bad: Google every single line of code
Good: Google when stuck after 15 minutes
Best: Google to learn patterns, then implement yourself

Part 15: My Advice to Junior Developers

Based on the reality that forgetting syntax daily and making mistakes is exactly what developers do, here's my advice:

1. Stop Feeling Guilty About Googling

All of us developers rely on Stack Overflow, YouTube, and Google. It's not a weakness—it's the job.

2. Build a Personal Knowledge Base

Keep notes on things you Google repeatedly:

# Git Commands I Always Forget

## Undo last commit (keep changes)
git reset --soft HEAD~1

## Undo last commit (discard changes)
git reset --hard HEAD~1

## View commit history
git log --oneline --graph

3. Learn to Read Documentation

Stack Overflow is great, but the official docs are better for understanding.

4. Embrace Being Uncomfortable

If you're in a room where you're not the smartest person, it means you're learning and expanding yourself.

5. Ask "Dumb" Questions

That "dumb" question? Three other people are wondering the same thing but are too scared to ask.

6. Pair Program with Seniors

Watching experienced developers make mistakes, run in the wrong direction, or search on Google can be very helpful.

You'll realize we're all just figuring it out as we go.

Conclusion: The Liberation of Admitting You Don't Know

Here's what I want you to take away from this:

You are not an imposter for Googling things.

You are not less skilled because you forget syntax.

You are not a bad developer because you don't know everything.

You're human. And with all the information we learn continuously and countless hours spent debugging, how can we expect to memorize everything?

I've been a professional developer for 10 years. I lead a team. I make six figures. I've shipped products used by millions.

And I Google "how to center a div" at least once a month.

The difference between junior and senior isn't knowledge—it's knowing how to find knowledge fast.

So the next time you find yourself frantically Googling something "basic," remember:

Somewhere, a senior developer at Google is Googling the exact same thing.

Welcome to software development. Now stop feeling guilty and keep Googling.

Your Turn: What Do You Google?

I showed you mine, now show me yours. What's the most embarrassing thing you've Googled as a developer?

Comment below or tweet at me @elvisautet with your most-Googled searches. Let's normalize this.

Most Googled Hall of Fame submissions:

"how to exit vim"
"git push force"
"javascript sort descending"
"css vertical align"
"regex email"

What's yours? 👇

Resources (That I Google Daily)

About the Author

I'm Elvis Autet (@elvisautet), a Senior Full-Stack Developer with 8 years of experience and a shameless Google addiction. I've Googled "how to reverse an array" more times than I can count, and I'm not ashamed anymore.

Follow me on X: @elvisautet for more honest developer content and terrible admissions about things I've Googled.

If this article made you feel less alone in your Googling habits, share it with a fellow developer who needs to hear this. We're all in this together.

P.S. I Googled "how to write a good blog conclusion" before writing this. 😂

React Server Components Are Breaking Production Apps (And Nobody's Talking About It)

Elvis Sautet — Tue, 21 Oct 2025 05:07:13 +0000

A few weeks ago, our production app started hanging. Random components wouldn't load. Users were stuck on loading spinners. We spent 40 hours debugging before we realized: React Server Components were the problem.

Introduction: The Promise vs. The Reality

React Server Components (RSC) were supposed to be revolutionary. The React team promised:

✅ Better performance
✅ Smaller bundle sizes
✅ Automatic code splitting
✅ Direct database access from components

We believed them. We migrated our entire Next.js app to the App Router with Server Components.

Three months later, our app is:

Slower on initial load
More complex to debug
Harder for junior developers to understand
Plagued with caching issues we can't explain

This article is the honest conversation the React community needs to have. Not the marketing. Not the hype. The real production experience with React Server Components.

Part 1: What React Server Components Actually Are (The Simple Version)

The Traditional Model (Client Components)

// This runs in the browser
'use client'

export default function UserProfile() {
  const [user, setUser] = useState(null)

  useEffect(() => {
    fetch('/api/user')
      .then(res => res.json())
      .then(setUser)
  }, [])

  if (!user) return <div>Loading...</div>

  return <div>{user.name}</div>
}

Flow:

Browser downloads JavaScript
Component mounts
useEffect fires
Fetch request to API
Wait for response
Update state
Re-render

Result: User sees "Loading..." for 1-2 seconds

The Server Component Model

// This runs on the server
import { db } from '@/lib/database'

export default async function UserProfile() {
  const user = await db.user.findFirst()

  return <div>{user.name}</div>
}

Flow:

Request hits server
Component runs on server
Database query executes
HTML with data sent to browser
User sees content immediately

Result: User sees data instantly (in theory)

The Promise

Server Components would eliminate:

Loading states
Client-side data fetching
API route boilerplate
Large JavaScript bundles

The reality is more complicated.

Part 2: The Problems Nobody Warned Us About

Problem #1: The Waterfall from Hell

Here's what actually happens with Server Components:

// app/dashboard/page.tsx
export default async function Dashboard() {
  const user = await getUser() // 200ms

  return (
    <div>
      <Header user={user} />
      <Stats userId={user.id} /> {/* Another server component */}
      <RecentActivity userId={user.id} /> {/* Another server component */}
    </div>
  )
}

// Stats component
async function Stats({ userId }) {
  const stats = await getStats(userId) // 300ms - WAITS for parent!
  return <div>{stats.total}</div>
}

// RecentActivity component  
async function RecentActivity({ userId }) {
  const activity = await getActivity(userId) // 250ms - WAITS for Stats!
  return <div>{activity.map(...)}</div>
}

What you expect: Parallel requests (200ms + 300ms + 250ms = 750ms max)

What actually happens: Sequential waterfall

getUser() - 200ms
Component renders, finds <Stats>
getStats() - 300ms (starts AFTER step 1)
Component renders, finds <RecentActivity>
getActivity() - 250ms (starts AFTER step 3)

Total time: 750ms (not parallelized!)

Why this happens: React renders components sequentially. Each async component blocks the next one.

The Fix (That Nobody Tells You)

You must manually parallelize:

export default async function Dashboard() {
  // Run all queries in parallel
  const [user, stats, activity] = await Promise.all([
    getUser(),
    getStats(),
    getActivity()
  ])

  return (
    <div>
      <Header user={user} />
      <Stats data={stats} /> {/* Now a regular component */}
      <RecentActivity data={activity} /> {/* Now a regular component */}
    </div>
  )
}

But now you've lost:

Component encapsulation
Separation of concerns
The entire point of Server Components

Problem #2: The Caching Black Box

React 19 and Next.js 14+ have aggressive caching. This sounds good until it breaks in production.

Real bug we hit:

// app/posts/page.tsx
export default async function PostsPage() {
  const posts = await db.post.findMany()
  return <PostList posts={posts} />
}

What happened:

User creates a new post
Redirected to /posts
New post doesn't appear
Refreshing the page doesn't help
Clearing browser cache doesn't help

Why: Next.js cached the database query result on the server. The cache wasn't invalidating.

The "solution":

export const revalidate = 0 // Disable caching

export default async function PostsPage() {
  const posts = await db.post.findMany()
  return <PostList posts={posts} />
}

But now:

You've lost the performance benefit
Every page load hits the database
You're back to the performance of Client Components

The deeper problem: You can't see what's cached. There's no cache inspector. You just have to guess.

Problem #3: Client/Server Boundary Confusion

This is the number one issue for our team:

// ❌ This looks like it should work
'use client'

import { ServerComponent } from './ServerComponent'

export default function ClientComponent() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>
      <ServerComponent /> {/* Error! */}
    </div>
  )
}

Error: "You're importing a Server Component into a Client Component"

Why: Once you use 'use client', everything below it must be a Client Component.

The fix:

// ✅ Pass Server Component as children
'use client'

export default function ClientComponent({ children }) {
  const [count, setCount] = useState(0)

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

// In parent (Server Component)
<ClientComponent>
  <ServerComponent />
</ClientComponent>

This is unintuitive. Junior developers struggle with this for weeks.

Problem #4: Forms Are a Nightmare

Traditional form handling:

'use client'

export default function Form() {
  async function handleSubmit(e) {
    e.preventDefault()
    const res = await fetch('/api/submit', {
      method: 'POST',
      body: JSON.stringify(formData)
    })
    if (res.ok) router.push('/success')
  }

  return <form onSubmit={handleSubmit}>...</form>
}

Simple. Works. Everyone understands it.

Server Actions (the RSC way):

// app/actions.ts
'use server'

export async function submitForm(formData: FormData) {
  const name = formData.get('name')
  await db.user.create({ data: { name } })
  revalidatePath('/users')
  redirect('/success')
}

// Form component
export default function Form() {
  return (
    <form action={submitForm}>
      <input name="name" />
      <button type="submit">Submit</button>
    </form>
  )
}

Problems:

Error handling is unclear: Where do you catch errors?
Loading states: How do you show a spinner?
Validation: Client-side validation requires Client Component
Progressive enhancement: Breaks if JS disabled (yes, people still care)

The "solution" requires useFormStatus:

'use client'

import { useFormStatus } from 'react-dom'
import { submitForm } from './actions'

function SubmitButton() {
  const { pending } = useFormStatus()
  return (
    <button disabled={pending}>
      {pending ? 'Submitting...' : 'Submit'}
    </button>
  )
}

export default function Form() {
  return (
    <form action={submitForm}>
      <input name="name" />
      <SubmitButton />
    </form>
  )
}

Now you need:

A separate file for Server Actions
A Client Component for the button
A new hook to learn
More files and complexity

For what benefit? The old way was simpler.

Problem #5: TypeScript Is a Mess

Server Components break TypeScript in subtle ways:

// lib/db.ts
export async function getUser() {
  return await db.user.findFirst()
}

// app/page.tsx - Server Component
export default async function Page() {
  const user = await getUser()
  return <UserProfile user={user} /> // Type error!
}

// components/UserProfile.tsx - Client Component
'use client'

interface Props {
  user: User // Prisma type with Date objects
}

export default function UserProfile({ user }: Props) {
  return <div>{user.createdAt.toISOString()}</div> // Runtime error!
}

The problem: Server Components serialize props to JSON. Date objects become strings.

TypeScript doesn't catch this. You get a runtime error in production.

The fix: Manual serialization

export async function getUser() {
  const user = await db.user.findFirst()
  return {
    ...user,
    createdAt: user.createdAt.toISOString() // Manual conversion
  }
}

Now you need:

Serialization functions for every database call
Separate types for server vs client
Runtime checks to be safe

Part 3: When Server Components Actually Work Well

I don't want to be entirely negative. Server Components do work well for specific use cases:

✅ Use Case 1: Static Content Sites

// Blog post page
export default async function BlogPost({ params }) {
  const post = await getPost(params.slug)

  return (
    <article>
      <h1>{post.title}</h1>
      <Markdown content={post.content} />
    </article>
  )
}

Why it works:

No interactivity needed
Content rarely changes
Perfect for caching
Great SEO

Verdict: Server Components shine here.

✅ Use Case 2: Dashboard Layouts

export default async function DashboardLayout({ children }) {
  const user = await getCurrentUser()

  return (
    <div>
      <Sidebar user={user} />
      <main>{children}</main>
    </div>
  )
}

Why it works:

User data needed on every page
Minimal interactivity in layout
Can cache user session

Verdict: Good use case.

✅ Use Case 3: Data Tables (Without Filters)

export default async function UsersTable() {
  const users = await db.user.findMany()

  return (
    <table>
      {users.map(user => (
        <tr key={user.id}>
          <td>{user.name}</td>
          <td>{user.email}</td>
        </tr>
      ))}
    </table>
  )
}

Why it works:

Display-only data
No client-side state
Server-side rendering is faster

Verdict: Appropriate use case.

Part 4: When Server Components Fail Hard

❌ Anti-Pattern 1: Real-Time Updates

// ❌ This doesn't work
export default async function LiveFeed() {
  const posts = await getPosts()

  return <PostList posts={posts} />
}

Problem: No way to subscribe to updates. WebSocket data requires Client Component.

You need: Client Component with useEffect and WebSocket connection.

Server Components can't help here.

❌ Anti-Pattern 2: Complex Forms

// ❌ This gets messy fast
export default function MultiStepForm() {
  // How do you manage form state across steps?
  // How do you validate before submission?
  // How do you show field-level errors?
}

Problem: Forms need client-side state. Mixing Server Actions with client state is confusing.

Better approach: Use Client Component with controlled inputs.

❌ Anti-Pattern 3: Highly Interactive UIs

// ❌ Server Components are wrong here
export default async function DataGrid() {
  const data = await getData()

  // Users need to:
  // - Sort columns
  // - Filter rows
  // - Select items
  // - Paginate

  return <Table data={data} />
}

Problem: Every interaction requires a server round-trip.

Solution: Client Component with local state or React Query.

Part 5: The Real Cost of Server Components

Let's talk about what the React team doesn't emphasize:

Cost #1: Developer Experience

Before Server Components:

Junior dev joins team
Learns React hooks
Understands client-side data fetching
Productive in 1-2 weeks

With Server Components:

Junior dev joins team
Learns React hooks
Learns Server Components
Learns Client/Server boundary rules
Learns Server Actions
Learns caching behavior
Learns when to use which pattern
Productive in 1-2 months (if lucky)

Real stat from our team: Onboarding time increased from 2 weeks to 6 weeks.

Cost #2: Debugging Difficulty

Client Component bug:

Open DevTools
See error in console
Add breakpoint
Step through code
Fix bug

Time: 10-30 minutes

Server Component bug:

Error shows in terminal (not browser)
Can't use browser DevTools
Add console.log statements
Restart dev server
Reproduce issue
Check terminal logs
Repeat steps 3-6 multiple times
Eventually find bug

Time: 1-3 hours

Cost #3: Bundle Size (The Lie)

The promise: "Server Components reduce bundle size!"

Reality check:

Before Server Components (pure client):

React bundle: 45KB
App code: 120KB
Total: 165KB

After Server Components:

React bundle: 45KB
React Server Components runtime: 28KB (new!)
App code (client portions): 80KB
Server Action boilerplate: 15KB
Total: 168KB

Savings: 3KB (1.8%)

But wait, there's more:

Increased HTML size (rendered server content)
More network requests (server component trees)
RSC payload overhead

Net result: Our initial bundle got slightly smaller, but total transferred data increased.

Cost #4: Performance (The Surprise)

We measured before/after:

Metric: Time to Interactive (TTI)

Before Server Components:

Home page: 1.2s
Dashboard: 1.8s
Product page: 1.4s

After Server Components:

Home page: 1.9s (58% slower!)
Dashboard: 2.4s (33% slower!)
Product page: 1.1s (21% faster)

Why slower?

Server rendering takes time
Waterfall requests (see Problem #1)
No client-side caching of API responses

Why faster on product page?

Simple, data-heavy page
No interactivity
Perfect use case for RSC

Lesson: Server Components aren't automatically faster.

Part 6: The Communication Problem

Here's what frustrates me most: the React team knew about these issues.

Evidence:

Waterfall problem: Mentioned in React docs, buried deep
Caching issues: "We're working on better devtools" (for 2 years)
TypeScript problems: "This is expected behavior"
Debugging difficulty: "Use console.log" (seriously?)

The community figured out these problems through painful production experience, not from documentation.

Compare this to:

Svelte: Excellent docs, clear limitations
Vue: Honest about tradeoffs
Solid: Upfront about learning curve

React's approach: "Trust us, it's better. We'll explain later."

Part 7: What Should You Actually Do?

Strategy 1: Selective Adoption (Recommended)

Use Server Components for:

Static content
Simple data display
Layout components
SEO-critical pages

Use Client Components for:

Forms with validation
Real-time features
Interactive UIs
Complex state management

Example structure:

app/
  (marketing)/          # Server Components
    page.tsx
    about/page.tsx
  (dashboard)/          # Mixed
    layout.tsx         # Server Component
    page.tsx           # Client Component (interactive)
  (blog)/               # Server Components
    [slug]/page.tsx

Strategy 2: Hybrid Rendering

// Server Component (page)
export default async function ProductPage({ params }) {
  const product = await getProduct(params.id)

  // Render static content on server
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>

      {/* Interactive parts as Client Components */}
      <AddToCartButton productId={product.id} />
      <Reviews productId={product.id} />
    </div>
  )
}

// Client Component (interactive)
'use client'

function AddToCartButton({ productId }) {
  const [loading, setLoading] = useState(false)

  async function handleClick() {
    setLoading(true)
    await addToCart(productId)
    setLoading(false)
  }

  return <button onClick={handleClick}>Add to Cart</button>
}

This works well because:

Server renders static content
Client handles interactivity
Clear separation of concerns

Strategy 3: Wait (Controversial but Valid)

If you're starting a new project:

Consider NOT using Server Components yet if:

You have a small team
You need rapid iteration
Your app is highly interactive
You value developer experience

Stick with:

Pages Router (Next.js 12 style)
Client Components with React Query
Traditional API routes

Why: These patterns are:

Well-documented
Well-understood
Battle-tested
Easier to debug

Server Components will mature. The ecosystem will improve. You can migrate later.

Part 8: The Migration Guide (If You Must)

Step 1: Audit Your App

Categorize every page:

✅ Good for RSC:
- Marketing pages
- Blog posts  
- Documentation
- Static dashboards

⚠️ Maybe:
- User profiles
- Product listings
- Search results

❌ Bad for RSC:
- Real-time chat
- Complex forms
- Canvas/drawing apps
- Admin panels with lots of interactivity

Step 2: Start Small

Don't rewrite everything. Pick ONE page type:

// Start with: Static blog posts
// app/blog/[slug]/page.tsx

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

Learn the patterns on simple pages first.

Step 3: Add Interactivity Gradually

// app/blog/[slug]/page.tsx (Server Component)
export default async function BlogPost({ params }) {
  const post = await getPost(params.slug)

  return (
    <article>
      <h1>{post.title}</h1>
      <Content>{post.content}</Content>

      {/* Client Component for interactions */}
      <LikeButton postId={post.id} />
      <Comments postId={post.id} />
    </article>
  )
}

Keep Server Components focused on data fetching and static content.

Step 4: Watch for Waterfalls

Use React DevTools Profiler:

// ❌ Bad: Sequential
<ServerComponent1 />
<ServerComponent2 /> {/* Waits for 1 */}
<ServerComponent3 /> {/* Waits for 2 */}

// ✅ Good: Parallel
const [data1, data2, data3] = await Promise.all([
  getData1(),
  getData2(),
  getData3()
])

Step 5: Set Up Proper Error Boundaries

// app/error.tsx
'use client' // Error boundaries must be Client Components

export default function Error({ error, reset }) {
  return (
    <div>
      <h2>Something went wrong!</h2>
      <p>{error.message}</p>
      <button onClick={reset}>Try again</button>
    </div>
  )
}

Server Components fail in production. You need error boundaries.

Part 9: The Alternatives Nobody Mentions

Alternative 1: Stick with Client Components + React Query

'use client'

import { useQuery } from '@tanstack/react-query'

export default function ProductPage({ params }) {
  const { data: product, isLoading } = useQuery({
    queryKey: ['product', params.id],
    queryFn: () => fetch(`/api/products/${params.id}`).then(r => r.json())
  })

  if (isLoading) return <Skeleton />

  return <ProductDetails product={product} />
}

Pros:

Well-understood pattern
Excellent DX
Great caching
Easy debugging

Cons:

Client-side loading states
Larger initial bundle
SEO requires extra work

Verdict: Still a great choice for many apps.

Alternative 2: Move to Remix

Remix had "Server Components" before React (via loaders):

// routes/products/$id.tsx
export async function loader({ params }) {
  return json(await getProduct(params.id))
}

export default function Product() {
  const product = useLoaderData()
  return <ProductDetails product={product} />
}

Pros:

Simpler mental model
Better documented
Clear data loading patterns
Excellent error handling

Cons:

Different framework
Migration cost

Verdict: Worth considering for new projects.

Alternative 3: Astro with React Islands

---
// src/pages/product/[id].astro
const product = await getProduct(Astro.params.id)
---

<Layout>
  <h1>{product.name}</h1>
  <p>{product.description}</p>

  <!-- Only this is interactive -->
  <AddToCartButton client:load productId={product.id} />
</Layout>

Pros:

Default to static
Opt-in to interactivity
Great performance
Simple mental model

Cons:

Not pure React
Smaller ecosystem

Verdict: Excellent for content-heavy sites.

Part 10: The Future (What's Coming)

React Team's Roadmap

From recent RFCs and discussions:

Better DevTools - "Coming soon" (been hearing this for 2 years)
Improved caching - More granular control
Streaming improvements - Better Suspense integration
TypeScript support - Better types for Server Components

What We Actually Need

Clear documentation on when NOT to use Server Components
Performance guidelines with real benchmarks
Migration tools to safely adopt RSC
Debugging tools that actually work
Honest communication about limitations

Conclusion: The Uncomfortable Truth

React Server Components are not a silver bullet. They're a tool with specific use cases, significant complexity, and real tradeoffs.

The truth the React team won't say:

They're better for some apps, worse for others
They require significant mental model shift
Documentation is inadequate
Production issues are common
The learning curve is steep

My honest recommendation:

Use Server Components if:

✅ You're building content-heavy sites
✅ You have a senior team that can handle complexity
✅ You're okay being an early adopter
✅ You can invest time in learning

Don't use Server Components if:

❌ Your app is highly interactive
❌ You have junior developers
❌ You need rapid development
❌ Stability is critical

The React community needs to have honest conversations about:

When RSC helps vs hurts
The real DX cost
The actual performance impact
The documentation gaps

Server Components are the future of React. But that future isn't here yet for most applications.

Choose wisely.

Quick Decision Framework

Ask yourself:

1. What % of my app is interactive?

< 30%: Consider Server Components
30-70%: Use hybrid approach
> 70%: Stick with Client Components

2. What's my team's experience level?

All senior: Go ahead
Mixed: Proceed carefully
Mostly junior: Wait

3. What's my timeline?

Learning project: Experiment
Tight deadline: Avoid
Long-term investment: Maybe

4. What's my priority?

Performance: Measure first
DX: Maybe wait
SEO: Good use case
Complexity: Avoid

Resources

The Code Review That Changed Everything

Elvis Sautet — Mon, 20 Oct 2025 19:12:03 +0000

Three months ago, I submitted what I thought was a perfectly reasonable pull request. I had created a new UserRole enum to handle our permission system. Clean, type-safe, idiomatic TypeScript.

The senior engineer's review came back with one comment: "Please don't use enums."

I was confused. Enums are in the TypeScript handbook. They're taught in every course. Major codebases use them. What was wrong with enums?

Then he showed me the compiled JavaScript output.

I deleted every enum from our codebase that afternoon.

This article explains why TypeScript enums are one of the language's most misunderstood features—and why you should probably stop using them.

Part 1: The Enum Illusion

TypeScript sells itself as "JavaScript with syntax for types." The promise is simple: write TypeScript, get type safety, compile to clean JavaScript.

For most TypeScript features, this is true. Interfaces? Erased. Type annotations? Erased. Generics? Erased.

Enums? They become real runtime code.

This fundamental difference makes enums an anomaly in TypeScript—and a trap for developers who don't understand the compilation model.

The Simple Example

Let's start with something innocent:

enum Status {
  Active = "ACTIVE",
  Inactive = "INACTIVE",
  Pending = "PENDING"
}

function getUserStatus(): Status {
  return Status.Active
}

Looks clean, right? Here's what actually ships to your users:

var Status;
(function (Status) {
  Status["Active"] = "ACTIVE";
  Status["Inactive"] = "INACTIVE";
  Status["Pending"] = "PENDING";
})(Status || (Status = {}));

function getUserStatus() {
  return Status.Active;
}

That's 9 lines of JavaScript for 5 lines of TypeScript.

But wait—it gets worse.

Part 2: The Numeric Enum Nightmare

String enums are bad. Numeric enums are a disaster.

enum Role {
  Admin,
  User,
  Guest
}

You might expect this to compile to something simple. Maybe const Role = { Admin: 0, User: 1, Guest: 2 }.

Here's what you actually get:

var Role;
(function (Role) {
  Role[Role["Admin"] = 0] = "Admin";
  Role[Role["User"] = 1] = "User";
  Role[Role["Guest"] = 2] = "Guest";
})(Role || (Role = {}));

What's happening here?

TypeScript is creating reverse mappings. The compiled object looks like this:

{
  Admin: 0,
  User: 1,
  Guest: 2,
  0: "Admin",
  1: "User",
  2: "Guest"
}

This allows you to do: Role[0] // "Admin"

Question: Did you ever need this feature?

In five years of professional TypeScript development, I have never once needed to look up an enum name from its numeric value. Not once.

Yet I've shipped this extra code to production hundreds of times.

Part 3: The Tree-Shaking Problem

Modern bundlers like Webpack, Rollup, and Vite have sophisticated tree-shaking capabilities. They can eliminate unused code with surgical precision.

Unless you're using enums.

The Problem

// types.ts
export enum Status {
  Active = "ACTIVE",
  Inactive = "INACTIVE",
  Pending = "PENDING",
  Archived = "ARCHIVED",
  Deleted = "DELETED"
}

// app.ts
import { Status } from './types'

const currentStatus = Status.Active

What you want: Just the string "ACTIVE" in your bundle.

What you get: The entire Status enum object plus the IIFE wrapper.

Enums cannot be tree-shaken because they're runtime constructs. Even if you only use one value, you get all of them.

Multiply this across dozens of enums in a real application, and you're shipping kilobytes of unnecessary code.

Part 4: The Better Alternative

So if enums are problematic, what should we use instead?

Solution 1: Const Objects with 'as const'

const Status = {
  Active: "ACTIVE",
  Inactive: "INACTIVE",
  Pending: "PENDING"
} as const

Compiled JavaScript:

const Status = {
  Active: "ACTIVE",
  Inactive: "INACTIVE",
  Pending: "PENDING"
}

That's it. No IIFE. No runtime overhead. Just a simple object.

Creating the Type

type Status = typeof Status[keyof typeof Status]
// Expands to: type Status = "ACTIVE" | "INACTIVE" | "PENDING"

Now you have:

✅ A runtime object for values
✅ A compile-time type for type checking
✅ Zero compilation overhead
✅ Tree-shakeable (if your bundler supports it)

Usage

// Works exactly like enums:
function setStatus(status: Status) {
  console.log(status)
}

setStatus(Status.Active) // ✅ Valid
setStatus("ACTIVE")      // ✅ Valid (it's just a string)
setStatus("INVALID")     // ❌ Type error

Part 5: The Type Safety Advantage

Here's where it gets interesting: const objects provide BETTER type safety than enums.

The Enum Problem

enum Color {
  Red = 0,
  Blue = 1
}

enum Status {
  Inactive = 0,
  Active = 1
}

function setColor(color: Color) {
  console.log(`Color: ${color}`)
}

// This compiles successfully:
setColor(Status.Active) // No error!

Why? Because TypeScript enums use structural typing. Both Color and Status are numbers, so TypeScript considers them compatible.

This compiled and shipped to production. It caused a bug that took hours to debug.

The Object Solution

const Color = {
  Red: "RED",
  Blue: "BLUE"
} as const

const Status = {
  Inactive: "INACTIVE",
  Active: "ACTIVE"
} as const

type Color = typeof Color[keyof typeof Color]

function setColor(color: Color) {
  console.log(`Color: ${color}`)
}

// Type error:
setColor(Status.Active) // ❌ Type '"ACTIVE"' is not assignable to type '"RED" | "BLUE"'

The const object approach uses literal types, which are exact string values. TypeScript catches the error at compile time.

Const objects provide stricter type checking than enums.

Part 6: The Migration Path

Convinced? Here's how to migrate existing enums.

Step 1: Identify String Enums

These are the easiest to migrate:

// Before
enum Status {
  Active = "ACTIVE",
  Inactive = "INACTIVE"
}

// After
const Status = {
  Active: "ACTIVE",
  Inactive: "INACTIVE"
} as const

type Status = typeof Status[keyof typeof Status]

Step 2: Convert Numeric Enums

For numeric enums, you need to preserve the numbers:

// Before
enum HttpStatus {
  OK = 200,
  NotFound = 404,
  ServerError = 500
}

// After
const HttpStatus = {
  OK: 200,
  NotFound: 404,
  ServerError: 500
} as const

type HttpStatus = typeof HttpStatus[keyof typeof HttpStatus]

Step 3: Update Usage

The good news? Usage stays mostly the same:

// Both work identically:
const status1: Status = Status.Active
const status2: HttpStatus = HttpStatus.OK

// Pattern matching still works:
switch (status) {
  case Status.Active:
    // ...
  case Status.Inactive:
    // ...
}

Step 4: Handle Edge Cases

If you're using reverse lookups (rare), you'll need to create an explicit reverse map:

const HttpStatus = {
  OK: 200,
  NotFound: 404
} as const

// Create reverse mapping only if needed:
const HttpStatusNames = {
  200: "OK",
  404: "NotFound"
} as const

HttpStatusNames[200] // "OK"

Part 7: The One Exception

Is there ever a valid reason to use enums?

Maybe: const enums

const enum Direction {
  Up,
  Down,
  Left,
  Right
}

const move = Direction.Up

Compiles to:

const move = 0 /* Direction.Up */

Const enums are inlined at compile time. They don't create runtime objects.

However:

They don't work with isolatedModules (required for Babel, esbuild, SWC)
They're being deprecated in favor of preserveConstEnums
They're more complex than just using objects

My recommendation: Even for const enums, just use objects. Simpler is better.

Part 8: Real-World Impact

When we migrated our codebase from enums to const objects, here's what happened:

Before Migration

Enums in codebase: 47
Bundle size: 2.4 MB (minified)
Enum-related code in bundle: ~14 KB

After Migration

Enums in codebase: 0
Bundle size: 2.388 MB (minified)
Savings: 12 KB

"Only 12KB?"

Yes, but:

It's 12KB we don't need to ship, parse, or execute
Type safety improved (we caught 3 bugs during migration)
Code became more readable (it's just JavaScript)
New developers onboard faster (fewer TypeScript quirks)

Developer Experience Improvements

Faster compilation: TypeScript doesn't need to generate enum code
Better IDE performance: Fewer runtime constructs to track
Easier debugging: Console logs show actual values, not enum references
Simpler mental model: One less TypeScript-specific feature to remember

Part 9: Common Objections

"But enums are in the TypeScript docs!"

So are namespaces, and those are also considered legacy. The TypeScript team has acknowledged that enums were a mistake, but they can't remove them without breaking changes.

"My entire codebase uses enums!"

Migration is straightforward and can be done incrementally. Start with new code, migrate old code during refactors.

"Enums are more explicit!"

// Enum
enum Status { Active = "ACTIVE" }

// Object
const Status = { Active: "ACTIVE" } as const

The difference is minimal. The object version is actually more JavaScript-idiomatic.

"I need the type and the value!"

You get both with the const object pattern:

const Status = { Active: "ACTIVE" } as const  // Runtime value
type Status = typeof Status[keyof typeof Status]  // Compile-time type

"What about JSON serialization?"

Enums serialize to their underlying values anyway:

enum Status { Active = "ACTIVE" }
JSON.stringify({ status: Status.Active }) // {"status":"ACTIVE"}

Same as:

const Status = { Active: "ACTIVE" } as const
JSON.stringify({ status: Status.Active }) // {"status":"ACTIVE"}

No difference.

Part 10: The Philosophical Point

TypeScript's motto is "JavaScript that scales." The best TypeScript code is code that looks like JavaScript but with type annotations.

Enums violate this principle. They're a TypeScript-only construct that generates runtime code and behaves differently from anything in JavaScript.

When in doubt, prefer JavaScript idioms with TypeScript types over TypeScript-specific features.

Good TypeScript:

const Status = { Active: "ACTIVE" } as const
type Status = typeof Status[keyof typeof Status]

This is JavaScript (an object) with TypeScript types. It scales. It's familiar. It works everywhere.

Questionable TypeScript:

enum Status { Active = "ACTIVE" }

This is TypeScript-specific syntax that generates unexpected runtime code.

Conclusion: Make the Switch

TypeScript enums seemed like a good idea in 2012. In 2025, we have better options.

The case against enums:

❌ Generate unexpected runtime code
❌ Don't tree-shake
❌ Create reverse mappings nobody uses
❌ Weaker type safety than literal types
❌ TypeScript-specific syntax

The case for const objects:

✅ Zero runtime overhead
✅ Tree-shakeable
✅ Just JavaScript
✅ Stronger type safety
✅ Works everywhere

Next time you reach for an enum, reach for a const object instead.

Your bundle will be smaller. Your types will be stricter. Your code will be clearer.

Stop using enums. Start using objects.

Quick Reference Guide

String Enum Migration

// ❌ Old way
enum Status {
  Active = "ACTIVE",
  Inactive = "INACTIVE"
}

// ✅ New way
const Status = {
  Active: "ACTIVE",
  Inactive: "INACTIVE"
} as const

type Status = typeof Status[keyof typeof Status]

Numeric Enum Migration

// ❌ Old way
enum Priority {
  Low = 1,
  Medium = 2,
  High = 3
}

// ✅ New way
const Priority = {
  Low: 1,
  Medium: 2,
  High: 3
} as const

type Priority = typeof Priority[keyof typeof Priority]

Helper Type for Reusability

// Create a reusable type helper
type ValueOf<T> = T[keyof T]

const Status = {
  Active: "ACTIVE",
  Inactive: "INACTIVE"
} as const

type Status = ValueOf<typeof Status>

About Me

I'm a senior TypeScript developer with 5+ years of experience building production applications. I learned this lesson the hard way—by shipping unnecessary enum code to millions of users. Now I share what I've learned so you don't have to make the same mistakes.

If you found this helpful, consider sharing it with your team. The more developers who understand this, the better code we'll all ship.

Forem: Elvis Sautet

Next.js Finally Has Competition

The five-year answer is dead

The most mass-adopted solo developer in React history

The code tells the real story

The SEO myth that won't die

The numbers nobody argues with

The security incident you need to know about

The money

Where Next.js wins and it's not close

Where TanStack Start wins and it's not close

Five questions that decide your framework

What happens next

Cron Jobs vs Real Task Schedulers: A Love Story

Table of Contents

The Problem with Traditional Cron

Why Big Tech Uses a Two-Tier Architecture

The Architecture We're Building

Understanding the Queue Layer

Why BullMQ + Redis?

Alternative 1: RabbitMQ

Alternative 2: AWS SQS + DynamoDB

Alternative 3: Kafka

My Recommendation

The Intelligent Router: The Brain of the System

Path 1: Immediate (< 15 minutes)

Path 2: Hot (< 24 hours)

Path 3: Cold (> 24 hours)

Implementing the Three Task Types

Type 1: One-Time Tasks

Type 2: Recurring Tasks

Type 3: Repeating Tasks

The Database Schema That Scales

Building the Scheduler

Worker Implementation

Putting It All Together

Production Considerations

1. Database Connection Pooling

2. Redis Persistence

3. Worker Scaling

4. Dead Letter Queue Monitoring

5. Database Archiving

6. Monitoring Metrics

7. Graceful Shutdown

What I Learned the Hard Way

Mistake 1: Not Using Idempotency Keys

Mistake 2: Infinite Retry Loops

Mistake 3: Not Handling Clock Skew

Mistake 4: Forgetting to Update nextRunAt

Mistake 5: No Monitoring

Wrapping Up

"2026", AI Users vs The Unemployed.

The Numbers That Should Scare You

What This Actually Means (Beyond the Hype)

The Job Market Reality (It's Worse Than You Think)

My Personal Crisis (And Probably Yours Too)

The Controversial Part (Let Me Say What Others Won't)

What Nobody Is Talking About (But Should Be)

The Things That Still Matter (Maybe)

The Fork in the Road (Where We're Actually At)

What Happens Next (My Best Guess)

The Question We Should All Be Asking

My Honest Take (No BS)

Tailwind CSS Won the War... But We're the Losers

The Takeover Nobody Saw Coming

Why Everyone Uses It (Including Me)

The Problem Nobody Talks About

What Happens If Tailwind Disappears?

The Real Controversy (That Nobody Wants to Say)

What I'm Doing About It (And What You Should Too)

The Uncomfortable Truth

Where CSS Is Actually Heading

The Question We Should Be Asking

My Honest Take (After 3 Years of Tailwind)

What You Can Do

The Bottom Line

Stop Doing Business Logic in Webhook Endpoints. I Don't Care What Your Lead Engineer Says.

The Setup: What We Were Building

Their Argument (Why They Thought I Was Wrong)

My Argument (Why I Was Right)

Part 2: `<Activity />` - The Component That Changes Everything

Part 3: `useEffectEvent` - Finally, Effect Dependencies Make Sense

The New Way with `useEffectEvent`: