Alex Carter — Full-stack Developer

My developer tooling stack for 2026

hello@example.com (Alex Carter) — Wed, 15 Jul 2026 00:00:00 GMT

The editors, terminals, CLI tools, and workflow glue I actually use daily — with honest notes on what earned its place and what got cut.

Shipping genuinely fast websites with Astro

hello@example.com (Alex Carter) — Thu, 18 Jun 2026 00:00:00 GMT

Every few years the pendulum swings between “ship everything as JavaScript” and “ship as little JavaScript as possible”. For content sites — blogs, portfolios, docs — the second camp has clearly won, and Astro is the sharpest tool in it.

The islands model, briefly

Astro renders your entire page to static HTML at build time. Components that need interactivity opt in explicitly:

---
import Chart from '../components/Chart.tsx';
---

<!-- Rendered to HTML, zero JS shipped -->
<h1>Traffic report</h1>

<!-- Hydrated only when it scrolls into view -->
<Chart client:visible />

Everything else — headers, footers, article bodies, cards — ships as plain HTML and CSS. The result is that your baseline JavaScript cost is close to zero, and every kilobyte you do ship is a deliberate decision.

Techniques that actually move the needle

Prefetch on hover and viewport

Astro’s built-in prefetch turns full page loads into near-instant navigations:

export default defineConfig({
  site: 'https://example.com',
  prefetch: {
    prefetchAll: true,
    defaultStrategy: 'viewport',
  },
});

By the time a visitor clicks a link, the next page’s HTML is usually already in the cache. You get SPA-feeling navigation without a router, a hydration step, or a client-side state bug budget.

Self-host your fonts

A @fontsource import costs one line and removes an entire third-party origin:

import '@fontsource-variable/inter';

No connection setup to fonts.googleapis.com, no layout shift from late-loading fonts, no consent-mode headaches. Variable fonts mean one file covers every weight you use.

Optimize the images you forgot about

Hero images get attention; the avatar in your footer doesn’t. Audit with the network tab sorted by size — the offenders are rarely where you expect. Set explicit width and height everywhere so the browser can reserve space before the image arrives.

What I stopped worrying about

Client-side routing. Prefetched MPA navigation is indistinguishable for content sites.
Skeleton screens. If the page renders in under 100ms, a skeleton is just a flash of fake content.
Complex state management. Static pages don’t have state. This is a feature.

The scoreboard

This theme — the one you’re reading — ships roughly 4KB of JavaScript on a typical page: the theme toggle, mobile navigation, and a lazily-loaded search index. Lighthouse gives it a 100 in performance, and more importantly, it feels instant on a mid-range phone over 4G.

Fast is a feature. Static-first is how you afford it.

TypeScript narrowing patterns I reach for every week

hello@example.com (Alex Carter) — Mon, 04 May 2026 00:00:00 GMT

Most TypeScript pain comes from fighting the narrowing engine instead of working with it. These are the patterns I use constantly — not clever tricks, just the bread and butter that keeps a codebase honest.

Discriminated unions over optional fields

The single biggest improvement you can make to a data model is replacing “bag of optionals” with a tagged union:

interface Request {
  status: string;
  data?: User[];
  error?: string;
}

type Request =
  | { status: 'loading' }
  | { status: 'success'; data: User[] }
  | { status: 'error'; error: string };

Now request.data simply does not exist unless status === 'success'. Whole categories of “why is data undefined here” bugs stop compiling.

Assertion functions at the boundaries

Data from the outside world — APIs, forms, file reads — should pass through an assertion exactly once:

export function assertUser(value: unknown): asserts value is User {
  if (
    typeof value !== 'object' ||
    value === null ||
    typeof (value as User).id !== 'string'
  ) {
    throw new Error('Invalid user payload');
  }
}

After the call site, TypeScript treats the value as User with no casting. The unsafe cast lives in one audited function instead of being scattered across the codebase as as User.

`satisfies` for config objects

satisfies checks a value against a type without widening it:

const routes = {
  home: '/',
  blog: '/blog',
  projects: '/projects',
} satisfies Record<string, `/${string}`>;

routes.blog; // type is '/blog', not string

You get validation and precise literal types. Before satisfies, you had to choose one.

Exhaustiveness with `never`

Close the loop on unions with a default branch that fails to compile when a variant is added:

function label(status: Request['status']): string {
  switch (status) {
    case 'loading':
      return 'Loading…';
    case 'success':
      return 'Done';
    case 'error':
      return 'Failed';
    default:
      return status satisfies never;
  }
}

Add a 'cancelled' variant next quarter and this function becomes a compile error instead of a silent bug.

The habit that ties it together

Narrow at the edges, trust the middle. If every input passes through a discriminated union or an assertion function on entry, the core of your application never touches unknown, never casts, and never surprises you at runtime.

Five Postgres indexing mistakes I keep seeing

hello@example.com (Alex Carter) — Sun, 22 Mar 2026 00:00:00 GMT

I’ve reviewed a lot of slow-query incidents over the years. The same five indexing mistakes account for most of them.

1. Indexing the column, not the query

An index on created_at does nothing for this query:

SELECT * FROM events
WHERE account_id = $1
ORDER BY created_at DESC
LIMIT 50;

The planner needs a composite index that matches the access pattern — filter first, then sort:

CREATE INDEX events_account_recent
ON events (account_id, created_at DESC);

Design indexes by starting from your five most expensive queries, not from the schema.

2. Functions in the WHERE clause

Wrapping an indexed column in a function silently disables the index:

-- Sequential scan: the index on email is useless here
WHERE lower(email) = 'alex@example.com'

-- Either use an expression index...
CREATE INDEX users_email_lower ON users (lower(email));

…or better, store the data in the shape you query it: normalize emails to lowercase on write.

3. Believing the index is used because it exists

EXPLAIN (ANALYZE, BUFFERS) is non-negotiable. The planner skips indexes for all sorts of good reasons — small tables, low selectivity, stale statistics — and one ANALYZE events; has fixed more “index isn’t working” tickets than any amount of query rewriting.

4. Partial indexes left on the table

If 95% of your queries touch 5% of your rows, index just that slice:

CREATE INDEX orders_pending
ON orders (created_at)
WHERE status = 'pending';

Partial indexes are smaller, hotter in cache, and cheaper to maintain on writes. They’re the highest-leverage indexing feature Postgres has, and most schemas I audit have none.

5. Forgetting that writes pay for reads

Every index is a tax on INSERT, UPDATE, and VACUUM. A table with twelve indexes is a table where every write does twelve extra btree updates. Drop the ones nothing uses:

SELECT indexrelname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

Zero scans since the last stats reset and it’s not enforcing a constraint? It’s a candidate for deletion.

The meta-lesson

None of these are exotic. They’re all visible in one EXPLAIN ANALYZE and one look at pg_stat_user_indexes. Slow queries are rarely mysterious — they’re just unexamined.

Edge rendering: the trade-offs nobody puts in the launch post

hello@example.com (Alex Carter) — Fri, 30 Jan 2026 00:00:00 GMT

Last year we moved a customer-facing dashboard to edge rendering. Six months later we moved half of it back. Both decisions were correct. Here’s the framework that would have saved us the detour.

What the edge actually buys you

Edge rendering moves your compute close to users. It does nothing about your data. That distinction is the entire story.

For a page that renders from nothing — marketing pages, docs, personalization from a cookie — the edge is a strict win. Time-to-first-byte drops from ~300ms to ~40ms globally, and there’s no origin to keep warm.

For a page that needs your database, the request path becomes:

user → edge (40ms) → database in us-east-1 (280ms) → edge → user

You moved the rendering next to the user and left the data on the other side of the ocean. One data round-trip erases the entire edge benefit; three round-trips make it slower than rendering at the origin, where the database is 2ms away.

The waterfall trap

ORMs make sequential queries invisible. This innocent-looking loader does four serial round-trips:

export async function loader({ userId }: Args) {
  const user = await db.user.find(userId);
  const team = await db.team.find(user.teamId);
  const projects = await db.projects.byTeam(team.id);
  const usage = await db.usage.byTeam(team.id);
  return { user, team, projects, usage };
}

At the origin: 4 × 2ms — nobody notices. At the edge: 4 × 280ms — your dashboard takes over a second before rendering starts. The edge doesn’t just expose latency, it multiplies whatever query discipline you already lacked.

The decision framework

Render at the edge when:

The page needs zero data round-trips (static, cached, or cookie-derived)
The data itself is replicated to the edge (KV, D1 read replicas, CDN-cached APIs)
You can batch the page’s data into one request to a regional API

Render at the origin when:

The page needs your primary database more than once
You depend on libraries that assume Node (native modules, filesystem access)
Debugging matters more than TTFB — origin observability is still years ahead

Where we landed

Marketing, docs, and the login shell render at the edge. The dashboard renders in the region where the database lives, behind a CDN that caches the shell. TTFB for the app is 90ms globally — not the 40ms of pure edge, but with none of the waterfall risk.

The edge is a real tool, not a default. Put compute next to whatever it talks to most — sometimes that’s the user, but more often than the launch posts admit, it’s your database.