Adobe is not the villain here because the market shifted and Animate could not keep up.

The Bridge That Never Connected

Animate CC let Flash animators keep their keyframe-and-timeline mental model while targeting JavaScript. However, it never shook off its Flash DNA.

When I worked with Animate components in 2017, you could build interactive pieces and games. But Animate exported to CreateJS — a Canvas runtime abstraction that felt like a foreign layer next to modern web stacks. CreateJS was slower than hand-coded Canvas. The whole pipeline felt out of step with JavaScript development. Unity, Godot, even Phaser owned their pipelines end-to-end. Animate's HTML5 output never felt native to the web.

The user base hollowed out. The "semi-technical designer" — people who could both animate and script — split into two camps. Motion designers storyboard concepts. Engineers implement them in Canvas or WebGL. Animate ended up in no-man's land: not opinionated enough as a game engine, not modern enough as a web tool.

The Workflow That Won

After Effects → Lottie gave designers a cleaner loop. Animate in a familiar tool, export JSON, hand it to engineers who render it natively on web or mobile. No custom JavaScript runtime. No FLA files.

Spine and Spriter did the same for game animation: export to runtime libraries that integrate cleanly with any engine. Animate's HTML5 Canvas output worked, but felt bolted onto a tool designed for a plugin that no longer exists.

The market wanted separation of concerns, where designers own animation and engineers own runtime. Animate tried to be both.

If you still use Animate, maintenance mode means security patches without ecosystem modernization. The risk shifts from "Adobe kills it next March" to "OS and ecosystem changes eventually outpace a frozen app." It is not advisable to build new work on museum-mode software.

The timeline and keyframe paradigm that made Flash powerful lives on in After Effects, game engines, and web animation libraries. It just does not need Animate anymore.

TL;DR: Total cost $236. Two stops at City Hall, then email a newspaper. Done in one day (plus 4 weeks of publication).

What to Bring

• Cash (Tax Collector only accepts cash in person)
• Valid photo ID
• Pre-filled FBN Statement form

Step 1: Tax Collector (Room 140)

Go here first. You can't file your FBN without registering your business. City Hall is in the Civic Center area—if you're coming from the Mission District, take BART to Civic Center station.

Obligation type: "Business Registration," payable to the Treasurer and Tax Collector.

Not sure why the amounts differ - maybe prorating.

Official fees for sole proprietors:

After paying, you immediately get:

• Business Account Number (BAN) - you'll need this for your FBN
• Temporary Verification of Registration (TVR) - required for your FBN filing, serves as proof until official certificate arrives

Step 2: County Clerk (Room 168)

Walk over to Room 168. This is where you file your Fictitious Business Name (FBN).

Pre-fill the FBN Statement form before going. The SF.gov instructions weren't clear to me, but the clerks were helpful.

After filing, you get a stamped copy of your FBN. This is your DBA.

Step 3: Publish in a Newspaper

California requires you to publish your FBN once a week for four consecutive weeks.

Newspaper Options

San Francisco has 4 court-approved newspapers. I emailed all four for quotes:

Small Business Exchange is $15 cheaper, but you file the proof yourself — either mail it (1-2 week wait) or another trip to City Hall. If your time is worth more than $15/hour, pay for convenience.

I went with Bay Area Reporter. They replied within hours. Accepts check, credit card, or PayPal. Deadline: 10am Tuesday for Thursday publication.

Step 4: Proof of Publication

After your fourth publication, you have 45 days to file the Proof of Publication. Fee is $10.

If your newspaper files for you (Bay Area Reporter, DBAStore, SF Examiner):

You're done. They file it and email you a copy.

If you file yourself (Small Business Exchange):

Total Costs

Timeline

Day 1        → City Hall (Tax Collector + County Clerk)
Days 2-45    → Email newspaper, submit FBN for publication
Weeks 2-5    → Publication runs (4 consecutive weeks)
Week 6+      → Proof of publication filed (within 45 days of 4th publication)

Your FBN expires in 5 years.

The Sequence

1. Tax Collector first → get your BAN
2. County Clerk second → file your FBN
3. Newspaper third → publish for 4 weeks
4. Proof of publication last → or let the newspaper handle it

Sources:

• SF.gov: File a Fictitious Business Name
• SF Treasurer: Register a Business
• SF County Clerk
• Court-Approved Newspapers

The one that matters: a frontend-design skill that auto-activates during UI work and changes how Claude writes your frontend code.

How it works

Run /plugin to browse, install, and manage plugins from marketplaces you've added.

Anthropic maintains two official marketplaces:

• anthropics/claude-code — bundled plugins for Agent SDK development, PR reviews, commit workflows
• claude-plugins-official — curated directory including the frontend-design skill

The frontend-design skill

From the plugin README:

Create distinctive, production-grade frontend interfaces with high design quality. Generates creative, polished code that avoids generic AI aesthetics.

What makes it different:

• Auto-invokes contextually — Claude detects frontend work and the skill kicks in. No slash command needed.
• Opinionated design choices — bolder typography, asymmetric layouts, motion, real spacing instead of safe defaults.
• ~400 tokens — a markdown document that rewires Claude's aesthetic sense. Not heavy infrastructure.

Before vs after

Without the skill, Claude tends to generate:

• Safe, centered layouts
• Default Tailwind spacing
• Generic card components
• "Clean" but forgettable UI

With frontend-design active:

• Editorial typography choices
• Intentional whitespace and asymmetry
• Motion and micro-interactions
• Distinctive visual personality

Installing it

# Add the official marketplace (if not already added)
/plugin marketplace add claude-plugins-official

# Install the frontend-design skill
/plugin install frontend-design@claude-plugins-official

Or just run /plugin, go to Discover, and find frontend-design.

The "Install for you (user scope)" option means it's installed to your profile only—other users on the same machine need to install it separately.

Why this matters

Plugins let Claude Code specialize for your workflow. No re-explaining context every session.

Other plugins worth installing

The claude-plugins-official marketplace has 46+ plugins. The ones I'd install first:

Development workflows

Language servers (LSP)

These give Claude better code intelligence for specific languages:

Security and quality

Integrations (MCP servers)

Learning and output styles

Plugin development

Security

Claude Code warns you at install time. The safe practice:

• Stick to official marketplaces (claude-plugins-official, anthropics/claude-code)
• Skim the plugin's README before installing third-party plugins
• Use user-scope installs rather than machine-wide when testing

Getting started

# 1. Add Anthropic's official marketplace
/plugin marketplace add claude-plugins-official

# 2. Install the frontend skill
/plugin install frontend-design@claude-plugins-official

# 3. Start building UI normally
# The skill auto-activates when Claude detects frontend work

Give it vibes and constraints, not "make it pretty":

"Build a landing page for an AI security startup in Next.js + Tailwind. Go for a bold editorial aesthetic with lots of whitespace."

I haven't tried this yet

I discovered this feature and haven't used it on a real project. I'll update this post after testing it. Questions I want answered:

• Does it handle design systems and component libraries well?
• Do the "distinctive" choices ship, or do they need heavy editing?
• How does it interact with existing Tailwind/CSS conventions in a codebase?

Related posts:

• Claude Code Strengths and Weaknesses - My earlier assessment of Claude Code's capabilities

The core difference

// ✅ Normal import: executes the module
import $ from 'jquery/dist/jquery.slim.js';
console.log(typeof $);  // "function" - it's the jQuery API

// ❌ URL import: asset URL only
import jquerySlimUrl from 'jquery/dist/jquery.slim.js?url';
console.log(typeof jquerySlimUrl);  // "string" - just a path
console.log(jquerySlimUrl);  // "/assets/jquery.slim-a1b2c3d4.js"

Without ?url:

• Vite runs the file through the JS pipeline
• Dependencies are resolved and bundled
• You get the module's exports

With ?url:

• Vite copies the file to your build output as-is
• No bundling, no dependency resolution
• You get a string path to that file

Why ?url "breaks" your code

If your code looks like this:

// 🚫 WRONG: This gives you a string, not jQuery
import $ from 'jquery/dist/jquery.slim.js?url';

$('#app').hide();
// TypeError: $ is not a function
// Because $ === "/assets/jquery.slim-a1b2c3d4.js"

The fix is simple—remove ?url:

// ✅ CORRECT: This gives you the jQuery function
import $ from 'jquery/dist/jquery.slim.js';

$('#app').hide();  // Works

If you see TypeError: x is not a function after an import, check if you accidentally added ?url to the import path.

What ?url is actually for

?url exists for cases where you need a file's URL, not its code.

1. CSS Paint Worklets

import workletUrl from './checkered-pattern.js?url';

// Worklet API requires a URL, not code
CSS.paintWorklet.addModule(workletUrl);

2. Audio Worklets

import processorUrl from './audio-processor.js?url';

await audioContext.audioWorklet.addModule(processorUrl);
const node = new AudioWorkletNode(audioContext, 'my-processor');

3. Injecting scripts into iframes

import jqueryUrl from 'jquery/dist/jquery.slim.js?url';

const script = document.createElement('script');
script.src = jqueryUrl;  // Need URL here, not code
iframe.contentDocument.head.appendChild(script);

4. Web Workers (alternative syntax)

// Option A: Vite's ?worker suffix (recommended)
import MyWorker from './worker.js?worker';
const worker = new MyWorker();

// Option B: Manual with ?url
import workerUrl from './worker.js?url';
const worker = new Worker(workerUrl, { type: 'module' });

All Vite import suffixes

Vite recognizes these query suffixes:

// ?raw - get file contents as string
import vertexShader from './shader.vert?raw';
gl.shaderSource(shader, vertexShader);

// ?worker - get a Worker constructor
import AnalyticsWorker from './analytics.js?worker';
const worker = new AnalyticsWorker();

// ?inline - get base64 data URI
import iconDataUri from './icon.svg?inline';
img.src = iconDataUri;  // "data:image/svg+xml;base64,..."

These suffixes are Vite-specific. They won't work in Node.js, Webpack, or browsers directly.

The dependency gotcha

?url treats the file as a standalone asset. Vite does not process import statements inside it.

// worker.js
import { helper } from './utils.js';  // This import exists

// main.js
import workerUrl from './worker.js?url';
// ⚠️ worker.js is copied as-is
// ⚠️ The import for utils.js is NOT resolved
// ⚠️ Worker will fail at runtime with "Failed to resolve module"

Quick reference

Do you need...

• The module's API (functions, classes, values) → Normal import
• A URL to pass to browser APIs → ?url
• File contents as a string → ?raw
• A Web Worker with bundled dependencies → ?worker

// I need jQuery's $ function
import $ from 'jquery';                           // ✅

// I need to inject jQuery into an iframe
import jqUrl from 'jquery?url';                   // ✅

// I need GLSL shader source code
import frag from './shader.frag?raw';             // ✅

// I need a worker that imports other modules
import MyWorker from './worker.js?worker';        // ✅

?url flips Vite into asset mode. One import gives you the module, the other gives you the address.

Related posts:

• Switching from Webpack to Vite in 2025 - Why Vite's architecture makes it faster

The project has been around since 2006. Twenty years. Most JavaScript libraries don't survive five. jQuery made it to version 4 after a decade of "you don't need jQuery" blog posts.

What Changed

jQuery 4 drops IE support entirely. No IE10, no IE11. This unlocks everything else.

Without legacy browser baggage, the team cut code that existed purely for compatibility:

• Browser detection hacks for IE quirks
• Event handling workarounds for old DOM APIs
• Animation fallbacks for browsers without CSS transitions
• jQuery.isArray() and jQuery.isFunction() (use native Array.isArray() and typeof instead)

The slim build also got slimmer. It now removes Deferreds, Callbacks, and the queue module on top of AJAX and effects.

jQuery Admits the Browser Won

What slim removes and what replaces it:

The size difference:

jQuery 4.0.0 (gzipped)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Full  ████████████████████████████████████████ 27.6 KB
Slim  ████████████████████████████░░░░░░░░░░░░ 19.5 KB
                                    ↑
                                8.1 KB saved (29%)

8KB doesn't sound like much in 2026. But those 8KB duplicate what browsers do natively. If you already use fetch() and CSS transitions, you're shipping dead code.

Slim or Full?

Use slim if you already use fetch() and Promises, jQuery only handles DOM and events, or bundle size matters (widgets, WordPress plugins, marketing pages).

Stick with full if you have a lot of $.ajax() code you're not ready to refactor, or you need the animation queue for sequenced effects.

The Migration Path

jQuery 4 doesn't force a rewrite. Migrate gradually:

1. Stop adding new $.ajax() calls. New code uses fetch().
2. Stop adding new jQuery animations. New code uses CSS transitions.
3. Replace $.Deferred() with native Promise when you touch old code.
4. Eventually swap jquery.min.js for jquery.slim.min.js.

// Old: jQuery AJAX
$.ajax({
  url: '/api/users',
  method: 'GET',
  dataType: 'json'
}).then(data => console.log(data));

// New: Native fetch
const data = await fetch('/api/users').then(r => r.json());

/* Old: jQuery fadeOut */
/* $('#box').fadeOut(300); */

/* New: CSS transition */
.box {
  opacity: 1;
  transition: opacity 0.3s ease;
}
.box.hidden {
  opacity: 0;
}

The slim build doesn't resolve dependencies inside ?url imports. If you're loading jQuery via a script URL in an iframe or worker, test thoroughly.

Twenty Years Later

We've gone through Angular, React, Vue, Svelte, and countless build tools. jQuery just kept working.

The slim build is jQuery saying "use the platform" for what the platform does well. Keep jQuery for DOM manipulation. Use fetch() for network requests. Use CSS for animations. That's more honest than most libraries manage.

Related posts:

• Why jquery.slim.js?url Behaves Differently in Vite - Import suffixes and what they mean
• Switching from Webpack to Vite in 2025 - Modern build tooling

I was asking Claude Code to solve the same problem I solve manually every time I work on the project.

Claude Code is the web interface at claude.ai/code. It loads a CLAUDE.md file from your project root at the start of every session.

That is where Claude Code becomes a force multiplier.

Without Quirks Documented

Claude encounters pnpm typecheck failing from a package directory. Claude asks: "Are you in a monorepo? Are you using pnpm? Where should I run this?" You explain the architecture. Claude fixes it. Next task: same questions, same exploration, same delay.

With CLAUDE.md

Claude encounters the same error. Claude reads CLAUDE.md: "pnpm workspace puts binaries at root in node_modules/.bin/. Always run from project root." Claude fixes it immediately, and the next task requires no questions.

The difference is not that Claude is smarter. You stopped re-teaching Claude the same lesson every session.

What Goes in CLAUDE.md

A real pnpm monorepo CLAUDE.md:

## pnpm Monorepo: Critical Commands

pnpm install (from root - sets up workspace)
cd packages/web && pnpm install (breaks symlinks)

pnpm typecheck (from root)
cd packages/web && pnpm typecheck (binaries at root, not in package)

pnpm -C packages/web build (run specific package)
cd packages/web && pnpm build (different behavior, can fail)

pnpm --filter @workspace/utils test (run package by name)
pnpm --filter utils test (partial matches fail)

Why each matters:
- pnpm workspace symlinks binaries to root node_modules/.bin/
- Running from package directory breaks PATH lookup
- -C flag changes working directory safely
- --filter requires exact package name from package.json

When you open Claude Code and encounter a pnpm error, it reads this CLAUDE.md and knows what went wrong. No hypothesis needed and no questions asked.

The Multiplier

You already know these quirks. You solve them manually every time. The difference between wasting 45 minutes and shipping in 5 minutes is not Claude Code's intelligence. You taught it to remember what you know.

What was a chatbot that asks the same questions every session becomes a development partner with perfect project memory.

What you see in the browser:

<button className="text-(--btn-icon) bg-(--btn-bg)" />

The classes do not exist, and the raw function syntax just sits there unstyled.

Why It Breaks

Tailwind v4 moved configuration from JS to CSS. The old tailwind.config.js with content: paths is ignored.

Fix: Add @source

In your app's CSS file (packages/main-app/src/app.css):

@import 'tailwindcss';
@source '../shared-components/src/**/*.{js,ts,jsx,tsx}';

@theme {
  --btn-icon: #222;
  --btn-bg: #cfcfcf;
  --radius-lg: 0.5rem;
}

The @source directive tells Tailwind where to find classes in other packages.

Multiple packages? Add multiple directives:

@import 'tailwindcss';
@source '../shared-components/src/**/*.{js,ts,jsx,tsx}';
@source '../shared-utils/src/**/*.{js,ts,jsx,tsx}';
@source '../shared-hooks/src/**/*.{js,ts,jsx,tsx}';

@theme {
  --btn-icon: #222;
  --btn-bg: #cfcfcf;
}

Your component now works:

export function Button({ children }) {
  return (
    <button className="text-(--btn-icon) bg-(--btn-bg) rounded-(--radius-lg)">
      {children}
    </button>
  );
}

What Changed

The path in @source is relative to your CSS file. All theme variables go in @theme.

References

Tailwind v4 Functions and Directives
Tailwind v4 Installation

I spent the last six months building applications with both approaches. Here's what I learned about when each makes sense.

Setting Up React Query in React Router v7

Before we compare approaches, let's cover how to properly add React Query to a React Router v7 framework mode project. If you're starting with loaders only, skip this section and come back when you need it.

Installation

bun add @tanstack/react-query
bun add -D @tanstack/react-query-devtools

Root Component Configuration

Create a query client and wrap your app with the provider in your root route:

// app/query-client.ts
import { QueryClient } from '@tanstack/react-query';

export const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      // Consider data fresh for 5 minutes
      staleTime: 1000 * 60 * 5,
      // Refetch when user returns to tab
      refetchOnWindowFocus: true,
      // Retry failed requests twice
      retry: 2,
      // Wait 2 seconds between retries
      retryDelay: 2000,
    },
  },
});

// app/root.tsx
import { QueryClientProvider } from '@tanstack/react-query';
import { ReactQueryDevtools } from '@tanstack/react-query-devtools';
import { Links, Meta, Outlet, Scripts, ScrollRestoration } from 'react-router';
import { queryClient } from './query-client';

export default function Root() {
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <Meta />
        <Links />
      </head>
      <body>
        <QueryClientProvider client={queryClient}>
          <Outlet />
          <ReactQueryDevtools initialIsOpen={false} />
        </QueryClientProvider>
        <ScrollRestoration />
        <Scripts />
      </body>
    </html>
  );
}

SSR Considerations

import { useState } from 'react';

export default function Root() {
  const [queryClient] = useState(
    () => new QueryClient({
      defaultOptions: {
        queries: {
          staleTime: 1000 * 60 * 5,
        },
      },
    })
  );

  return (
    <QueryClientProvider client={queryClient}>
      <Outlet />
    </QueryClientProvider>
  );
}

This creates a new query client instance per request, preventing data leaks between users.

Now let's look at what each approach does well, and when you'd use one over the other.

What React Router v7 Loaders Do Well

React Router v7 loaders run on the server (or edge) before rendering. They're part of the framework, so there's no extra dependency. Every route can define a loader that fetches data:

// app/routes/posts.$id.tsx
import type { LoaderFunctionArgs } from 'react-router';
import { useLoaderData } from 'react-router';
import { db } from '~/db';
import { posts } from '~/db/schema';
import { eq } from 'drizzle-orm';

export async function loader({ params }: LoaderFunctionArgs) {
  const post = await db.query.posts.findFirst({
    where: eq(posts.id, params.id),
    with: {
      author: true,
      comments: {
        orderBy: (comments, { desc }) => [desc(comments.createdAt)],
        limit: 10,
      }
    }
  });

  if (!post) {
    throw new Response('Not Found', { status: 404 });
  }

  return { post };
}

export default function Post() {
  const { post } = useLoaderData<typeof loader>();

  return (
    <article>
      <h1>{post.title}</h1>
      <p>By {post.author.name}</p>
      <div>{post.content}</div>

      <section>
        <h2>Comments</h2>
        {post.comments.map(comment => (
          <div key={comment.id}>{comment.text}</div>
        ))}
      </section>
    </article>
  );
}

The data arrives with the initial HTML. No loading states. No client-side fetch waterfalls. Users see content immediately.

What's powerful here is the loader runs before the page renders. The HTML sent to the browser already contains the post data. No spinners. No "loading..." text. Just content.

Automatic Revalidation After Actions

Loaders revalidate automatically after actions complete. Submit a form that updates a post? React Router refetches the loader data. This covers most CRUD patterns without manual cache management:

// app/routes/posts.$id.edit.tsx
import type { ActionFunctionArgs, LoaderFunctionArgs } from 'react-router';
import { redirect } from 'react-router';
import { Form, useLoaderData } from 'react-router';

export async function loader({ params }: LoaderFunctionArgs) {
  const post = await db.query.posts.findFirst({
    where: eq(posts.id, params.id)
  });

  if (!post) throw new Response('Not Found', { status: 404 });
  return { post };
}

export async function action({ request, params }: ActionFunctionArgs) {
  const formData = await request.formData();
  const title = formData.get('title') as string;
  const content = formData.get('content') as string;

  await db.update(posts)
    .set({
      title,
      content,
      updatedAt: new Date()
    })
    .where(eq(posts.id, params.id));

  // Redirect back to the post page
  // This triggers the loader on posts.$id.tsx to revalidate
  return redirect(`/posts/${params.id}`);
}

export default function EditPost() {
  const { post } = useLoaderData<typeof loader>();

  return (
    <Form method="post">
      <input
        name="title"
        defaultValue={post.title}
        required
      />
      <textarea
        name="content"
        defaultValue={post.content}
        required
      />
      <button type="submit">Save</button>
    </Form>
  );
}

Submit the form, the action runs, the redirect happens, and the post page loader refetches. Your UI shows the updated data. No manual invalidation. No cache keys to manage.

This pattern handles most blog posts, product listings, user profiles, and admin panels without React Query.

When React Router Loaders Are Enough

Skip React Query if your app matches these patterns:

1. Traditional Page-Based Navigation

Users navigate between routes. Each route loads its data. The browser back button works naturally. You don't need client-side cache persistence across route changes.

I built a content management system with 40+ routes using just loaders. Posts list, individual posts, categories, tags, settings pages. Each route fetches what it needs. Navigation is fast because React Router prefetches on hover. No React Query needed.

2. Simple Mutations with Automatic Revalidation

Here's a complete example of deleting a comment:

// app/routes/posts.$postId.comments.$commentId.delete.tsx
import type { ActionFunctionArgs } from 'react-router';
import { redirect } from 'react-router';

export async function action({ params }: ActionFunctionArgs) {
  await db.delete(comments)
    .where(eq(comments.id, params.commentId));

  // Redirect back to the post
  // The post loader refetches, showing updated comment count
  return redirect(`/posts/${params.postId}`);
}

// In your post component
<Form method="post" action={`/posts/${post.id}/comments/${comment.id}/delete`}>
  <button type="submit">Delete</button>
</Form>

The form submits, the action runs, the redirect triggers the post loader to revalidate. The comment disappears from the list. This pattern works for:

• Creating posts
• Updating user profiles
• Deleting items
• Bulk operations

If your mutation affects data on the current route, loaders handle it automatically.

3. Data Scoped to Single Routes

If data lives on one route and doesn't appear elsewhere, loaders handle it perfectly. Each route loads what it needs when users visit.

Settings pages are a good example:

// app/routes/settings.notifications.tsx
export async function loader({ request }: LoaderFunctionArgs) {
  const userId = await getUserId(request);

  const settings = await db.query.notificationSettings.findFirst({
    where: eq(notificationSettings.userId, userId)
  });

  return { settings };
}

export async function action({ request }: ActionFunctionArgs) {
  const userId = await getUserId(request);
  const formData = await request.formData();

  await db.update(notificationSettings)
    .set({
      emailNotifications: formData.get('email') === 'on',
      pushNotifications: formData.get('push') === 'on',
    })
    .where(eq(notificationSettings.userId, userId));

  return { success: true };
}

These settings only appear on this route. No other component needs them. Loaders are perfect here.

4. Server-Heavy Applications

If your app renders mostly on the server and JavaScript is progressive enhancement, loaders give you server-side data fetching with zero client bundle impact.

React Query adds 40KB+ to your bundle. If you're building a documentation site, blog, or marketing pages with occasional interactivity, loaders keep your bundle small while providing excellent data loading.

The Breaking Points: When Loaders Become Insufficient

Here are the specific moments where React Router loaders hit their limits and you'll know you need React Query:

1. No Caching Between Navigations

Loaders only keep data for the current route. Click a link, the loader runs. Hit the back button, the loader runs again. Every navigation refetches everything.

This becomes painful when:

// User journey:
// 1. Visit /posts - loader fetches posts list (200 posts, 50KB response)
// 2. Click post #42 - loader fetches post details
// 3. Hit back button - loader fetches posts list AGAIN (same 50KB)
// 4. Click post #17 - loader fetches post details
// 5. Hit back button - loader fetches posts list AGAIN

You just downloaded the same 50KB posts list three times in one minute. Users on slow connections see loading states every time they navigate back.

React Query caches this. Navigate away, come back, see cached data instantly while React Query refetches in the background. The perceived performance difference is massive.

2. Data Used in Multiple Places

A header component needs the current user. A sidebar needs the current user. The settings page needs the current user. With loaders, your options are:

Option A: Fetch in every route's loader (wasteful)

// Every route that needs user data
export async function loader({ request }: LoaderFunctionArgs) {
  const user = await getUser(request); // Database query every time
  const posts = await getPosts(); // What this route actually needs
  return { user, posts };
}

You're making database queries for the same user data on every route. Slow. Expensive if you're paying per query.

Option B: Fetch in root loader, pass down via context (rigid)

// app/root.tsx
export async function loader({ request }: LoaderFunctionArgs) {
  const user = await getUser(request);
  return { user };
}

// Now every component needs the context or props

This works but you can't granularly control when user data refetches. If user updates their profile on a different route, how do you invalidate the root loader data? You're stuck with full page reloads or complex invalidation logic.

Option C: React Query (flexible)

// Fetch once, use everywhere, granular invalidation
const { data: user } = useUser();

Cache, share, invalidate independently. This is the pattern React Query was built for.

3. Polling and Real-Time Updates

Dashboard showing live metrics? Stock prices? Order status? Loaders run when you navigate to the route, then stop. They don't poll. They don't refetch in the background.

You'd need to build your own polling mechanism:

// With loaders only
export default function Dashboard() {
  const initialData = useLoaderData<typeof loader>();
  const [data, setData] = useState(initialData);

  useEffect(() => {
    const interval = setInterval(async () => {
      const response = await fetch('/api/metrics');
      const newData = await response.json();
      setData(newData);
    }, 30_000);

    return () => clearInterval(interval);
  }, []);

  return <div>Active Users: {data.activeUsers}</div>;
}

You just reimplemented React Query's refetchInterval feature. Badly. No deduplication if multiple components poll the same endpoint. No automatic cleanup. No error handling.

React Query handles this:

const { data } = useQuery({
  queryKey: ['metrics'],
  queryFn: fetchMetrics,
  refetchInterval: 30_000,
});

When your app needs data to update automatically without user interaction, loaders can't help.

4. You're Fetching the Same Data Repeatedly

Look at your network tab. Are you seeing the same API calls over and over with identical responses? You're wasting:

• User bandwidth (expensive on mobile)
• Server resources (database queries, API calls)
• User time (waiting for data they already saw)

I had a CMS where the posts list endpoint was called 15 times in 2 minutes of normal usage. Same 200 posts, same 50KB response. Adding React Query with a 5-minute stale time cut that to 1 request. The server CPU usage dropped 40%.

5. Mutations Affecting Multiple Routes

You create a post on /posts/new. The posts list lives on /posts. Your user profile shows post count on /profile. The home page shows recent posts on /.

With loaders, you need to manually revalidate all affected routes:

const fetcher = useFetcher();

// After creating a post, revalidate everything
fetcher.load('/posts');
fetcher.load('/profile');
fetcher.load('/');

Miss one and your UI shows stale data. Add a new route that shows posts? Remember to revalidate it everywhere posts get created, updated, or deleted.

React Query's invalidation handles this cleanly:

// Invalidate all queries with 'posts' in the key
queryClient.invalidateQueries({ queryKey: ['posts'] });

Every component using post data refetches. Automatically. No matter where in the app.

6. Optimistic Updates Are Critical

Your app has like buttons, follow buttons, todo toggles, or any interaction where waiting for the server feels slow. Loaders can't do optimistic updates. They're about loading data when you navigate, not updating data instantly on interaction.

You'd need to track optimistic state manually:

const [optimisticLikes, setOptimisticLikes] = useState<Record<string, number>>({});

async function handleLike(postId: string, currentLikes: number) {
  // Set optimistic state
  setOptimisticLikes(prev => ({ ...prev, [postId]: currentLikes + 1 }));

  try {
    await fetch(`/api/posts/${postId}/like`, { method: 'POST' });
    // Revalidate loader
    submit({}, { method: 'get' });
  } catch (error) {
    // Roll back on error
    setOptimisticLikes(prev => {
      const next = { ...prev };
      delete next[postId];
      return next;
    });
  }
}

Complex. Error-prone. React Query's onMutate and rollback handling make this pattern simple and reliable.

If you recognize your app in any of these scenarios, you need React Query. Loaders alone won't cut it.

When You Need React Query

React Query becomes valuable when you have these requirements:

1. Shared Data Across Multiple Components

A user profile appears in the header, sidebar, and settings page. With just loaders, you'd either:

• Fetch the same data three times on different routes
• Pass props through many layers (prop drilling hell)
• Use React context (which doesn't solve stale data problems)

React Query caches by query key. Fetch once, use everywhere:

// app/hooks/use-user.ts
import { useQuery } from '@tanstack/react-query';

interface User {
  id: string;
  name: string;
  email: string;
  avatarUrl: string;
  role: 'admin' | 'user';
}

export function useUser(userId: string) {
  return useQuery({
    queryKey: ['user', userId],
    queryFn: async (): Promise<User> => {
      const response = await fetch(`/api/users/${userId}`);
      if (!response.ok) throw new Error('Failed to fetch user');
      return response.json();
    },
    staleTime: 60_000, // Consider fresh for 1 minute
  });
}

Now use it anywhere:

// app/components/header.tsx
export function Header({ userId }: { userId: string }) {
  const { data: user } = useUser(userId);

  return (
    <header>
      <img src={user?.avatarUrl} alt={user?.name} />
      <span>{user?.name}</span>
    </header>
  );
}

// app/components/sidebar.tsx
export function Sidebar({ userId }: { userId: string }) {
  const { data: user } = useUser(userId);

  return (
    <aside>
      <div>{user?.name}</div>
      <div>{user?.email}</div>
      <div>Role: {user?.role}</div>
    </aside>
  );
}

// app/routes/settings.profile.tsx
export default function ProfileSettings({ userId }: { userId: string }) {
  const { data: user, isLoading } = useUser(userId);

  if (isLoading) return <div>Loading...</div>;

  return (
    <form>
      <input defaultValue={user?.name} />
      <input defaultValue={user?.email} />
    </form>
  );
}

All three components call useUser(userId). React Query makes only one network request. All components share the cached result. Update the user? One invalidation updates all three.

This pattern saved me from prop drilling through 5+ component layers in a dashboard application.

2. Background Refetching and Stale-While-Revalidate

React Query can refetch data in the background while showing cached data. Users see instant responses while you keep data fresh:

// Real-time dashboard showing live metrics
function DashboardMetrics() {
  const { data: metrics, dataUpdatedAt } = useQuery({
    queryKey: ['metrics'],
    queryFn: async () => {
      const response = await fetch('/api/metrics');
      return response.json();
    },
    staleTime: 30_000, // Consider fresh for 30 seconds
    refetchInterval: 60_000, // Refetch every minute
    refetchOnWindowFocus: true, // Refetch when user returns to tab
  });

  return (
    <div>
      <h2>Live Metrics</h2>
      <p>Active Users: {metrics?.activeUsers}</p>
      <p>Revenue Today: ${metrics?.revenueToday}</p>
      <p>Orders: {metrics?.ordersCount}</p>
      <small>Last updated: {new Date(dataUpdatedAt).toLocaleTimeString()}</small>
    </div>
  );
}

The component shows cached data instantly, then refetches in the background. Users never see a loading spinner after the initial load. The UI stays responsive while data updates.

This pattern doesn't exist in React Router loaders. Loaders fetch when you navigate to the route, not on a timer. If you need polling or real-time updates, you need React Query.

3. Optimistic Updates

Update the UI immediately while the mutation runs in the background. This makes your app feel instant:

// app/components/like-button.tsx
import { useMutation, useQueryClient } from '@tanstack/react-query';

interface Post {
  id: string;
  title: string;
  likes: number;
  likedByMe: boolean;
}

export function LikeButton({ post }: { post: Post }) {
  const queryClient = useQueryClient();

  const likeMutation = useMutation({
    mutationFn: async (postId: string) => {
      const response = await fetch(`/api/posts/${postId}/like`, {
        method: 'POST',
      });
      if (!response.ok) throw new Error('Failed to like post');
      return response.json();
    },

    // Run before the mutation starts
    onMutate: async (postId) => {
      // Cancel any outgoing refetches
      await queryClient.cancelQueries({ queryKey: ['posts', postId] });

      // Snapshot the previous value
      const previousPost = queryClient.getQueryData<Post>(['posts', postId]);

      // Optimistically update the cache
      queryClient.setQueryData<Post>(['posts', postId], (old) => {
        if (!old) return old;
        return {
          ...old,
          likes: old.likedByMe ? old.likes - 1 : old.likes + 1,
          likedByMe: !old.likedByMe,
        };
      });

      // Return context with the previous value
      return { previousPost };
    },

    // If mutation fails, rollback
    onError: (err, postId, context) => {
      if (context?.previousPost) {
        queryClient.setQueryData(['posts', postId], context.previousPost);
      }
    },

    // Always refetch after error or success
    onSettled: (data, error, postId) => {
      queryClient.invalidateQueries({ queryKey: ['posts', postId] });
    },
  });

  return (
    <button
      onClick={() => likeMutation.mutate(post.id)}
      disabled={likeMutation.isPending}
    >
      {post.likedByMe ? '❤️' : '🤍'} {post.likes}
    </button>
  );
}

Click the button. The heart fills and the count updates instantly. The mutation runs in the background. If it fails, React Query rolls back automatically. This creates a much faster perceived experience than waiting for server responses.

I use this pattern for:

• Like/favorite buttons
• Follow/unfollow actions
• Quick edits (updating post titles, comment text)
• Todo item toggles
• Cart operations

4. Infinite Scroll and Pagination

React Query has built-in infinite query support:

// app/components/posts-feed.tsx
import { useInfiniteQuery } from '@tanstack/react-query';
import { useInView } from 'react-intersection-observer';

interface Post {
  id: string;
  title: string;
  excerpt: string;
}

interface PostsPage {
  posts: Post[];
  nextCursor: string | null;
}

export function PostsFeed() {
  const { ref, inView } = useInView();

  const {
    data,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
  } = useInfiniteQuery({
    queryKey: ['posts', 'feed'],
    queryFn: async ({ pageParam }): Promise<PostsPage> => {
      const response = await fetch(
        `/api/posts?cursor=${pageParam ?? ''}`
      );
      return response.json();
    },
    getNextPageParam: (lastPage) => lastPage.nextCursor,
    initialPageParam: undefined,
  });

  // Fetch next page when bottom element comes into view
  React.useEffect(() => {
    if (inView && hasNextPage) {
      fetchNextPage();
    }
  }, [inView, hasNextPage, fetchNextPage]);

  return (
    <div>
      {data?.pages.map((page) => (
        page.posts.map((post) => (
          <article key={post.id}>
            <h2>{post.title}</h2>
            <p>{post.excerpt}</p>
          </article>
        ))
      ))}

      <div ref={ref}>
        {isFetchingNextPage ? 'Loading more...' : null}
      </div>
    </div>
  );
}

Scroll to the bottom, React Query loads the next page. The data accumulates in memory. Scroll back up? The data is still there. This provides a smooth infinite scroll experience.

You can implement pagination with loaders using URL search params:

// app/routes/posts._index.tsx
export async function loader({ request }: LoaderFunctionArgs) {
  const url = new URL(request.url);
  const page = parseInt(url.searchParams.get('page') ?? '1');

  const posts = await db.query.posts.findMany({
    limit: 20,
    offset: (page - 1) * 20,
  });

  return { posts, page };
}

But infinite scroll requires client-side data accumulation. React Query handles this elegantly while loaders don't.

5. Cross-Route Data Dependencies

If creating a post should update the posts list, and both live on different routes, you need coordinated invalidation. React Query handles this elegantly:

// app/routes/posts.new.tsx
import { useMutation, useQueryClient } from '@tanstack/react-query';
import { useNavigate } from 'react-router';

export default function NewPost() {
  const navigate = useNavigate();
  const queryClient = useQueryClient();

  const createMutation = useMutation({
    mutationFn: async (post: { title: string; content: string }) => {
      const response = await fetch('/api/posts', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(post),
      });
      return response.json();
    },

    onSuccess: (data) => {
      // Invalidate the posts list on another route
      queryClient.invalidateQueries({ queryKey: ['posts', 'list'] });

      // Invalidate the feed
      queryClient.invalidateQueries({ queryKey: ['posts', 'feed'] });

      // Navigate to the new post
      navigate(`/posts/${data.id}`);
    },
  });

  return (
    <form onSubmit={(e) => {
      e.preventDefault();
      const formData = new FormData(e.currentTarget);
      createMutation.mutate({
        title: formData.get('title') as string,
        content: formData.get('content') as string,
      });
    }}>
      <input name="title" required />
      <textarea name="content" required />
      <button type="submit">Create Post</button>
    </form>
  );
}

Create a post on the /posts/new route. Navigate to /posts. The list includes your new post immediately. React Query invalidated the cached list data.

With just loaders, you'd need to manually trigger revalidation:

const fetcher = useFetcher();

// After creating, manually revalidate the posts list
fetcher.load('/posts');

It works, but React Query's invalidation is more ergonomic when you have complex data dependencies across routes.

How Query Invalidation Works

React Query's invalidation system is the most compelling reason to use it. Here's how it works in detail:

Mark Queries as Stale

queryClient.invalidateQueries({ queryKey: ['posts'] });

This marks all queries with that key as stale. If a component is currently using this query and it's mounted, React Query refetches immediately. If no component is using the query, it refetches next time a component mounts.

The refetch happens in the background. Users see cached data while fresh data loads.

Invalidate Related Queries

The query key array structure lets you invalidate broadly or surgically:

// Invalidate ALL posts queries
// Matches: ['posts'], ['posts', 'list'], ['posts', '123'], etc.
queryClient.invalidateQueries({ queryKey: ['posts'] });

// Invalidate only the posts list
// Matches: ['posts', 'list'] but not ['posts', '123']
queryClient.invalidateQueries({ queryKey: ['posts', 'list'], exact: true });

// Invalidate a specific post
// Matches: ['posts', '123'] but not ['posts', 'list'] or ['posts', '456']
queryClient.invalidateQueries({ queryKey: ['posts', '123'] });

// Invalidate all posts for a specific user
// Matches: ['posts', { authorId: 'user123' }]
queryClient.invalidateQueries({
  queryKey: ['posts'],
  predicate: (query) => {
    const [, filters] = query.queryKey;
    return filters?.authorId === 'user123';
  }
});

This hierarchical key structure is powerful. I structure query keys like this:

['posts'] // All posts
['posts', 'list'] // Posts list
['posts', 'list', { filter: 'published' }] // Filtered list
['posts', postId] // Individual post
['posts', postId, 'comments'] // Post comments
['user', userId] // User profile
['user', userId, 'posts'] // User's posts

Now I can invalidate precisely:

// User updates their profile
queryClient.invalidateQueries({ queryKey: ['user', userId] });

// User publishes a post - update their posts list
queryClient.invalidateQueries({ queryKey: ['user', userId, 'posts'] });

// Someone comments on a post - update just the comments
queryClient.invalidateQueries({ queryKey: ['posts', postId, 'comments'] });

Automatic Refetch on Window Focus

useQuery({
  queryKey: ['posts'],
  queryFn: fetchPosts,
  refetchOnWindowFocus: true, // Default behavior
  refetchOnReconnect: true, // Also refetch when reconnecting to network
});

User switches tabs, comes back 10 minutes later? React Query refetches. This keeps data fresh without manual intervention.

I disable this for data that changes rarely:

useQuery({
  queryKey: ['site-config'],
  queryFn: fetchConfig,
  refetchOnWindowFocus: false, // Site config rarely changes
  staleTime: Infinity, // Never consider stale
});

The Hybrid Approach: Using Both Together

The most powerful pattern combines both: loaders for fast initial page loads, React Query for sophisticated client-side data management. This gives you server-rendered HTML with instant data, plus all of React Query's features for updates, caching, and invalidation.

The Pattern: Loaders Pre-Fill React Query Cache

Instead of using loader data directly, use loaders to populate React Query's cache before the component renders. Then use useQuery in components as normal:

// app/routes/posts.$id.tsx
import type { LoaderFunctionArgs } from 'react-router';
import { useParams } from 'react-router';
import { useQuery } from '@tanstack/react-query';
import { queryClient } from '~/query-client';

// Loader runs on the server, fetches data, pre-fills React Query cache
export async function loader({ params }: LoaderFunctionArgs) {
  // Use fetchQuery to pre-fill cache and throw errors to errorElement
  await queryClient.fetchQuery({
    queryKey: ['posts', params.id],
    queryFn: async () => {
      const response = await fetch(`/api/posts/${params.id}`);
      if (!response.ok) throw new Response('Not Found', { status: 404 });
      return response.json();
    },
  });

  // Return null or empty object - React Query has the data
  return {};
}

export default function Post() {
  const params = useParams();

  // React Query cache already has this data from the loader
  // Component shows it instantly, no loading state
  const { data: post, isLoading } = useQuery({
    queryKey: ['posts', params.id],
    queryFn: async () => {
      const response = await fetch(`/api/posts/${params.id}`);
      return response.json();
    },
    staleTime: 60_000, // Consider fresh for 1 minute
    refetchOnWindowFocus: true, // Refetch when user returns
  });

  if (isLoading) return <div>Loading...</div>;

  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  );
}

What happens:

1. User visits /posts/123
2. Loader runs on server, calls fetchQuery which populates React Query cache
3. Component renders, useQuery finds data already in cache, shows it instantly
4. No loading state, users see content immediately
5. React Query continues managing the cache (refetch on focus, invalidation, etc.)

This is better than using initialData because:

• The cache is populated before rendering (no hydration issues)
• Error handling works correctly (errors throw to errorElement)
• Multiple components can read from the same cache entry
• Refetching logic works consistently

Mutations with Hybrid Approach

Mutations work beautifully with this pattern. Use React Query mutations, invalidate the query, and React Query refetches automatically:

// app/components/like-button.tsx
import { useMutation, useQueryClient } from '@tanstack/react-query';

export function LikeButton({ postId }: { postId: string }) {
  const queryClient = useQueryClient();

  const likeMutation = useMutation({
    mutationFn: async () => {
      await fetch(`/api/posts/${postId}/like`, { method: 'POST' });
    },
    onSuccess: () => {
      // Invalidate the post query - React Query refetches automatically
      queryClient.invalidateQueries({ queryKey: ['posts', postId] });
    },
  });

  return (
    <button onClick={() => likeMutation.mutate()}>
      Like
    </button>
  );
}

The invalidation triggers a refetch. If you navigate away and come back, the loader pre-fills the cache with fresh data. Everything stays synchronized.

Pre-Filling Multiple Queries

Loaders can pre-fill multiple related queries:

// app/routes/posts.$id.tsx
export async function loader({ params }: LoaderFunctionArgs) {
  // Pre-fill multiple queries in parallel
  await Promise.all([
    queryClient.fetchQuery({
      queryKey: ['posts', params.id],
      queryFn: () => fetchPost(params.id),
    }),
    queryClient.fetchQuery({
      queryKey: ['posts', params.id, 'comments'],
      queryFn: () => fetchComments(params.id),
    }),
    queryClient.fetchQuery({
      queryKey: ['posts', params.id, 'author'],
      queryFn: () => fetchAuthor(params.id),
    }),
  ]);

  return {};
}

// Components use the queries independently
export default function Post() {
  const params = useParams();

  const { data: post } = useQuery({
    queryKey: ['posts', params.id],
    queryFn: () => fetchPost(params.id!),
  });

  const { data: comments } = useQuery({
    queryKey: ['posts', params.id, 'comments'],
    queryFn: () => fetchComments(params.id!),
  });

  // All data is already cached from the loader
  // No loading states, instant render
  return (
    <article>
      <h1>{post.title}</h1>
      <Comments comments={comments} />
    </article>
  );
}

Prefetching on Hover

Combine React Router's <Link> with React Query prefetching for instant navigation:

// app/components/post-link.tsx
import { Link } from 'react-router';
import { useQueryClient } from '@tanstack/react-query';

export function PostLink({ post }: { post: Post }) {
  const queryClient = useQueryClient();

  return (
    <Link
      to={`/posts/${post.id}`}
      onMouseEnter={() => {
        // Prefetch on hover
        queryClient.prefetchQuery({
          queryKey: ['posts', post.id],
          queryFn: () => fetchPost(post.id),
        });
      }}
    >
      {post.title}
    </Link>
  );
}

Hover over a link, React Query prefetches the data. Click the link, the loader finds it already cached. The page loads instantly.

When to Use This Pattern

Use loaders + React Query together when you need:

• Fast initial page loads (server-rendered HTML with data)
• Rich client-side interactions (optimistic updates, polling, invalidation)
• Shared data across components (global cache)
• Progressive enhancement (works without JavaScript, enhanced with it)

I use this pattern for production apps that need both excellent perceived performance and sophisticated data management. The extra setup is worth it for complex applications.

Performance and Bundle Size Trade-offs

Choosing between loaders only, React Query only, or both has real performance implications. Here's what you're trading:

Bundle Size

React Router loaders: ~0KB additional

• Built into React Router, no extra dependency
• No client-side data fetching library needed
• Minimal JavaScript for the data layer

React Query: ~45KB minified + gzipped

• Core library: ~40KB
• DevTools (dev only): ~5KB
• This is meaningful on slow connections or low-powered devices

If you're building a documentation site, blog, or marketing pages where most users visit 1-2 pages and leave, those 45KB matter. You're paying for features you don't use.

If you're building a SaaS dashboard where users spend hours per session with hundreds of interactions, those 45KB are negligible compared to the value React Query provides.

Time to Interactive (TTI)

Loaders excel at TTI:

User requests page
  → Server runs loader
  → Server renders HTML with data
  → Browser receives complete HTML
  → Page is interactive immediately

The HTML contains the data. No client-side JavaScript needs to run to fetch and display content. This is perfect for content sites, blogs, and server-first applications.

React Query adds hydration overhead:

User requests page
  → Server runs loader (if using hybrid approach)
  → Server renders HTML
  → Browser receives HTML
  → React hydrates
  → React Query hydrates its cache
  → Page is fully interactive

The extra hydration step adds 50-200ms depending on cache size. Not huge, but measurable. If you're optimizing for the fastest possible TTI, loaders alone win.

Ongoing Performance

After initial load, React Query wins:

With loaders:

• Navigate back: refetch everything (network request, wait, render)
• Switch tabs and return: refetch everything
• Same data in multiple places: multiple fetches

With React Query:

• Navigate back: instant (cached data shows immediately)
• Switch tabs and return: instant (cached data) + background refetch
• Same data in multiple places: one fetch, shared cache

I measured a CMS built with loaders only vs the same app with React Query. Over a 5-minute user session with typical navigation:

• Loaders only: 47 network requests, 850KB transferred, users waited for loading states 8 times
• React Query: 12 network requests, 240KB transferred, users saw loading states once (initial load)

The caching eliminated 75% of network requests and made navigation feel instant. The 45KB bundle cost was paid back in reduced data transfer and better UX.

When Bundle Size Matters Most

Add React Query when:

• Users stay on your app for extended sessions (dashboards, tools, SaaS)
• Lots of navigation between routes
• Data appears in multiple places
• User interactions trigger updates frequently

Skip React Query when:

• Users visit one page and leave (landing pages, blogs, docs)
• Each page is independent with no shared data
• Server rendering is the priority
• You're optimizing for the smallest possible bundle

Real-World Bundle Analysis

For a typical React Router v7 app, here's what you're shipping:

Minimal (loaders only):

• React + React DOM: ~140KB
• React Router: ~30KB
• Your app code: varies
• Total base: ~170KB

With React Query:

• React + React DOM: ~140KB
• React Router: ~30KB
• React Query: ~45KB
• Your app code: varies
• Total base: ~215KB

That's a 26% increase in baseline JavaScript. For some apps it's worth it. For others it's not. Make the choice deliberately based on your data patterns, not defaults.

The Practical Decision Tree

Ask these questions about your app:

Start with React Router Loaders Alone

✅ Use loaders only if:

• Each route owns its data: Post detail page needs post data. Settings page needs settings. No overlap.
• Users navigate linearly: Landing page → feature page → signup. Not much back-button usage.
• Session duration < 5 minutes: Landing pages, docs, marketing sites. Users read and leave.
• Mutations are simple: Create post → redirect to post. Update settings → show success. Automatic revalidation handles it.
• Bundle size matters: You're shipping to users on slow connections or tracking performance budgets.

Examples: Documentation sites, blogs, marketing websites, simple CRUD admin panels, server-rendered content sites.

Add React Query When You Hit These Signals

⚠️ Add React Query if you notice:

• Network tab shows duplicates: Same API call fetching the same data multiple times in one session.
• Multiple loaders fetch the same thing: User profile appears in 3+ route loaders. You're querying the database repeatedly for identical data.
• Users navigate back frequently: Analytics show high back-button usage. Users seeing loading states they already saw.
• Data needs to stay fresh: Stock prices, order status, live metrics. You need polling or refetch intervals.
• Mutations affect multiple places: Create a post and need to update the list page, profile page, and home feed.
• Optimistic updates would help: Like buttons, toggles, quick edits feel slow waiting for server confirmation.

Examples: SaaS dashboards, social media apps, real-time monitoring tools, collaborative editors, e-commerce apps with cart management.

Use the Hybrid Approach (Both Together)

🚀 Use loaders + React Query when:

• SSR is critical AND you need rich interactions: You need fast initial page loads (SEO, perceived performance) but also sophisticated client-side data management.
• Progressive enhancement matters: App works without JavaScript (loaders render content) but enhanced with it (React Query adds caching, optimistic updates).
• Mix of static and dynamic routes: Some routes are simple (use loaders only), others need real-time updates (add React Query where needed).
• Building a complex app incrementally: Start with loaders, add React Query to specific routes as needed. Best of both worlds.

Examples: E-commerce sites (product pages are static, cart is dynamic), content platforms with personalization, admin dashboards with mixed data patterns, complex multi-page forms with shared state.

Quick Reference by App Type

The decision isn't about which is "better." It's about matching the tool to your data patterns and user behavior.

Migration Path: Adding React Query When You Need It

You started with loaders only. Now you're hitting limitations. Here's how to add React Query incrementally without rewriting your entire app.

Step 1: Install and Configure

bun add @tanstack/react-query @tanstack/react-query-devtools

Add the provider to your root route (shown in "Setting Up React Query" section above). Your existing loader-based routes keep working unchanged.

Step 2: Identify Problem Areas First

Don't migrate everything. Find the routes where loaders are causing pain:

• Data fetched repeatedly (check network tab for duplicates)
• Shared data fetched in multiple loaders
• Routes that need real-time updates or polling
• Complex invalidation needs (mutations affecting multiple routes)

Start with these routes. Leave routes that work fine alone.

Step 3: Migrate One Route to Hybrid Pattern

Pick one problematic route. Convert it to use the hybrid pattern:

Before (loader only):

// app/routes/dashboard.tsx
export async function loader() {
  const metrics = await fetchMetrics();
  return { metrics };
}

export default function Dashboard() {
  const { metrics } = useLoaderData<typeof loader>();
  return <div>Active Users: {metrics.activeUsers}</div>;
}

After (hybrid with React Query):

// app/routes/dashboard.tsx
import { useQuery } from '@tanstack/react-query';
import { queryClient } from '~/query-client';

export async function loader() {
  // Pre-fill cache
  await queryClient.fetchQuery({
    queryKey: ['metrics'],
    queryFn: fetchMetrics,
  });
  return {};
}

export default function Dashboard() {
  // Use React Query in component
  const { data: metrics } = useQuery({
    queryKey: ['metrics'],
    queryFn: fetchMetrics,
    refetchInterval: 30_000, // Now we can poll!
  });

  return <div>Active Users: {metrics?.activeUsers}</div>;
}

Deploy this one change. Verify it works. Now that route gets all React Query benefits (caching, polling, invalidation) while keeping the fast initial load from the loader.

Step 4: Extract Shared Data to React Query

If user data appears in multiple route loaders, extract it:

Before:

// app/routes/posts._index.tsx
export async function loader({ request }) {
  const user = await getUser(request); // Fetched here
  const posts = await getPosts();
  return { user, posts };
}

// app/routes/settings.tsx
export async function loader({ request }) {
  const user = await getUser(request); // And here
  const settings = await getSettings();
  return { user, settings };
}

After:

// app/hooks/use-current-user.ts
export function useCurrentUser() {
  return useQuery({
    queryKey: ['currentUser'],
    queryFn: async () => {
      const response = await fetch('/api/me');
      return response.json();
    },
    staleTime: 1000 * 60 * 5, // Cache for 5 minutes
  });
}

// app/routes/posts._index.tsx
export async function loader() {
  const posts = await getPosts(); // Only fetch posts
  return { posts };
}

export default function PostsIndex() {
  const { data: user } = useCurrentUser(); // Get user from cache
  const { posts } = useLoaderData<typeof loader>();

  return <div>Welcome {user?.name}</div>;
}

Now user data fetches once, caches, and every component can access it. This is the biggest win when migrating.

Step 5: Convert Mutations to React Query

Replace action-based mutations with React Query mutations for better control:

Before:

export async function action({ request, params }) {
  const formData = await request.formData();
  await updatePost(params.id, formData);
  return redirect(`/posts/${params.id}`);
}

After:

import { useMutation, useQueryClient } from '@tanstack/react-query';

export default function EditPost() {
  const queryClient = useQueryClient();

  const updateMutation = useMutation({
    mutationFn: (data) => updatePost(postId, data),
    onSuccess: () => {
      // Invalidate all affected queries
      queryClient.invalidateQueries({ queryKey: ['posts'] });
      navigate(`/posts/${postId}`);
    },
  });

  return <form onSubmit={(e) => {
    e.preventDefault();
    const formData = new FormData(e.currentTarget);
    updateMutation.mutate(Object.fromEntries(formData));
  }} />;
}

Now you can do optimistic updates, show loading states, and invalidate queries across the entire app.

Step 6: Keep What Works

Not every route needs React Query. I have apps where:

• 80% of routes use loaders only (simple CRUD, settings pages, forms)
• 20% of routes use React Query (dashboards, shared data, real-time features)

This is fine. The hybrid approach lets you use the right tool for each route. Static content? Loader. Dynamic, shared, or real-time? React Query.

Common Migration Pitfalls

Don't immediately remove all loaders:

Loaders are still valuable for SSR and initial data. Keep them to pre-fill React Query cache.

Don't duplicate query logic:

Create shared query functions:

// app/queries/posts.ts
export const postQueries = {
  all: () => ['posts'] as const,
  lists: () => [...postQueries.all(), 'list'] as const,
  list: (filters: string) => [...postQueries.lists(), { filters }] as const,
  details: () => [...postQueries.all(), 'detail'] as const,
  detail: (id: string) => [...postQueries.details(), id] as const,
};

export async function fetchPost(id: string) {
  const response = await fetch(`/api/posts/${id}`);
  return response.json();
}

// Use in both loaders and components
export async function loader({ params }) {
  await queryClient.fetchQuery({
    queryKey: postQueries.detail(params.id),
    queryFn: () => fetchPost(params.id),
  });
  return {};
}

export default function Post() {
  const params = useParams();
  const { data: post } = useQuery({
    queryKey: postQueries.detail(params.id!),
    queryFn: () => fetchPost(params.id!),
  });
}

This keeps query keys consistent and logic DRY.

Don't over-cache:

Set appropriate staleTime and cacheTime. Don't cache everything forever. Fresh data matters more than cache hits for critical information.

The migration doesn't have to happen all at once. Add React Query where it solves problems. Keep loaders where they work well. Ship incrementally.

What I'd Do Differently

I used to add React Query by default to every project. After working with React Router v7's framework mode for six months, I don't. The automatic revalidation after actions covers 80% of what I needed React Query for.

For new projects, I start with just loaders. When I find myself needing data in multiple places or wanting background updates, I add React Query. This keeps the initial bundle smaller and the mental model simpler.

The combination of server-side loaders for initial data and React Query for client-side updates is powerful when you need it. But don't reach for it until you actually need it.

I have a production app with 60+ routes using just loaders. It's a content management system where each route loads its own data. Fast, simple, maintainable. React Query would add complexity without benefit.

I have another production app that's a real-time dashboard. React Query is critical there. Shared data across widgets, background polling, optimistic updates when users interact. Loaders alone wouldn't work.

The right choice depends on your data patterns, not dogma about which tool is "better."

The Automation Problem

Copilot categorizes transactions automatically, and I only need to check in once a week. Origin wants me to review transactions regularly, shifting work from manual entry to manual review. That is busy work dressed up as a feature.

Missing the Basics

Origin tries to replace Mint with net worth tracking, AI planning, tax filing, estate planning, and CFP access, which is an ambitious scope.

The AI features are slow, and they generate insights you will probably ignore. Copilot's simpler approach already covers the same ground faster.

Origin can't handle bulk delete for transactions. When you import accounts or fix mistakes, you delete one-by-one. You can't ship tax filing before you've nailed bulk delete.

Both apps use Plaid for bank connections. Origin adds MX and Finicity as fallbacks — 50,000+ connections vs Plaid's 11,000. That matters if your bank doesn't connect through Plaid. But better connectivity is worthless if the core experience exhausts you.

What Copilot Got Right

Copilot iterated on the core experience. The app doesn't ask you to do work it should handle.

Origin feels unfinished, with an ambitious roadmap but lagging execution.

If I were building a financial app: start with Plaid, make automation work without user validation, add bulk operations, then expand. Don't ask users to do your job.

Copilot gets this right, while Origin does not — at least not yet.

Origin's ambition is worth exploring if you need multiple data connectors, tax filing, or estate planning. Use this referral link to get your first year for $1. Go in knowing you'll review transactions regularly. That's the trade-off.

Next.js 16 (also October) made Turbopack the default bundler with 2-5x faster builds. Bun 1.3 shipped full-stack runtime support. The entire React ecosystem got a performance upgrade without requiring you to rewrite anything.

Before and After

Before: you wrapped components in React.memo, dependencies in useCallback, and expensive calculations in useMemo. You forgot half the time. When you remembered, you maintained dependency arrays by hand.

After: the compiler analyzes your code and memoizes values used in rendering. It memoizes conditionally — something you could not do manually.

This code:

function Form({ onSubmit, onMount }) {
  // your component logic
}

Now behaves as if you wrapped onSubmit and onMount in useCallback and Form in React.memo. You did not have to write any of that manually because the compiler handles it during the build.

You write cleaner code. The compiler catches edge cases you would miss. Same philosophy as TypeScript — let the tooling do the work.

When You Still Need Manual Memoization

The official React blog explains this: manual memoization guarantees reference stability for effect dependencies. The effect only runs when the dependency changes in value, not on every render.

Setting It Up

React Compiler requires React 19+. For React 17 or 18, you also need react-compiler-runtime@latest.

With Next.js

Next.js 16 has the compiler integrated. Update your config:

// next.config.js
const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};

Next.js handles the Babel plugin setup automatically.

With Vite

Vite uses esbuild by default, so you add the Babel plugin manually. The trade-off: automatic memoization at the cost of Babel overhead in your build.

Install:

npm install babel-plugin-react-compiler@latest

Configure:

// vite.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: ["babel-plugin-react-compiler"],
      },
    }),
  ],
});

The React Compiler must run first in your Babel plugin pipeline. @vitejs/plugin-react handles this when configured as shown.

The Vite team is working with oxc on native compiler support. Once that ships alongside Rolldown, you get automatic memoization without Babel. The React docs will update with migration info when that happens.

Turbopack Goes Default

Next.js 16 shipped Turbopack as the default bundler in October. Vercel runs production sites on it (vercel.com, v0.app, nextjs.org). Their benchmarks show 2-5x faster builds depending on project size.

Fast Refresh is about 10x quicker, which is the difference between grabbing coffee during a rebuild and seeing the change instantly.

Next.js 15.5 (August) had Turbopack in beta. Two months later it became the default.

Bun 1.3 added full-stack runtime support and compiles entire apps into standalone binaries. While not directly related to React Compiler, this is part of the same trend: tools getting faster without changing how you write code.

What Shifted

Manual optimization became automatic optimization. Your codebase is cleaner without memo wrappers. The compiler catches optimization opportunities you would miss.

Next.js switching to Turbopack as the default signals this is production-ready. They run their own infrastructure on it.

What To Do

1. Update to React 19+ (or 17/18 with react-compiler-runtime)
2. Install the compiler: npm install babel-plugin-react-compiler@latest
3. Configure it (Next.js: experimental flag, Vite: Babel plugin)
4. Remove React.memo from components where it is not needed
5. Remove most useCallback/useMemo (keep for useEffect deps)
6. Watch your bundle size and build times

The React Compiler installation guide has framework-specific setup for Next.js, Remix, Vite, and others. The Next.js 16 announcement covers Turbopack details.

Compiler 1.0 and Turbopack becoming default are not about learning new patterns. The tools got better while you keep writing the same code.

153,074 job cuts in October. Triple last year's October. The worst since 2003. AI was cited for 31,039 of those cuts. Tech alone lost 33,281 jobs in a single month, six times September's number.

Most companies citing AI aren't replacing workers with automation. They're using "AI transformation" as PR cover for correcting pandemic overhiring while avoiding the word "layoff."

The Numbers Don't Add Up

The Challenger, Gray & Christmas October report breaks down the stated reasons:

Cost-cutting was the #1 reason. AI was #2. When you look at who's cutting and what they're saying, the story shifts.

Amazon cut 14,000 corporate jobs. CEO Andy Jassy told GeekWire the layoffs weren't "financially driven" or "AI-driven" — it's about "culture" and staying "nimble." Six months earlier, the same CEO wrote in a memo that AI would reduce their corporate workforce over time.

Which explanation is it?

Google cut 100+ design roles from their cloud unit while ramping up AI infrastructure spending. Intel cut 15% of its global workforce — about 25,000 people — after overinvesting in chip manufacturing. Meta spent $19.37 billion on AI this year, double last year, while letting people go.

Companies are using "AI transformation" to avoid saying "we hired too many people in 2021 and now we're fixing it."

The AI Washing Problem

79% of US CEOs fear losing their jobs if they don't deliver measurable AI-driven business gains within two years. That creates an incentive to blame AI for layoffs even when the real reason is overcapacity or cost-cutting.

Business professors call it "AI washing." Tell investors you're firing workers because AI can replace them — they cheer. Tell them you overhired during the pandemic boom — they punish your stock.

Wall Street rewards "AI transformation," but Wall Street punishes "we made hiring mistakes."

The warehousing sector tells the real story. Those 47,878 cuts (a 4,700% month-over-month increase) are not AI washing but actual automation, with robots replacing humans in distribution centers. Year-to-date, warehousing has cut 90,418 jobs, up 378% from last year.

That's what automation-driven layoffs look like. Compare that to Amazon's "culture" excuse or Google's "design role optimization."

What I'm Seeing in San Francisco

The tech jobs getting cut aren't the ones AI can replace yet. They're middle management, project coordinators, design researchers — roles companies added when headcount growth was the metric everyone cared about. You see it in SF's tech corridors. There are fewer people at the coffee shops during work hours.

The AI jobs everyone promised would replace them? Still mostly infrastructure spending. More GPUs, more AI researchers, more "alignment engineers." Not the distributed workforce of AI-augmented individual contributors we were told would emerge.

Friends who got cut aren't hearing "your role is automated now." They're hearing "we're restructuring" or "eliminating redundancy" or my favorite: "evolving our organizational structure."

One person told me their entire team got eliminated three months after leadership presented a roadmap showing AI would "10x their productivity." The AI tools never materialized. The headcount reduction did.

The Uncomfortable Truth

Some of these cuts ARE automation-driven. That warehousing number isn't a typo. Distribution centers are replacing humans with robots at scale. Manufacturing is next. Customer service is already there.

The white-collar tech layoffs are a different story. Most are pandemic correction dressed up as AI strategy. Companies hired aggressively in 2021 based on growth assumptions that proved wildly optimistic. When reality hit, they needed to right-size.

The difference between now and two years ago is the narrative. In 2022-2023, companies announced layoffs and took the stock hit. In 2025, they announce "AI-driven efficiency improvements" and get rewarded.

The outcome is the same, but the optics are better.

Over 1 million job cuts for 2025 so far. Employers announced only 488,077 planned hires through October, down 35% from last year. That's the lowest since 2011.

AI will replace jobs. That's not the question. The question is whether we're honest about what's happening right now. October's data says we're not.

Next time a company cites "AI transformation" for layoffs, check whether they're deploying AI or deploying euphemisms. The Challenger report tracks this monthly. Watch for the gap between "AI cited" and actual automation deployment.

That gap is where the AI washing is happening.

Why Switch?

The native Claude Code binary is faster, more reliable, and maintained as the official distribution. The npm version was a temporary solution while the native version was being developed.

Uninstall the npm Version

npm uninstall -g @anthropic-ai/claude-code

Install the Native Version

Pick the method that matches your operating system.

macOS

Homebrew:

brew install --cask claude-code

Linux

Installation script:

curl -fsSL https://claude.ai/install.sh | bash

WSL (Windows Subsystem for Linux)

Same as Linux:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell

PowerShell script:

irm https://claude.ai/install.ps1 | iex

Verify Installation

Confirm it works:

claude --version

claude /doctor

You should see the version number, which confirms you are running the native CLI.

What's Next?

Claude Code handles codebase questions, command execution, and coding tasks from the terminal. See the documentation for the full feature set.

The research team had become bureaucratic, and they are cutting the slowness.

What Wang's Reorganization Tells You

This isn't cost-cutting disguised as efficiency. It's a priority realignment. Wang (former Scale AI CEO) now runs Meta's AI. Yann LeCun, the legendary FAIR leader, reports to him. Meta chose superintelligence speed over foundational research depth.

The numbers reinforce it. Meta invested $14.3 billion in Scale AI earlier this year and closed a $27 billion financing deal for data centers. Those funds flow to TBD Lab's race for AGI, not to FAIR's long-term research agenda.

FAIR's theoretical breakthroughs eventually become products. But "eventually" doesn't win when you're competing with OpenAI, Google, and Anthropic on superintelligence timelines. When the business question becomes "who gets to AGI first," organizations reshape around speed.

The Backdoor Layoff — And Why This Isn't One

This connects to something I've written about before: AI as the backdoor layoff strategy. Companies can either announce layoffs (stock drops, media scrutiny, morale collapse) or announce AI efficiency gains (stock rises, innovation narrative).

Meta is doing something different. They're being direct about restructuring. They acknowledge the organizational problem. They're not claiming FAIR is failing. They're saying that in a superintelligence race, you optimize differently.

FAIR has produced important research over the years. Research that does not ship is ultimately just cost. If Meta believes AGI is the defining competition, resources should flow there.

Yann LeCun will probably be fine. He's legendary enough to land anywhere, and Meta seems committed to keeping him in some capacity. The message to the broader AI research community is blunt: if your foundational questions won't ship this decade, work somewhere else.

The Timing

Meta is signaling it's serious about superintelligence. Not someday, but right now. The company is willing to cut headcount and reorganize around that priority.

Whether TBD Lab delivers anything resembling superintelligence is a separate question. The organizational commitment is real. There is no equivocating about research timelines and no "we support both" messaging. This is what they are betting on.

Atlas adds chat, memory, and agent mode to your browser. Talk to ChatGPT about any webpage. It remembers what you've browsed and suggests relevant content. Agents automate bookings and form-filling. Available for macOS now.

Perplexity launched Comet in July 2024 — nearly a year earlier. Same feature set: sidecar assistant, task automation, background agents. After launching at $200/month, they made it free globally in October 2025.

Both solve the same problem the same way, and neither is truly innovative since it is what you would expect when combining an LLM with a browser. OpenAI wins on distribution — 200+ million ChatGPT users. Perplexity gets credit for building it first and making it free.

What are these browsers actually for?

I have used Comet to find coupons, search things, and summarize pages, and it works fine. But what can an AI browser do that opening ChatGPT in a tab cannot?

Automated bookings sound appealing, but do you trust your browser with payment info? Managing Linear projects sounds good until you remember people already have integrations, and inline text editing only saves a single click.

People don't need an AI browser. They need Gmail with AI writing, Linear with AI summaries — apps that already have AI built in. The browser is a distribution channel, not the product.

Both assume the bottleneck is information access or task automation. It's judgment. I don't need AI to find the cheapest flight — I need to decide if the layover is worth it. I don't need AI to summarize an article — I need to know if it matters. These browsers automate what was already easy.

OpenAI wins on scale. Perplexity built it first and made it free. Both will find users, but neither will replace Chrome. When you have a great LLM, integrating it everywhere is the obvious next step, and that is not innovation but simply the market filling in the gaps.

Claude Code generates $500 million in annual revenue and has seen 10x user growth since May. Inside Anthropic, Claude Code writes 90% of their code, and output per engineer has jumped 67%. When your own tool works that well, you ship it everywhere.

Three Interfaces, Different Tradeoffs

Web runs tasks on Anthropic's cloud. Multiple tasks run in parallel, which the CLI can't do. Real-time progress, mid-task steering, session resumption.

CLI runs locally with direct filesystem access and is single-threaded. You control the environment, but pay-as-you-go pricing stacks up when you're hammering it.

iOS is for monitoring and light tasks: checking progress, providing feedback, triggering simple refactors. Anthropic admits it needs refinement.

All three connect to GitHub the same way. Install the GitHub app, authorize access (contents, issues, PRs), add the Claude Dispatch workflow. Claude gets sandboxed with network and filesystem restrictions. A secure proxy handles git operations — it can't touch repos you didn't authorize.

The Maintenance Machine

Refactoring, test generation, dependency upgrades, and bug fixing are not glamorous, but that is what fills sprints. React project needs upgrading? Claude analyzes the codebase, identifies breaking changes, runs migrations across files.

Type annotations on JavaScript files. Unit tests for new functions. Database migrations from schema changes. The time savings pile up on repetitive work that eats days, not on architectural decisions.

The web interface shifts the psychology. You're delegating, not augmenting your editor. That changes how you scope the work.

Distribution Wins

Claude Code used to live inside Cursor or a VS Code plugin. You had to seek it out.

Now it's a browser tab. GitHub OAuth and you're in. You can try it on one task without committing to another tool.

Pro ($20/month) and Max ($100-200/month) include full Claude Code access across web, iOS, and CLI. Shared limits with regular Claude chat, reset every five hours.

I got access to Sora in TikTok form, and something clicked. This isn't annoying because Sora is bad. It's annoying because it's honest.

Friction Is Gone

Lying used to have a cost. Fabricating video evidence meant work. Film it. Edit it. Make it convincing. That work was friction. Friction penalized lying with time, effort, and risk of exposure.

Sora removes that penalty entirely.

Now you prompt an AI. Fake historical event? Seconds. Celebrity deepfake? Done. False testimony on video? Trivial. Fabricating is now easier than capturing reality.

Why This Breaks the System

Social media optimizes for engagement over truth. That only works if truth is expensive enough to be selective. You can't put everything on the feed.

With friction, lying is selective. You lie when the payoff justifies the work. The system survives because most content is still regular stuff. People sharing their lives. Creators doing real work.

Sora removes that selection. Lying is free. Truth and lies cost the same to produce. Engagement cares about neither. The algorithm picks based on one thing: what keeps you scrolling?

Not truth. Novelty. Spectacle. Uncanniness. Deepfakes of celebrities doing weird things beat someone filming their actual day.

The system must fill the feed with fabrication. Not because creators are evil. The incentives make fabrication cheaper than reality.

What This Looks Like

Echo chambers accelerate. TikTok already concentrates algorithmic curation into bubbles. Sora makes those bubbles self-reinforcing: same IP, same memes, same likenesses, generated infinitely. The machine feeding itself.

Truth becomes optional. Audiences stop sorting by "real vs. fake" and start sorting by "entertaining vs. dull." The Verge reported getting trapped in scroll loops of deepfaked celebrities and fabricated moments — even knowing they were AI. The uncanniness is the feature.

You can visually assert anything now. Any scene. Any dialogue. Any context. Short-form video already rewards punchy narratives over grounded reporting. Sora strips away the last constraint. Virality beats truth.

The Epiphany

Sora isn't breaking social media. It's making visible what was always there.

We built platforms optimized for engagement. Added algorithms to concentrate attention. Added infinite scroll and habit-forming UI. Added unlimited content generation via AI.

At each step, we told ourselves it was fine. "Engagement metrics are just incentives." "Echo chambers are just efficiency." "Disinformation is a problem we'll solve later."

Watching people trapped in loops of fabricated celebrity cameos ends that pretense. Friction is gone. Lying costs nothing. Engagement doesn't care about truth. The system fills itself with slop.

That's the machine working exactly as designed.

What Friction Did For Us

Friction was a natural check. Video production was slow. Editing took time. Deepfakes required skill. There was a price for lying on camera. Most people paid it in truth instead.

Now there is no price. Lying is as effortless as telling the truth. The system was designed assuming some friction. Some cost to fabrication. Some incentive to be selective about deception.

Sora removes that assumption.

Infinite scroll of fabricated content, algorithmically sorted for engagement, presented in a UI designed for habit formation, watched by people who stopped caring if it's real.

The machine didn't break. It just stopped pretending.

Related posts:

• AI The New Backdoor Layoff - How companies use AI as cover for not hiring
• On Technological Stratification - How AI widens inequality and access gaps
• Perplexity replaces Google Search and Apple News for me - How AI is changing information consumption
• Google AI Overviews are cutting web traffic in half - The impact of AI on traditional web patterns

The Tiny Recursive Model (TRM) doesn't solve problems in one pass. It loops: draft an answer, check the logic, rewrite, repeat up to 16 times. An internal "scratchpad" critiques its reasoning, catching mistakes before they compound.

On the ARC-AGI benchmark — abstract reasoning tests that trip up even the best LLMs — TRM scored 45% on ARC-AGI-1 and 8% on ARC-AGI-2. Better than DeepSeek-R1, o3-mini, and Gemini 2.5 Pro, all running billions of parameters. On Sudoku-Extreme with 1,000 training examples, it hit 87.4% accuracy versus its predecessor's 55%.

Alexia Jolicoeur-Martineau, the Samsung researcher behind TRM: "The notion that one must depend on extensive foundational models trained for millions of dollars by major corporations to tackle difficult tasks is misleading."

You don't write down the first answer that pops into your head when solving a hard problem. You draft something, spot the holes, rethink it, try again. TRM does this in a two-layer neural network. Traditional LLMs generate answers in a single forward pass. An early mistake spreads through the entire response.

TRM won't write your emails or debug your code. It handles structured, grid-based reasoning: Sudoku, mazes, abstract pattern recognition. For these problems, a 7-million parameter model running locally beats cloud-based giants — faster, cheaper, and private.

I've been testing Apple's Foundation Models framework. What I like most is the privacy. It runs entirely offline. Your prompts stay on your device. Apple doesn't use your data to train models.

Cloud-based LLMs log every query you send. Apple's 3-billion parameter model runs natively in iOS 26, iPadOS 26, and macOS 26. It feels like it's mine, not something I'm renting access to.

Samsung's TRM is open source under an MIT license. Apple's Foundation Models framework gives developers on-device AI with three lines of Swift code. AI doesn't have to phone home. Sometimes the best model runs quietly on your device without sending your data anywhere.

Anthropic shipped Claude Haiku 4.5. You trade deeper reasoning for speed and cost. For most tasks, that's the correct trade.

The Numbers

3.75x cheaper. Sub-200ms latency versus Sonnet's 500-800ms. That gap matters for anything that needs to feel responsive.

A small support chatbot costs $5-20/month on Haiku versus $50-150/month on Sonnet. High-volume workloads widen the gap further.

Where I Use It

I run Haiku for small refactors, code review, and debugging. It matches Sonnet 4 on most coding tasks. The speed makes it feel snappier, and for real-time pair programming or customer support it is the obvious choice. Sonnet earns its price when you need complex reasoning or nuanced writing.

January 2025 Cutoff

Established patterns and refactoring work fine, but bleeding-edge tools require extra context in your prompts.

When Cost Decides

Haiku makes LLM integration practical for projects where API costs would otherwise kill the idea. You can afford to be generous with calls. It will not impress on reasoning, but it does not need to.

Related posts:

• Claude Code's Strengths and Weaknesses in March 2025 - See how Haiku compares to other Claude tools
• GPT-4.1: SWE-bench Performance - Compare Haiku to GPT-4.1 on coding benchmarks
• The True Cost of AI - Understand AI pricing across different models and services

You describe placement intent—"put this button top-right"—and SwiftUI interprets based on device, orientation, and available space. Sometimes it honors your intent. Sometimes it moves items to overflow menus. Sometimes it hides them entirely.

ToolbarItem Basics

SwiftUI's toolbar API uses a toolbar modifier with ToolbarItem elements. Each needs placement (where you want it) and content (what to show). Apple's ToolbarItemPlacement documentation lists placements like .topBarLeading, .topBarTrailing, .bottomBar, .status, .title, and .subtitle.

The simplest example:

import SwiftUI

struct BasicToolbarDemo: View {
    var body: some View {
        NavigationStack {
            Text("Content goes here")
                .navigationTitle("Basic Toolbar")
                .toolbar {
                    // Single toolbar item in top-right
                    ToolbarItem(placement: .topBarTrailing) {
                        Button { } label: {
                            Image(systemName: "plus")
                        }
                    }
                }
        }
    }
}

Key points:

• Must be inside NavigationStack - Toolbars attach to navigation bars
• placement parameter - Tells SwiftUI where you want it
• Content closure - What to display (usually a Button)

Common placements:

• .topBarLeading - Top-left corner (menu, back button)
• .topBarTrailing - Top-right corner (add, edit, share)
• .bottomBar - Bottom toolbar area
• .status - Centered in bottom bar (non-interactive status text)
• .title - Custom title view in navigation bar
• .subtitle - Subtitle text below title

The Four Corners Pattern

I wanted toolbar items in all four screen corners. Common in file browsers (Files app), editing apps (Pages, TextEdit), and photo apps (Photos). Here's the simplest version:

struct FourCornersDemo: View {
    var body: some View {
        NavigationStack {
            // DemoData.generatePeople() creates 50 placeholder names
            List(DemoData.generatePeople(), id: \.self) { person in
                Text(person)
            }
            .navigationTitle("Four Corners")
            .toolbar {
                ToolbarItem(placement: .topBarLeading) {
                    Button { } label: {
                        Image(systemName: "line.3.horizontal")
                    }
                }

                ToolbarItem(placement: .topBarTrailing) {
                    Button { } label: {
                        Image(systemName: "plus")
                    }
                }

                ToolbarItem(placement: .bottomBar) {
                    Button { } label: {
                        Label("Back", systemImage: "chevron.backward")
                    }
                }

                ToolbarItem(placement: .bottomBar) {
                    Spacer()
                }

                ToolbarItem(placement: .bottomBar) {
                    Button { } label: {
                        Label("Next", systemImage: "chevron.forward")
                    }
                }
            }
        }
    }
}

Five ToolbarItems: top-left, top-right, bottom-left, a Spacer in the middle, and bottom-right. The Spacer pushes the bottom buttons to the edges.

On iPhone, all four buttons appear where specified. On iPad, same buttons with more spacing. On macOS, the top buttons appear in the window toolbar, but bottom buttons disappear—macOS windows don't have bottom toolbars, so SwiftUI hides them.

Kitchen Sink Placements

SwiftUI has more toolbar placements beyond the four corners. Here's a kitchen sink example showing .title, .subtitle, and .status:

struct ToolbarKitchenSink: View {
    @State private var selectedCount = 3
    private let people = DemoData.generatePeople()

    var body: some View {
        NavigationStack {
            List(people, id: \.self) { person in
                Text(person)
            }
            .navigationTitle("Kitchen Sink")
            .toolbar {
                ToolbarItem(placement: .topBarLeading) {
                    Button { } label: {
                        Image(systemName: "line.3.horizontal")
                    }
                }

                ToolbarItem(placement: .topBarTrailing) {
                    Button { } label: {
                        Image(systemName: "plus")
                    }
                }

                ToolbarItem(placement: .title) {
                    HStack(spacing: 6) {
                        Image(systemName: "tray.fill")
                        Text("Inbox")
                    }
                }

                ToolbarItem(placement: .subtitle) {
                    Text("\(selectedCount) of \(people.count) people selected")
                        .foregroundStyle(.secondary)
                }

                ToolbarItem(placement: .status) {
                    Button { } label: {
                        Text("\(selectedCount) of \(people.count) people selected")
                    }
                    .controlSize(.large)
                }

                ToolbarItem(placement: .bottomBar) {
                    Button { } label: {
                        Label("Back", systemImage: "chevron.backward")
                    }
                }

                ToolbarItem(placement: .bottomBar) {
                    Button { } label: {
                        Label("Next", systemImage: "chevron.forward")
                    }
                }
            }
        }
    }
}

• .title - Custom title view in navigation bar (replaces standard title)
• .subtitle - Subtitle text below title
• .status - Centered in bottom bar (can be button or text)

Portrait-Only iPhone Apps Don't Need This

Here's my issue: if you're building a portrait-only iPhone app, SwiftUI's cross-platform adaptation solves a problem you don't have.

I want fixed button placement on a simple iPhone app. SwiftUI's toolbar API assumes universal apps that might run on iPad or macOS, rotate to landscape, and need adaptive layouts.

Apple's documentation doesn't make the constraints clear upfront. You discover them by testing. The docs say:

"In compact horizontal size classes, the system limits both the leading and trailing positions of the navigation bar to a single item each."

Translation: iPhone portrait gets one button in .topBarLeading and one button in .topBarTrailing. Want more? They go to overflow menus automatically.

Automatic Overflow with Too Many Items

What happens when you add 10 toolbar buttons? SwiftUI creates an overflow menu. I built a demo with a star button (left) and 10 action icons (right):

struct TenItemsTopTrailing: View {
    @State private var isStarred = false
    @State private var showAlert = false
    @State private var alertMessage = ""

    private let trailingIcons = [
        "pencil", "trash", "square.and.arrow.up", "doc.on.doc",
        "folder", "tag", "link", "clock", "bell", "flag"
    ]

    var body: some View {
        NavigationStack {
            List(DemoData.generatePeople(), id: \.self) { person in
                Text(person)
            }
            .navigationTitle("Lots of Actions")
            .alert(alertMessage, isPresented: $showAlert) {
                Button("OK") { }
            }
            .toolbar {
                ToolbarItem(placement: .topBarLeading) {
                    Button {
                        isStarred.toggle()
                        alertMessage = isStarred ? "Starred" : "Unstarred"
                        showAlert = true
                    } label: {
                        Image(systemName: isStarred ? "star.fill" : "star")
                            .foregroundColor(isStarred ? .yellow : .primary)
                    }
                }

                ToolbarItemGroup(placement: .topBarTrailing) {
                    ForEach(trailingIcons, id: \.self) { icon in
                        Button {
                            alertMessage = "\(icon.capitalized) clicked"
                            showAlert = true
                        } label: {
                            Image(systemName: icon)
                        }
                    }
                }
            }
        }
    }
}

I didn't write code to create the overflow menu. SwiftUI saw 10 items, measured available space, and moved extras into a "..." button. You get no control over this. No API to customize it, no way to prioritize which items stay visible, no option to change the overflow UI.

On iPhone, 4-5 icons show before overflow. On iPad, 5-7. On macOS, all 10 might fit if the window is wide enough. SwiftUI picks which items get hidden based on its own logic. Want to keep the most important actions visible? You can't specify that.

Apple's Vision vs Developer Needs

Apple wants universal apps running on iPhone, iPad, macOS, and visionOS with consistent HIG adherence and automatic adaptation.

Many developers want a simple iPhone portrait app with exact button placement, predictable behavior, and no hidden overflow menus.

These goals conflict. SwiftUI's toolbar API optimizes for universal apps that adapt everywhere. For simple iPhone apps, it creates friction. The framework makes decisions for you, and you can't override them.

Related posts:

• Understanding SwiftUI's TabView - Learn how tab bars work with the iOS 26 Tab API
• SwiftUI Liquid Glass and Accessibility - Make your toolbars accessible with proper VoiceOver support

API Redesign

iOS 26 replaced .tabItem modifiers with a dedicated Tab component. The old API required wrapping labels in closures. The new syntax consolidates everything:

Before:

Text("Home").tabItem { Label("Home", systemImage: "house") }

After:

Tab("Home", systemImage: "house") { Text("Home") }

The result is less nesting and clearer intent.

Example Setup

For visual consistency across examples, I extracted styling into TabViewHelpers.swift:

// TabViewHelpers.swift - shared across all examples
extension View {
    var rainbowGradient: some View {
        LinearGradient(
            colors: [.red, .orange, .yellow, .green, .blue, .purple],
            startPoint: .topLeading,
            endPoint: .bottomTrailing
        )
        .ignoresSafeArea()
    }

    func tabContent(_ text: String) -> some View {
        Text(text)
            .font(.system(size: 40, weight: .bold))
            .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .bottom)
            .padding(.bottom, 100)
            .background(rainbowGradient)
    }
}

This keeps examples focused on TabView structure. The rainbow gradient makes liquid glass effects more visible in videos.

Basic Tab Example

A standard TabView with three tabs:

TabView {
    Tab("Home", systemImage: "house") {
        tabContent("Home")
    }
    Tab("Automation", systemImage: "checkmark.circle") {
        tabContent("Automation")
    }
    Tab("Discover", systemImage: "star") {
        tabContent("Discover")
    }
}

Each Tab needs a label, icon, and content. TabView handles state persistence, animations, and accessibility automatically.

iOS 26 introduced "liquid-glass"—a frosted tab bar that adapts to content behind it. The effect is automatic. As you switch tabs, the backdrop blur adjusts dynamically. No configuration is needed.

Notice how the gradient shifts through the frosted tab bar as you navigate:

Search Role

Tab(role: .search) is special. The search role automatically provides the magnifying glass icon and semantic context to iOS:

TabView {
    Tab("Issues", systemImage: "newspaper") {
        tabContent("Issues")
    }
    Tab("About", systemImage: "info.circle") {
        tabContent("About")
    }
    Tab(role: .search) {
        tabContent("Search")
    }
}

The magnifying glass is locked in—no customization. This ensures consistent search recognition across iOS. Apps like App Store and Music follow this pattern.

Badges

.badge() adds notification bubbles to tabs:

struct BadgedTabView: View {
    @State private var messageCount = 3
    @State private var notificationCount = 7

    var body: some View {
        VStack {
            // Control buttons
            HStack {
                Button("Add Message") {
                    messageCount += 1
                }
                Button("Clear Notifications") {
                    notificationCount = 0
                }
            }
            .padding()

            TabView {
                Tab("Messages", systemImage: "message") {
                    tabContent("Messages (\(messageCount))")
                }
                .badge(messageCount)

                Tab("Notifications", systemImage: "bell") {
                    tabContent("Notifications (\(notificationCount))")
                }
                .badge(notificationCount)

                Tab("Profile", systemImage: "person") {
                    tabContent("Profile")
                }
            }
        }
    }
}

Badges hide at 0, and iOS handles positioning and styling. Messages, Mail, and Phone use this pattern for unread counts.

What You Can't Customize

Apple enforces conventions to maintain iOS consistency.

Search Is Locked Down

Tab(role: .search) cannot be repurposed. You can't replace it with an "Add" button. The icon is fixed, only one search role is allowed per TabView, and iOS determines its position.

Apple's reasoning: search should be instantly recognizable. The magnifying glass is universal.

Other Restrictions

More than 5 tabs: iOS adds a "More" tab automatically. You can't customize or remove it. The system decides which tabs get hidden.

iPad layout: iOS 26 forces tab bars near the top. The old bottom position is gone. Sidebar toggle is system-controlled.

Tab bar appearance: Limited color, blur, and spacing customization. Liquid glass is the default—you can't disable it or swap in custom materials.

Tab ordering: Users can reorder in the "More" menu (requires customizationID). Sidebar doesn't always sync with TabView order.

Most apps stay within these constraints. The defaults cover common cases and maintain iOS consistency.

Design Guidelines

Apple's recommendations:

Structure

• 3-5 tabs on iPhone
• Clear SF Symbol icons
• Concise titles (1-2 words)
• Sparse badging (only for things that need attention)

Hierarchy

• Primary actions in main tabs
• Secondary content in TabSections (iOS 26+)
• Search always uses Tab(role: .search)

Responsive

• Size class adaptation for different screens
• .sidebarAdaptable for iPad
• 44pt minimum touch targets

Related posts:

• SwiftUI's Toolbar placement API - Learn how to customize toolbar buttons and bottom bars in SwiftUI
• SwiftUI Liquid Glass and Accessibility - Make your tab views accessible with Reduce Motion and VoiceOver support

VoiceOver Labels, Hints, and Grouping

VoiceOver reads UI elements aloud for blind and low-vision users. SwiftUI provides default labels for text and images, but custom views need explicit accessibility annotations. Without proper labels, VoiceOver reads raw view hierarchies ("Image, Text, Text, Text") instead of meaningful descriptions.

Combining elements: Group related views so VoiceOver reads them as one logical element:

HStack {
    Image(systemName: "photo")
        .resizable()
        .frame(width: 60, height: 60)

    VStack(alignment: .leading) {
        Text(item.name)
            .font(.headline)
        Text("\(item.quantity) items")
            .font(.subheadline)
        if let notes = item.notes {
            Text(notes)
                .font(.caption)
        }
    }
}
.accessibilityElement(children: .combine)
.accessibilityLabel("\(item.name), \(item.quantity) items")
.accessibilityHint(item.notes ?? "No notes")
.accessibilityValue(item.condition?.rawValue ?? "")

.accessibilityElement(children: .combine) merges child elements into one. .accessibilityLabel() is the primary text VoiceOver reads immediately—keep it short. .accessibilityHint() is secondary context read after a delay. .accessibilityValue() holds current state.

Stat Card with Icon:

VStack {
    Image(systemName: "star.fill")
        .font(.title)
    Text("\(count)")
        .font(.title2)
        .fontWeight(.bold)
    Text(label)
        .font(.caption)
}
.accessibilityElement(children: .combine)
.accessibilityLabel("\(label): \(count)")

Without .accessibilityElement(children: .combine), VoiceOver reads "Star, 42, Favorites". With grouping: "Favorites: 42".

iOS 26 Liquid Glass Defaults

.glassEffect() automatically respects Reduce Motion and Reduce Transparency system settings. Liquid Glass materials adapt opacity and blur intensity based on accessibility preferences. GlassEffectContainer groups glass views for shared rendering and better performance. .interactive() makes glass respond to touch and focus with subtle lighting—disabled when Reduce Motion is on.

Apply .glassEffect() to floating elements (toolbars, tab bars, cards). Avoid placing solid fills behind glass views. Don't combine .glassEffect() with manual .blur() or .opacity() modifiers. Use GlassEffectContainer when multiple glass elements share the same space.

Testing Your Implementation

Reduce Motion: Settings -> Accessibility -> Motion -> Reduce Motion -> ON. Verify .glassEffect() is replaced with static materials. Check that parallax and refraction animations are disabled.

Reduce Transparency: Settings -> Accessibility -> Display & Text Size -> Reduce Transparency -> ON. Glass elements should become more opaque and frosty. Content behind glass should be more obscured for better contrast.

Dynamic Type: Settings -> Accessibility -> Display & Text Size -> Larger Text. Drag the slider to maximum. Check that text on glass backgrounds stays readable and layouts don't break.

VoiceOver: Settings -> Accessibility -> VoiceOver -> Enable. Navigate through glass UI elements. Listen for meaningful descriptions, not just "Glass effect, Button".

Combined testing: Enable Reduce Motion + Reduce Transparency + Dark Mode together for the most accessibility-friendly configuration.

What I Learned

Accessibility isn't an afterthought in Liquid Glass—Apple baked it in from the start. But you have to respect it in custom implementations.

The @Environment(\.accessibilityReduceMotion) pattern is straightforward. When Reduce Motion is on, I replace .glassEffect() with .ultraThinMaterial for a static blur without morphing animations. VoiceOver grouping with .accessibilityElement(children: .combine) solved screen readers treating each glass element separately. Dynamic Type worked automatically once I switched from fixed font sizes to SwiftUI's built-in text styles.

Liquid Glass looks incredible but is visually intense. Some users find it distracting or hard to read. Testing with Reduce Motion + Reduce Transparency showed me how much the system adapts—glass becomes more opaque, animations stop, and the UI feels closer to iOS 25's flat design.

What I'd do differently next time: check accessibilityReduceMotion and fall back to .ultraThinMaterial instead of .glassEffect(), use SwiftUI text styles with dynamicTypeSize ranges for text on glass backgrounds, group compound glass views with accessibilityElement(children: .combine), test with both Reduce Motion and Reduce Transparency enabled, and never manually combine .glassEffect() with .blur() or .opacity().

The hard part is not the API itself but remembering to test with those settings enabled.

Related posts:

• Part 1: Reduce Motion and Dynamic Type - Foundation accessibility techniques for Liquid Glass
• Understanding SwiftUI's TabView - Apply these accessibility patterns to tab views
• SwiftUI Bottom Toolbar and Placement API - Make toolbars accessible with proper placement

What Liquid Glass Does

iOS 26 introduces Liquid Glass, Apple's unified design language influenced by visionOS. It replaces iOS 7's flat design with rounded, translucent elements that refract, blur, and respond to motion, content, and user input.

The visual properties: environmental refraction (refracts and reflects content behind it), dynamic light reflection (responds to light sources), responsive fluidity (morphs based on size and interaction), and adaptive blur (adapts to background content). Larger glass elements simulate thicker glass with deeper shadows and more pronounced lensing.

iOS 26's Liquid Glass blur, refraction, and parallax effects break accessibility when unhandled. Three areas matter: Reduce Motion (disable or simplify animations), Reduce Transparency (make glass less translucent for better contrast), and VoiceOver (give glass-styled components proper labels).

Apple built accessibility into Liquid Glass directly. Reduce Motion decreases glass effect intensity, disables elastic properties, and removes parallax and refraction animations. Reduce Transparency makes Liquid Glass "frostier" and more opaque, obscuring more content behind glass to improve contrast. Combined settings (Reduce Transparency + Reduce Motion + Dark Mode) deliver the best visibility, performance, and battery life. Liquid Glass then behaves more like iOS 25's flat design.

Disable Liquid Glass Animations with Reduce Motion

When users enable Reduce Motion, disable or simplify blur animations, parallax, refraction, and elastic morphing. Liquid Glass's dynamic refraction and morphing animations can trigger motion sickness in users with vestibular disorders.

Implementation:

struct AnimatedBadge: View {
    @Environment(\.accessibilityReduceMotion) private var reduceMotion
    @State private var animate = false

    var body: some View {
        let animation = reduceMotion
            ? .none
            : .easeInOut(duration: 0.8).repeatForever(autoreverses: true)

        Circle()
            .fill(Color.blue)
            .frame(width: 12, height: 12)
            .scaleEffect(animate ? 1.2 : 1.0)
            .onAppear {
                guard !reduceMotion else { return }
                withAnimation(animation) {
                    animate = true
                }
            }
    }
}

The pattern: read @Environment(\.accessibilityReduceMotion), set animation to .none when enabled, and early return in onAppear to prevent state changes.

Liquid Glass with Reduce Motion:

struct GlassCard: View {
    @Environment(\.accessibilityReduceMotion) private var reduceMotion

    var body: some View {
        VStack {
            Text("Content")
        }
        .padding()
        .background {
            if reduceMotion {
                // Fallback: simple blur without morphing
                RoundedRectangle(cornerRadius: 16)
                    .fill(.ultraThinMaterial)
            } else {
                // Full Liquid Glass effect
                RoundedRectangle(cornerRadius: 16)
                    .glassEffect(.regular.interactive())
            }
        }
    }
}

When Reduce Motion is on, replace .glassEffect() with .ultraThinMaterial or .regularMaterial. You keep the blur without the morphing and refraction.

Scalable Text with Dynamic Type

Dynamic Type lets users adjust text size system-wide. SwiftUI text styles (.headline, .body, .caption) scale automatically, but you still need to handle layout constraints. Users with visual impairments rely on larger sizes up to accessibility5.

Implementation:

Text(item.name)
    .font(.headline)
    .fontWeight(.semibold)
    .lineLimit(2)
    .multilineTextAlignment(.leading)
    .dynamicTypeSize(...DynamicTypeSize.accessibility5)

Use SwiftUI's built-in text styles instead of fixed point sizes. The range operator ...DynamicTypeSize.accessibility5 caps the maximum text size. Allow at least 2 lines to prevent truncation at larger sizes. Test with Settings -> Accessibility -> Display & Text Size -> Larger Text.

Capping Dynamic Type: You can cap at a maximum size when unlimited scaling breaks layouts:

Text("Fixed Layout Text")
    .font(.body)
    .dynamicTypeSize(.medium...DynamicTypeSize.xxxLarge)

This allows scaling up to xxxLarge but prevents accessibility sizes that might break the design.

Continue to Part 2 for VoiceOver support and testing strategies.

Related posts:

• Understanding SwiftUI's TabView - See how to implement accessible tab bars with Liquid Glass
• SwiftUI Bottom Toolbar and Placement API - Learn toolbar placement patterns that work with accessibility settings

A Worker catches requests to example.com/tag/_ and sends them to example.com/tags/_, keeping the method, headers, and query strings intact. No changes to the main app.

People bookmark URLs, and when you rename a path, their links break. This Worker fixes that problem.

Worker script

export default {
  async fetch(request) {
    const url = new URL(request.url);

    // Only handle /tag/*, leave /tags/* and everything else alone
    if (url.pathname.startsWith("/tag/")) {
      url.pathname = url.pathname.replace(/^\/tag\//, "/tags/");
      return fetch(url.toString(), request);
    }

    return fetch(request);
  },
};

This uses modules style with a basic path check, where the regex swaps /tag/ for /tags/ before passing the request along.

Create the Worker

In the Cloudflare dashboard, go to Workers & Pages -> Create application -> Create Worker. Open the Worker, pick Edit code, paste the script, then Save and deploy.

Attach a route

In the Worker, go to Settings -> Domains & Routes -> Add -> Route. Pick the zone example.com and set the route to example.com/tag/_ so it only rewrites under /tag/_.

DNS and proxy prerequisites

Patterns and precedence

Route patterns work with wildcards at the start of hostnames or end of paths, like example.com/tag/. Putting wildcards mid-path (example.com//tag/*) is invalid. Specific routes win over general ones.

Optional: broader coverage

Set the route to example.com/_ and keep the code check so it only rewrites /tag/_. Other paths pass through, and the Worker runs more often but you manage fewer routes.

Quick edits in the dashboard

For small tweaks, use the dashboard's Quick Edit (VS Code in the browser) to change code, preview, and redeploy without local tools. Save Wrangler for CI/CD or bigger projects.

Verification

Requests to https://example.com/tag/some-topic should show content from https://example.com/tags/some-topic, with query strings intact and caching handled upstream.

What It Costs

Static hosting is free on both platforms. Page count does not matter.

Pages charges for builds:

• Free: 500 builds/month
• Pro: $20/month for 5,000 builds

Workers charges for server-side execution:

• Free: 100,000 requests/day
• Paid: $5/month for 10M requests

For a static blog: both cost $0/month unless you exceed 500 builds or add dynamic features. I have been on the free tier for years.

One Line to Migrate

Pages already runs on Workers infrastructure. Change one property in your config:

- pages_build_output_dir: "./dist"
+ assets:
+   directory: "./dist"

Then redeploy the site.

Full steps:

1. Install Wrangler: bun install -D wrangler@latest
2. Update your config (see above)
3. Configure API token permissions (see below)
4. Deploy: bunx wrangler deploy

The official migration guide covers complex setups with Functions. Most static sites will not need it.

API Token Permissions

If you deploy with an API token (recommended for CI/CD), you need these permissions:

Required:

• Account -> Cloudflare Pages -> Edit (for Pages deployments)
• Account -> Workers Scripts -> Edit (for Workers deployments)
• Account -> Account Settings -> Read (for account info)

Optional but recommended:

• Zone -> Workers Routes -> Edit (if using custom domains with your zone)

Setting up the token:

1. Go to Cloudflare Dashboard -> API Tokens
2. Click "Create Token"
3. Add the permissions above
4. For Zone permissions, select "Specific zone" and choose your domain (e.g., kahwee.com)
5. Save the token and set it as your CLOUDFLARE_API_TOKEN environment variable

What Workers Adds

Node.js API compatibility: crypto, tls, net, dns modules. Better support for frameworks expecting Node APIs.

Edge compute features:

• Durable Objects (real-time collaboration, WebSocket state)
• Cron Triggers (scheduled tasks at the edge)
• Queue Consumers (background job processing)
• Gradual Deployments (progressive rollouts)

Observability: Workers Logs with request-level detail, Logpush for analytics pipelines, Source Maps for debugging.

Does a Blog Need This?

If you serve pre-built HTML, CSS, and JavaScript, both platforms are free and fast. The migration is trivial. What do you actually gain?

Form handling is the main reason to migrate. Contact forms, newsletter signups, comment APIs — you handle form posts without a separate backend service.

API endpoints like search, view counts, and reading time tracking. Workers builds lightweight APIs alongside your blog without a server.

Dynamic content like personalized pages, A/B testing, and geo-redirects. Useful for experimentation. Overkill for most blogs.

Skip Durable Objects unless you are building live comments or a collaborative editor. Skip Cron Triggers — most static site generators handle scheduled publishing at build time. Skip Queue Consumers entirely.

When to Migrate

Migrate if you plan to add comments, search, or dynamic features. Migrate if you want lightweight APIs for likes, subscriptions, or view counts. Migrate if you need better observability than Pages offers.

Stay on Pages if your blog is purely static and will remain so.

My Take

I migrated because I wanted newsletter signups without third-party services. The migration took 5 minutes. Most of that was waiting for deployment.

If you are just serving markdown-to-HTML, do not bother. Pages works fine for static sites. The migration is simple enough to do anytime you need Workers features.

Hardware Setup

The Connect ZWA-2 is the first Z-Wave product in Home Assistant's Connect line. The "2" refers to the second-generation technology platform, not a previous ZWA-1 model.

Prerequisites: Ugreen NAS with Docker installed, SSH access to your NAS, Home Assistant Connect ZWA-2 USB stick, and a USB extension cable (recommended for better signal).

Connect the hardware: Plug the ZWA-2 into the NAS. A USB extension cable helps — it positions the stick away from interference.

Identify the device path: SSH into your NAS and locate your Z-Wave device with ls /dev/serial/by-id/. You should see something like usb-Nabu_Casa_ZWA-XXXXXXXXXX-if00. This is your device identifier.

Create persistent storage: Run mkdir -p /volume1/docker/zwave-store. This directory stores your Z-Wave network config, device database, and security keys. Without it, you lose everything on container restart.

Run the Docker container:

docker run --rm -it \
  -p 8091:8091 -p 3000:3000 \
  --device=/dev/serial/by-id/usb-Nabu_Casa_ZWA-XXXXXXXXXX-if00:/dev/zwave \
  -v /volume1/docker/zwave-store:/usr/src/app/store \
  zwavejs/zwave-js-ui:latest

Port 8091 serves the Z-Wave JS UI web interface. Port 3000 runs the WebSocket server for Home Assistant. The device mapping connects the physical USB to /dev/zwave inside the container.

Software Configuration

Access the web interface: Open http://<YOUR_NAS_IP>:8091/ in your browser. In Settings → Z-Wave, set Serial Port to /dev/zwave and click Save.

Set RF region: Go to Settings → Z-Wave → RF Manager and set RF Region to your location (USA, EU, ANZ, etc.). Wrong region means communication failures and potential regulatory violations.

Connect to Home Assistant: In Z-Wave JS UI, go to Settings → Home Assistant and enable WS Server. The WebSocket URL is ws://<YOUR_NAS_IP>:3000. In Home Assistant, go to Settings → Devices & Services, add the Z-Wave JS integration, and enter that URL.

Pair Z-Wave devices: In Z-Wave JS UI, click Control Panel → Add Node (or Include), then follow your device's pairing instructions (usually triple-press a button). Paired devices appear in Home Assistant automatically.

Troubleshooting & Maintenance

Backup strategy: Back up security keys (Settings → Z-Wave → Security Keys, export as JSON), the entire /volume1/docker/zwave-store directory, and your Home Assistant config. Automate backups with: tar -czf zwave-backup-$(date +%Y%m%d).tar.gz /volume1/docker/zwave-store

Common issues:

Device not found: Check if USB device is visible with ls -la /dev/serial/by-id/ and review kernel logs with dmesg | tail -n 50.

Permission denied: The container needs access to the USB device. Ensure Docker has proper permissions or run with --privileged flag (less secure).

Controller offline: Verify serial port setting is /dev/zwave, check container logs with docker logs <container-id>, restart container, or check USB cable connection.

Home Assistant can't connect: Verify WebSocket server is enabled in Z-Wave JS UI, check firewall rules on NAS allow port 3000, confirm Home Assistant can reach NAS IP, and try ws:// instead of wss:// for local network.

Z-Wave JS UI bridges the ZWA-2 and Home Assistant via WebSocket, handling mesh network communication while Home Assistant handles automation.

Hosting & Deployment

Infrastructure

Fly.io hosts the application. It scales to zero when idle and runs database migrations during deployment.

Cloudflare handles CDN, DDoS protection, and SSL.

Neon hosts PostgreSQL with serverless auto-scaling, database branching for dev/staging, point-in-time recovery, and connection pooling.

Docker Multi-Stage Builds

The application uses multi-stage builds for optimization:

FROM node:24-alpine AS base
WORKDIR /app

FROM base AS deps
COPY package.json package-lock.json ./
RUN npm ci --only=production

FROM base AS build
COPY . .
RUN npm run build

FROM base AS runtime
COPY --from=build /app/build ./build
COPY --from=deps /app/node_modules ./node_modules
EXPOSE 3000
CMD ["npm", "start"]

Development Workflow

# Development
npm run dev        # Start development server
npm run test       # Run tests
npm run typecheck  # Type checking

# Database
npm run db:studio  # Visual database management
npm run db:seed    # Populate with sample data
npm run db:migrate # Apply schema changes

Code Quality Standards

The project uses ESLint with React and TypeScript rules, Prettier for formatting, strict TypeScript with noUncheckedIndexedAccess, Husky for git hooks, Vitest for unit tests, and Playwright for E2E testing.

Database Development with Drizzle Kit

Schema changes follow a structured approach:

# 1. Edit app/db/schema.ts
# 2. Generate migration
npm run db:generate

# 3. Apply migration
npm run db:migrate

# Development workflow
npm run db:push   # Quick schema sync (dev only)
npm run db:studio # Visual database UI
npm run db:reset  # Clean database reset

Performance

Vite delivers sub-second HMR, tree shaking, route-based code splitting, and image compression.

Drizzle ORM caches query plans with prepared statements and pools connections. Type-safe migrations prevent runtime errors.

Catalyst UI gave us high-quality components without overhead. Fly.io reduced operational complexity to near zero.

The deployment pipeline runs tests on every push, checks types, runs migrations during deploy, and rolls back on failure. React Router v7, Drizzle ORM, better-auth, and Fly.io together make a stack I'd pick again.

Tech Stack

The foundation is React Router v7 with TypeScript, PostgreSQL for data, and modern UI libraries:

Frontend: React Router v7 with React 19.1.1, TypeScript 5.9.2 for type safety

UI & Styling: Tailwind CSS v4.1.13, Catalyst UI components, Headless UI, Heroicons, Motion for animations

Backend & Data: Node.js v24+, PostgreSQL with Neon serverless, Drizzle ORM v0.44.5 for type-safe queries

Authentication: better-auth v1.3.9 with WebAuthn, OAuth, and session management. Zod v4.1.5 for validation

Dev Tools: Vite v7.1.5, ESLint, Prettier, Vitest, Playwright, Storybook

Architecture Decisions

Type-Safe Data Layer

Using Drizzle ORM provides full type safety across the entire data layer:

// Type-safe queries with full IntelliSense
const users = await db.query.users.findMany({
  where: eq(users.isActive, true),
  with: {
    profile: true,
    settings: true,
  },
});

// Prepared statements for performance
const getUserById = db
  .select()
  .from(users)
  .where(eq(users.id, sql.placeholder("id")))
  .prepare();

The database schema uses normalized tables with foreign keys, JSON columns for flexible data, and indexes on frequently queried columns.

Authentication with Multiple Methods

The authentication layer uses better-auth: email/password, WebAuthn/passkeys, OAuth, and HTTP-only cookie sessions.

export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: "pg",
  }),
  emailAndPassword: {
    enabled: true,
    requireEmailVerification: true,
  },
  socialProviders: {
    github: {
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    },
  },
  passkey: {
    enabled: true,
  },
});

API Architecture with React Router v7 Typegen

React Router v7's typegen automatically generates route-specific types based on your file structure:

import type { Route } from './+types/app.dashboard._index';

export const meta: Route.MetaFunction = () => {
  return [
    { title: 'Dashboard - My App' },
    { name: 'description', content: 'Application dashboard overview' },
  ];
};

export async function loader({ params, request }: Route.LoaderArgs) {
  const user = await requireAuth(request);
  const data = await getData(params.id);
  return { data, user };
}

export default function Component() {
  const { data, user } = useLoaderData<typeof loader>();
  return <div>...</div>;
}

Why This Stack Works

Vite gives fast HMR and automatic code splitting. Drizzle ORM handles prepared statements and connection pooling. Better-auth removes authentication boilerplate. React Router v7's typegen catches bugs at compile time instead of runtime.

TypeScript caught dozens of potential runtime errors during development. That alone justified the stack choice.

Continue to Part 2 for deployment, workflows, and performance.

Two TLS Hops, One Failure Point

When Cloudflare proxying is enabled (orange cloud), two TLS connections exist: browser to Cloudflare edge, then Cloudflare edge to Fly.io origin. Fly.io must present a valid certificate for the custom domain. If the origin cert is missing or wrong, Cloudflare cannot complete the handshake. You get 525.

The symptom: 525 SSL handshake failed only when Cloudflare proxy was enabled. With proxy off (grey cloud / DNS only), the site showed certificate mismatch errors instead.

Mental model:

Browser --TLS--> Cloudflare --TLS--> Fly.io
                      ^
            Needs valid cert at origin

If Cloudflare cannot finish that second TLS hop, you get 525.

The Fix

Clean your DNS. Remove every unrelated or legacy record for the apex and www. Delete old A, AAAA, and CNAME records not belonging to the Fly.io deployment. ACME validation and routing depend on unambiguous records.

Add correct AAAA records. Fly.io provides an IPv6 that routes to the app:

example.com          AAAA   <fly-io-ipv6-address>  (Proxied)
www.example.com      AAAA   <fly-io-ipv6-address>  (Proxied)

No A record needed if Fly.io only gave IPv6. Cloudflare terminates at edge (dual stack) then connects over IPv6 downstream.

Preserve ACME records. Leave existing _acme-challenge CNAMEs intact. These allow Let's Encrypt to validate via DNS-01.

Wait for propagation. TTL and resolver caches need a few minutes. Verify with dig from several public resolvers.

Three Things to Check

I only needed to confirm three things:

1. DNS returned just the Fly.io AAAA for apex + www
2. Fly.io marked the domain verified and showed issued certs
3. Cloudflare SSL mode was Full (Strict) with proxy on

Everything else — manual probing, deep TLS inspection — was noise once those were correct.

Why custom cert upload failed: Fly.io issues and renews its own certs via ACME. Cloudflare Origin Certificates only handle Cloudflare-to-origin trust and are not public-PKI certs. Uploading was never the path.

Common pitfalls: Stale A/AAAA/CNAME records lingering. Mixing previous host IPs with Fly.io AAAA. Using "Flexible" SSL (masks the real problem). Trying to import certificates instead of letting automation run.

Minimal checklist:

1. Add domain in Fly.io
2. Publish ONLY the Fly.io AAAA (and A if given) in Cloudflare; proxy on
3. Leave _acme-challenge CNAMEs untouched
4. Set SSL/TLS = Full (Strict)
5. Wait a few minutes; confirm Fly.io shows "Verified / Issued"

A 525 error means a Cloudflare-to-origin TLS failure, and DNS cleanliness gates cert issuance. Let Fly.io handle the issuance, because fewer DNS records mean fewer surprises.

Proxy pointed at an origin without a valid cert because of messy DNS. Clean DNS, correct AAAA only, wait for Fly.io issuance, Full (Strict). If you see 525: check DNS, then Fly.io cert status, then Cloudflare mode. Stop when all three are green.

The Step-by-Step Process

Phase 1: Dependencies and Configuration (30 minutes)

Replace all @remix-run/* packages with React Router equivalents in package.json. Change build/dev commands to use the react-router CLI. Simplify Vite configuration. Add react-router.config.ts for framework-specific settings.

Phase 2: Import Refactoring (90 minutes)

This phase ate the most time. Every file importing from @remix-run/* needed updates:

• Route files (23 files): Updated loader/action imports and useLoaderData calls
• Component files (8 files): Changed Link and Form imports
• Entry files (2 files): Updated server/client entry points
• Utility files (7 files): Modified auth and theme utilities

Start with entry points, then routes, then components. Fix TypeScript errors as they appear.

Phase 3: Configuration Fine-tuning (30 minutes)

Updated TypeScript config to use React Router types. Converted splat routes from api.auth.$.ts to api.auth.$rest.tsx. Added the react-router typegen command to dev scripts.

Typegen Changes Everything

This feature didn't exist in Remix. It's a React Router v7 innovation.

The typegen command generates a +types/<route-file>.d.ts for each route. You get automatic type inference for loader data, route-specific parameter typing, action and loader return type validation, and component prop type safety — all from your actual route implementation.

Instead of manually defining LoaderData interfaces for every route, typegen infers them from your loaders:

// New React Router v7 pattern - types inferred automatically
export async function loader({ request }: LoaderFunctionArgs) {
  // Return whatever you want, typegen handles the interface
  return { recipes: await getRecipes(), user: await getUser(request) };
}

// Component gets proper typing automatically
export default function RecipeList() {
  const { recipes, user } = useLoaderData<typeof loader>();
  // recipes and user are fully typed without manual interfaces
}

This fixes the interface drift problem. With manual interfaces, you change a loader to return additional data but forget to update the interface. TypeScript doesn't complain — it silently ignores the new properties.

useLoaderData<typeof loader> eliminates this. The type reflects your actual loader implementation. When you refactor a loader's return structure, every component using that data updates automatically.

What Happened to Remix?

Ryan Florence and Michael Jackson handed React Router v7 to an open governance committee while they focus on Remix v3. Remix v3 isn't an iteration — it's a complete rewrite with no React dependencies. They're building on a fork of Preact for "AI-first development" and "AI driven user interfaces."

React Router v7 is the successor for production React apps that want the Remix experience.

Worth the Switch?

React Router v7 is actively developed. Remix v2 is in maintenance mode. The simplified dependency tree, better TypeScript integration, and improved build system pay off immediately.

For teams on Remix v2 with future flags enabled, the migration is straightforward. AI assistance was critical for batch import updates across 40+ files. What could have been a full day of manual work became two focused sessions.

The migration runs smoothly on React Router v7 now. Same power as Remix, simpler tooling, stronger types.

Why React Router v7?

React Router v7 is Remix v3 renamed. Ryan Florence and Michael Jackson merged the projects because "Remix v2 had become such a thin wrapper around React Router that an artificial separation developed between the two projects."

The payoff is immediate. Instead of juggling @remix-run/node, @remix-run/react, @remix-run/serve, and others, everything consolidates into react-router. My dependencies dropped from 16 to 3. The react-router typegen command eliminates manual type annotations in loader functions. The Vite-based build system is cleaner than Remix's custom setup.

TypeScript Was the Hard Part

The API stayed compatible. TypeScript did not.

The git log tells the story — multiple commits dedicated to resolving type issues:

• LoaderFunctionArgs and useLoaderData typing: Every route needed manual type updates
• Route module type safety: New type patterns required learning React Router v7's approach
• Interface mismatches: Database query results needed type alignment with component expectations
• Case-sensitivity bugs: Database queries failed due to case-sensitive matching that worked in Remix

What Actually Changed

The migration touched 40 files with 327 insertions and 918 deletions — a net reduction of 591 lines. The main changes: package dependencies (replacing all @remix-run/* packages), build scripts (switched to react-router CLI), and Vite configuration.

The Vite config transformation was dramatic:

- import { vitePlugin as remix } from '@remix-run/dev';
- // Complex remix configuration with future flags
- remix({
-   future: {
-     v3_fetcherPersist: true,
-     v3_relativeSplatPath: true,
-     v3_throwAbortReason: true,
-     v3_singleFetch: true,
-     v3_lazyRouteDiscovery: true,
-   }
- })
+ import { reactRouter } from '@react-router/dev/vite';
+ // Simple, clean configuration
+ plugins: [reactRouter(), tsconfigPaths(), tailwindcss()]

Every route and component needed import updates:

- import type { LoaderFunctionArgs } from '@remix-run/node';
- import { useLoaderData } from '@remix-run/react';
+ import type { LoaderFunctionArgs } from 'react-router';
+ import { useLoaderData } from 'react-router';

Loaders, actions, and components work identically. The migration was mostly changing imports and build configuration.

The entry.server.tsx got simpler — React Router v7 removed the bot/browser request splitting logic. Bundle size dropped ~30% and build times improved with the unified package structure.

Continue to Part 2 for the detailed step-by-step migration process and React Router's typegen feature.

Three months ago, I ditched Next.js for Remix. Remix felt like regular web development without the mental overhead of React Server Components and "use client" boundaries.

I didn't expect to learn why those boundaries exist.

The "use client" Boundary I Didn't Understand

In Next.js, "use client" felt like an annoying annotation. Need a click handler? Add "use client". Want useState? Add "use client". Access localStorage? Same.

I thought it was just ceremony, but I was wrong.

That directive creates a hard boundary in your component tree. Everything above it runs on the server during rendering. Everything below it ships to the browser as JavaScript. Server and client code have different capabilities and constraints.

On the server side, you have database queries, file system access, and environment variables but no user interaction.
On the client side, you have DOM APIs, user events, and localStorage but no direct database access.

The boundary forces you to think about this split instead of accidentally mixing concerns.

The Bundle Creep Problem

I added "use client" to a layout component for a mobile menu toggle. My entire page — header, sidebar, content, footer — started shipping to the browser as JavaScript instead of rendering on the server.

Some Next.js teams ban "use client" except in specific directories. When someone needs interactivity, they create a client component in a designated place like components/client/. This prevents one directive from dragging an entire page into the client bundle.

How Remix Handles the Server/Client Split

Remix doesn't need "use client" because it enforces the boundary architecturally.

Server code lives in loader and action functions. These run on the server and can access databases, file systems, environment variables. They return plain data.

Client code lives in React components. These receive data as props from loaders and can use all browser APIs — useState, event handlers, localStorage. You can't accidentally put a database query in a component because loaders and actions are the only places with server context.

What I Actually Miss

Automatic tree shaking: Next.js strips browser-only dependencies from the server bundle when it sees a server component. In Remix, you keep server and client imports separate through discipline.

Component-level boundaries: With RSC, a server component fetches data, renders UI, and nests client components inside for interactivity. The boundary is fine-grained.

Bundle optimization: Server components don't add to your client bundle at all.

In Remix, the entire component tree ships to the client, even parts that don't need interactivity. You optimize by discipline, not by framework.

The Real Tradeoff

Next.js makes it explicit with "use client" but easy to mess up. One misplaced directive and your bundle explodes. Remix makes it implicit with loaders/actions but requires discipline. You can accidentally import server-only code in components if you're not careful.

Related posts:

• Migrating from Remix to React Router v7 - The next chapter: leaving Remix for React Router
• Building a Modern Full-Stack Web Application - Full-stack patterns with React Router v7
• When Rebuilding is Better than Refactoring - Why I rebuilt instead of refactored

Error: EMFILE: too many open files, open '/var/task/node_modules/nanostores/index.js'
at Object.openSync (node:fs:562:18)
at readFileSync (node:fs:446:35)
at getSourceSync (node:internal/modules/esm/load:66:14)
at getSource (node:internal/modules/esm/translators:68:10)
at createCJSModuleWrap (node:internal/modules/esm/translators:185:32)
at ModuleLoader.commonjsStrategy (node:internal/modules/esm/translators:275:10)
at #translate (node:internal/modules/esm/loader:534:12)
at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:581:27)
Node.js process exited with exit status: 1.

Vercel helpfully adds:

The logs above can help with debugging the issue.

That note does not help since you get no visibility into the per-process file descriptor limit.

Remix users hit this more than most. Vercel's serverless runtime is more restrictive than local dev environments, so file handle limits surface only during deployment.

What the Community Reports

Reddit threads: Recurring EMFILE on deploy, often with lucide-react and other icon sets.

GitHub issues: Remix + Vite + large icon libraries (phosphor, heroicons, lucide) trigger failures. Replacing barrel imports with direct paths reduces frequency.

Consensus: This is a platform constraint. Local dev rarely reproduces it. Import patterns influence open-file churn.

The community workarounds:

• Optimizing build-time concurrency
• Refactoring dynamic imports from icon libraries
• Updating dependencies and build tooling
• Switching from barrel to direct imports

These are mitigations, not fixes. They trade code clarity for staying within an unknown cap.

Routing Convention Collision

Remix uses parentheses in filenames for layout routes — like app/routes/(dashboard).profile.tsx to create nested layouts without affecting the URL structure.

Vercel reserves parentheses for its own routing logic. Deploy a Remix app with parenthesized route files and the build process throws errors until you rename them. Your intended routing structure breaks.

Why this happens: Vercel generates serverless functions from your filesystem structure. Each route file becomes a separate endpoint. The platform reserves [] for dynamic segments and () for route groups. Remix uses parentheses for layout composition, not URL generation. The two conventions collide.

The workaround tax: You refactor route organization to avoid parentheses. This means losing the clean layout composition that makes Remix routing elegant. Instead of (dashboard) layouts, you use nested folder structures that don't map as cleanly to your component hierarchy.

So what next?

I am considering Fly.io as an alternative, so stay tuned.

Pew Research Center data, reported by Ars Technica, shows Google's AI Overviews are halving website traffic. When AI-generated summaries appear at the top of search results, click-through rates drop from 15% to 8%.

Only 1% of users click on sources cited within the AI Overviews. Wikipedia, YouTube, and Reddit are the most frequently referenced. About 1 in 5 Google searches now display these AI Overviews, especially for longer, question-based queries.

Google claims AI features drive engagement and create new opportunities for websites. The data says the opposite. Users read the AI summary and stop searching. They leave with whatever the model gave them — including errors, since generative AI still hallucinates.

I Stopped Clicking Too

I use Dia, a browser with a built-in LLM, and I barely touch Google anymore. Information gets synthesized directly, and I rarely visit the underlying websites.

Getting contextualized answers without clicking through multiple sites changed how I consume information entirely. Are we watching the "dead internet theory" arrive in practice? When AI systems synthesize and present information without sending users to original sources, the web's click-through economy breaks down.

From Piracy to Purchase

Anthropic's data collection history tells the whole story. Founded by ex-OpenAI researchers in February 2021, the company started with pirated content.

Co-founder Ben Mann downloaded Books3 in early 2021 — 196,640 pirated books. By June 2021, he had downloaded at least five million books from Library Genesis. In July 2022, Anthropic added two million more from the Pirate Library Mirror. All of these sources were known to contain unauthorized copies.

Then Anthropic changed course entirely. In February 2024, they hired Tom Turvey, former head of partnerships for Google's book-scanning project. His mission: obtain "all the books in the world" while avoiding "legal/practice/business slog."

Turvey's team spent millions buying print books, often used. They stripped bindings, cut pages to size, scanned them into PDFs, and discarded the physical copies.

The Ruling

Judge Alsup's 32-page decision draws lines that will define AI copyright law.

Fair Use

AI Training: The court called training LLMs on copyrighted books "spectacularly transformative." The judge compared it to how humans learn from reading — forcing people to pay "each time they read, each time they recall from memory, each time they later draw upon it when writing new things" would be unthinkable.

Purchased-and-Scanned Books: Converting bought print books to digital for internal use is fair use, though on narrower grounds. The court treated it as format shifting.

Not Fair Use

Pirated Central Library: Maintaining a permanent digital library of millions of pirated books is not fair use. The court stressed that Anthropic kept pirated copies even after deciding not to use them for training.

What AI Companies Should Take Away

• Training on copyrighted material can be fair use when the process is transformative and doesn't produce infringing outputs
• Legitimate purchase and digitization for internal AI training is likely protected
• No special carveout for AI: The court stated plainly, "There is no carveout from the Copyright Act for AI companies"
• Piracy isn't excused by downstream fair use
• Intent matters: The court weighed whether companies actively sought pirated content

What Happens Next

Anthropic won on the training question but still faces a jury trial over damages for their pirated book library. Statutory damages for willful infringement could be steep.

OpenAI, Meta, and others used similar datasets — Books3 was part of Meta's LLaMA training data. They are watching this ruling closely.

Unanswered Questions

• What counts as "transformative" use across different AI contexts?
• How does fair use apply to images, videos, or code?
• What licensing models emerge to serve both creators and AI companies?

Training on copyrighted content can be fair use, but building pirate libraries is not. The smartest approach is what Anthropic eventually adopted: invest in legitimate content acquisition, even when it is expensive.

The Math Has Changed

UI development costs less than it did five years ago. Better tooling, mature component libraries, and improved CSS make starting fresh viable more often.

Much of our codebase predates TypeScript. Some components still use Flow annotations. When facing large changes, scaffolding new components with current patterns beats incrementally modernizing legacy code.

Legacy code carries hidden costs: outdated dependencies, deprecated patterns, assumptions that no longer hold. Starting fresh means applying lessons learned without fighting existing architecture.

Tooling Now

Cursor replaced VS Code as my default IDE. The AI integration feels natural — contextually aware tab completion that flows with development rather than interrupting it.

I tried Warp.dev. The interface felt clunky compared to traditional terminal environments. The promise is there, but the execution is not ready yet.

React's ecosystem has matured. TanStack Query solves problems we used to handle with complex custom implementations. These improvements make rebuilding cheaper than it used to be.

When to Rebuild

The same tools that speed up development — AI assistance, improved frameworks, streamlined deployment — also compress time for documentation and reflection. Capture insights during development, not afterward.

The New Playbook

Traditional layoff announcements tank stock prices, attract negative press, and crush morale. Companies learned this during the 2022-2023 tech downturn. Even mentioning workforce reductions triggered immediate market reactions. Many of these companies had overhired during 2021-2022, adding thousands of employees on pandemic-driven growth assumptions that collapsed.

The new approach skips the announcement. Instead of disclosing job cuts, companies highlight AI investments and productivity improvements. The message shifts from "we're laying off 2,000 people" to "our AI initiatives increased efficiency by 40%." There is no mention of overhiring — just technological evolution. The outcome is the same, but the optics are better.

The numbers game: A traditional layoff announcement ("We're reducing headcount by 15%") drops stock 8-12%. An AI efficiency narrative ("AI has improved productivity, reducing our hiring needs") lifts stock 5-8%. The market rewards the second framing. The underlying economic impact is identical.

How it sounds in practice: Earnings calls now feature "AI-enabled workforce optimization" instead of restructuring. The phrases have evolved: "Optimizing team structures through AI." "Reducing hiring needs through automation gains." "AI-driven efficiency improvements cutting operational costs." Each phrase signals reduced labor costs to investors without triggering a negative market response.

The competitive equilibrium problem: Companies benchmark their workforce against competitors. If your competitor has 5,000 R&D engineers, you need roughly the same to stay competitive. This creates an equilibrium where companies match hiring patterns. You can't announce "we're cutting engineering by 30%" without signaling weakness.

The AI efficiency story solves this. Instead of "we're falling behind in the talent war," companies claim "we're ahead in the efficiency war." The message: "Our 700 engineers with AI outperform competitor X's 1,000 engineers." Workforce reduction becomes competitive advantage.

When multiple companies in an industry adopt AI efficiency messaging simultaneously, it gives everyone permission to shrink teams. The entire industry can agree that "AI changes the game" instead of one company unilaterally disarming. This explains why AI efficiency announcements cluster within industries. Once one major player announces AI-driven workforce optimization, competitors follow to avoid looking behind.

Corporate Case Studies

IBM - The Pioneer: IBM CEO Arvind Krishna made headlines in May 2023 when he paused hiring for roles that could be replaced by AI. He framed it as efficiency, not layoffs. Roughly 7,800 jobs would be "replaced by AI and automation over five years." His words: "I could easily see 30% of that getting replaced by AI and automation." No mass layoff announcement. No stock price drop.

Meta - "Year of Efficiency": Meta overhired during the pandemic boom, then found itself overstaffed when growth assumptions collapsed. Zuckerberg reframed 2023 as the "Year of Efficiency", emphasizing AI automation that would reduce future hiring needs. The dual messaging was strategic: address immediate overstaffing with layoffs while setting expectations for permanently reduced headcount through AI. The market rewarded technological transformation over admission of hiring errors.

Google - AI-First Reorganization: Google followed the same pattern. After pandemic-era hiring ballooned its workforce, the company faced overcapacity. Following ChatGPT's launch, Google declared a "code red" and repositioned its 12,000-person reduction as an AI-first reorganization. Not a correction of overhiring. Earnings calls now emphasize AI productivity gains that justify "more disciplined" hiring practices. That's a euphemism for the lean workforce they should have maintained all along.

Microsoft - Copilot as Workforce Multiplier: Microsoft positioned its AI strategy around "human-AI collaboration" rather than replacement. Yet Copilot products let single employees do tasks that previously required multiple people. Microsoft's earnings emphasize productivity multipliers and efficiency gains while quietly reducing hiring targets across divisions using Copilot.

Why It Works

Investors hear three things: innovation leadership (the company ships cutting-edge technology), cost optimization (operating expenses drop through automation), and future readiness (the workforce is becoming more productive). The AI framing delivers all three of these signals without the layoff stigma.

The competition shifts from "who has the most talented people" to "who has the most efficient AI-human collaboration." Companies reduce headcount while claiming advantage. They redirect hiring budgets toward AI infrastructure. They appear innovative rather than desperate. The result: industry-wide workforce shrinkage, all justified by AI advancement rather than economic pressure.

The practical result — fewer jobs available — gets buried in the positive narrative. In San Francisco's tech corridors, from the Mission to SoMa, the impact is tangible. While AI eliminates traditional jobs, gig platforms like Uber are creating new AI-related work opportunities for drivers. The workforce transformation creates winners and losers.

The Migration: Step by Step

Phase 1: Package Management

First, swap npm for Bun's package manager:

// Before (package.json scripts)
"scripts": {
  "start": "ts-node src/index.ts",
  "build": "tsc",
  "dev": "nodemon --watch src --exec ts-node src/index.ts",
}

// After
"scripts": {
  "start": "bun src/index.ts",
  "build": "bun build ./src/index.ts --outdir ./dist --target=bun",
  "dev": "bun --watch src/index.ts",
}

Bun runs TypeScript files directly, which eliminates the separate compilation step and results in faster command execution.

Phase 2: Build Configuration

Bun's native bundler replaced TypeScript's compiler. Bun's sensible defaults eliminated dozens of lines of configuration.

Phase 3: CI Integration

Updated GitHub Actions:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: oven-sh/setup-bun@v1
        with:
          bun-version: 1.2.11
      - run: bun install
      - run: bun run build
      - run: bun run typecheck

This also killed package-lock.json — 4,500+ lines removed — in favor of bun.lock.

Phase 4: Refactoring File Operations

The biggest payoff came from converting Node's fs operations to Bun's native File API.

Using Claude Code for the Migration

Claude Code identified file system operations that could use Bun's native APIs. The approach:

1. Scan for patterns like fs.readFile and fs.pathExists across the codebase
2. Build a migration plan for each file based on usage patterns
3. Generate side-by-side rewrites with explanations of Bun-specific benefits
4. Apply changes file by file

Claude suggested optimizations I wouldn't have considered, like using arrayBuffer() for binary file operations.

Challenges

Ecosystem maturity: Not all Node packages work with Bun yet.

Documentation gaps: Bun's docs are improving but still lag behind Node's.

Error messages: Bun sometimes gives less informative errors than Node.

Native extensions: Some C/C++ extensions don't work with Bun out of the box.

The benefits outweighed these drawbacks for my use case.

Results: Faster Builds, Cleaner Code

Build time dropped from 37 seconds to 20 seconds — 46% faster. The development cycle feels different when you're not waiting.

The codebase is cleaner now too:

Should You Switch?

Bun fits well for:

• Static site generators and content-heavy applications
• TypeScript projects that want to skip compilation
• Projects bottlenecked by build performance
• New projects that can fully adopt Bun's ecosystem

For existing projects, migrate gradually. Start with build tooling, then move to runtime code as you validate compatibility. My path:

1. Package management and simple commands
2. Build configuration
3. CI/CD pipelines
4. File operations refactored to native APIs
5. Dependency cleanup

Bun is a real step forward for I/O-heavy JavaScript projects. My migration paid for itself within the first week of faster builds.

Why Bun?

Native speed: Built on JavaScriptCore (WebKit's engine) instead of V8.

Integrated tooling: Package manager, bundler, test runner in one binary.

TypeScript support: First-class, no extra dependencies.

Modern APIs: Native File and Glob implementations that outperform Node alternatives.

TOML support: Built-in parser for configuration files.

File Operations: Before and After

The biggest wins came from replacing Node's file system operations with Bun's native File API.

Before (Node.js with fs-extra):

// Check if file paths exist
if (await fs.pathExists(withSlash)) {
  filePath = withSlash;
} else if (await fs.pathExists(withoutSlash)) {
  filePath = withoutSlash;
}

// Read file content
const content = await fs.readFile(filePath);
let htmlContent = content.toString();

After (Bun's File API):

// Check if file paths exist
if (await Bun.file(withSlash).exists()) {
  filePath = withSlash;
} else if (await Bun.file(withoutSlash).exists()) {
  filePath = withoutSlash;
}

// Read file content
const bunFile = Bun.file(filePath);
let htmlContent = await bunFile.text();

The Bun version runs faster. The native File API handles existence checks and reads with less overhead than Node's implementation.

Bun's Native Glob API

I replaced recursive directory traversal with Bun's native Glob API.

Before (Node.js recursion):

async function getMarkdownFilesRecursively(dir: string): Promise<string[]> {
  const entries = await fs.readdir(dir, { withFileTypes: true });

  const files = await Promise.all(
    entries.map(async (entry) => {
      const fullPath = path.join(dir, entry.name);
      if (entry.isDirectory()) {
        return getMarkdownFilesRecursively(fullPath);
      } else if (entry.isFile() && entry.name.endsWith(".md")) {
        return [fullPath];
      }
      return [];
    }),
  );

  return files.flat();
}

After (Bun's Glob API):

async function getMarkdownFilesRecursively(dir: string): Promise<string[]> {
  const glob = new Bun.Glob("**/*.md");
  const files: string[] = [];

  for await (const file of glob.scan({
    cwd: dir,
    absolute: true,
  })) {
    files.push(file);
  }

  return files;
}

Why Bun Is Fast

JavaScriptCore engine: Apple's JSC engine outperforms V8 for many operations.

Native implementations: File, HTTP, and core APIs are written in Zig, not JavaScript. No abstraction layers.

Optimized I/O: Bun's file operations bypass Node's libuv layer.

Single binary: Runtime, bundler, and package manager share one process. No inter-process communication overhead.

Built-in TypeScript: No separate compilation step.

Zero-copy architecture: Minimizes memory copies, especially for file operations.

These architectural choices compound. I/O-intensive tasks like static site generation benefit the most.

Continue to Part 2 for the migration process, challenges, and results.

New Pricing

Windsurf ditched usage-based flow action credits for flat-rate, per-user pricing. No more tracking multiple credit types for background AI actions. They credit better GPU optimization for making this work. Flow action credits never made sense to me — unnecessary complexity that confused users.

• Pro plan: $15/month per user
• Teams plan: $30/month per user (down from $35)
• Enterprise: Custom pricing

The Teams plan includes 500 credits per user with pooled add-on credits ($40 for 1,000 credits shared across the org). Seat management and analytics included. Advanced controls coming for an extra $10/user/month.

How Cursor and GitHub Copilot Compare

The Numbers That Matter

At $30/user/month, Windsurf undercuts Cursor’s $40 and GitHub Copilot’s $39 Enterprise plan. The $15/month individual plan beats Cursor’s $20, though Copilot Pro at $10/month is still the cheapest option — with limits on advanced models and requests.

Dropping flow action credits removes the biggest source of user complaints: surprise charges and opaque billing. Whether the pricing holds post-acquisition is another question.

Figma's Trademark List

Figma has filed or registered these trademarks, most of which are generic software terms (see USPTO report):

• FIGMA (the company and product name)
• FORGE
• SUMMIT
• CONFIG
• FIGJAM
• SCHEMA
• DEV MODE
• NOTHING GREAT IS MADE ALONE

The Worst Offenders

FIGMA and FIGJAM make sense as brand names, but the rest do not.

• DEV MODE: Universal shorthand for "developer mode." Chrome uses it. Xbox uses it. Jira uses it. Open-source projects have used it for decades (see The Verge). Figma trademarked it in 2023 and now sends legal threats to startups.
• CONFIG: Trademarking "config" is like trying to own "settings."
• SCHEMA: A database and API term. Descriptive, not distinctive.
• SUMMIT and FORGE: Microsoft and Atlassian both use these names for events and tools.

Why the Legal Ground Is Weak

The "Dev Mode" trademark sits on the Supplemental Register, not the Principal Register. The USPTO put it there because the term is descriptive, not distinctive. That makes Figma's legal position fragile. Anyone who files for cancellation with evidence of prior widespread use has a strong case.

Lovable Should Fight This

Lovable refused to back down, and that is the right move. If they file for cancellation, Figma's claim on "Dev Mode" probably falls apart. The tech community needs more companies willing to challenge trademark grabs on common terminology.