DEV Community: Erik Hanchett

Nuxt 4.5 SSR Streaming Is Kind Of A Big Deal

Erik Hanchett — Tue, 11 Aug 2026 17:41:30 +0000

Nuxt 4.5 launched last month and it's really neat. One of my most favorite features is the experimental SSR streaming. With one simple change in the Nuxt config I was able to reduce the Largest Contentful Paint (LCP) by over 2 seconds. I simply enabled the experimental SSR streaming, and the first byte arrived in 16 milliseconds.

With out it, the server spent about 2.5 seconds rendering the page. Streaming changed what the browser could display during that wait.

As a part of my testing I also tried out two other features: useLayout() and named views. Let's take a look at all of these now!

This post walks through all three features using Nuxt 4.5.2. Let's take a look!

If you rather watch check out my full video here

Prerequisites

You will need:

Node.js 22 or another version supported by Nuxt 4.5
npm
Basic experience with Nuxt pages, components, and layouts
Chrome or another browser with document-request timing tools
My sample app! https://github.com/ErikCH/nuxt-ssr-streaming

After cloning down the repo, build it and run it in preview.

npm ci
npm run typecheck
npm run build
npm run preview

The demo preview runs on port 3010. The streamed route is /, and /buffered uses the same components with streaming disabled by a route rule.

Feature 1: Experimental SSR streaming

Normal server-side rendering can buffer the document until every server-rendered component finishes. A slow database query or API request can leave the browser waiting even when the page shell is ready.

Nuxt 4.5 added the experimental ssrStreaming option. It uses Vue's web-stream renderer to flush ready HTML while later boundaries continue rendering.

Create a controlled slow component

I used a fixed delay so the delivery difference would be easy to see. The delay runs on the server, and useState serializes the result into the Nuxt payload for hydration.

<script setup lang="ts">
interface SlowResult {
  resolvedAt: string
  serverDurationMs: number
  renderMarker: string
}

const props = withDefaults(
  defineProps<{
    delayMs?: number
  }>(),
  {
    delayMs: 2500,
  },
)

const route = useRoute()
const result = useState<SlowResult>(`slow-panel:${route.path}`, () => ({
  resolvedAt: '',
  serverDurationMs: 0,
  renderMarker: '',
}))

if (import.meta.server) {
  const startedAt = Date.now()
  await new Promise(resolve => setTimeout(resolve, props.delayMs))

  result.value = {
    resolvedAt: new Date().toISOString(),
    serverDurationMs: Date.now() - startedAt,
    renderMarker: Date.now().toString(36).slice(-6).toUpperCase(),
  }
}
</script>

Place the component inside a Vue Suspense boundary. The fallback becomes part of the shell that Nuxt can send before SlowPanel resolves.

<template>
  <main>
    <header>
      <p>Nuxt 4.5 rendering test</p>
      <h1>The shell is ready</h1>
    </header>

    <Suspense>
      <SlowPanel :delay-ms="2500" />

      <template #fallback>
        <article aria-live="polite" aria-busy="true">
          <p>Shell received</p>
          <h2>Waiting for the slow server boundary...</h2>
        </article>
      </template>
    </Suspense>
  </main>
</template>

The fallback needs to be useful. Navigation, page context, and a clear loading state give the visitor something to work with. Sending an empty shell earlier does little for the experience.

Enable streaming in production

The demo enables streaming outside development and keeps /buffered as a control route.

const ssrStreamingEnabled = process.env.NODE_ENV !== 'development'

export default defineNuxtConfig({
  compatibilityDate: '2026-07-01',
  features: {
    devLogs: false,
  },
  experimental: {
    ssrStreaming: ssrStreamingEnabled,
  },
  runtimeConfig: {
    public: {
      ssrStreamingEnabled,
    },
  },
  routeRules: {
    '/buffered': { streaming: false },
  },
})

The /buffered route uses the same slow component, delay, and shell. Its route rule changes the response mode without changing the work performed by the component.

Compare the responses

Open the streamed and buffered routes as full document requests. Disable the browser cache and use a hard reload. Client-side navigation does not create a new SSR document request.

You can also measure the response chunks from a second terminal:

npm run measure

My local production preview produced this result:

streamed: first byte 16 ms, complete 2562 ms, 14 chunks, 5.8 KB
buffered: first byte 2518 ms, complete 2518 ms, 1 chunk, 5.8 KB

Both routes performed the same delayed work and returned the same amount of HTML. The streamed route delivered the response in 14 chunks and gave the browser useful HTML much earlier. The buffered route delivered one chunk after the slow boundary finished.

This was just a test, on a somewhat contrived setup. However, I would try this yourself in your own app and see how the results go. Make sure to try it in development first, before going to production.

Check the production constraints

ssrStreaming is experimental and disabled by default. Nuxt can fall back to buffered rendering for:

Bots and crawlers
Cached routes
Incremental Static Regeneration (ISR)
Stale-while-revalidate (SWR) routes
Redirects
Routes using ssr: false
Prerendered output
Routes with streaming: false

Streaming also changes when the HTTP response becomes committed. After the shell has been flushed, later component code may be too late to change the status, headers, or cookies. Test authentication redirects, cookie writes, cache headers, errors, and middleware before enabling streaming on a production route.

I would start with a content-heavy page that has a useful shell and one isolated slow boundary. Measure the deployed route with its real adapter and route rules. Keep buffering where the application needs to finish response decisions before sending HTML.

Feature 2: Read the resolved layout with `useLayout()`

Nuxt 4.5 added a stable useLayout() composable. It returns a read-only computed ref containing the layout Nuxt resolved for the current route.

<script setup lang="ts">
const layout = useLayout()
</script>

<template>
  <output class="layout-badge">
    <code>useLayout()</code>
    <strong>{{ layout === false ? 'disabled' : layout }}</strong>
  </output>
</template>

The value accounts for page metadata, route-rule layout selection, and the default layout. It also updates during navigation.

In the demo, two child pages select different layouts:

<!-- app/pages/features/overview.vue -->
<script setup lang="ts">
definePageMeta({
  layout: 'default',
})
</script>

<!-- app/pages/features/focus.vue -->
<script setup lang="ts">
definePageMeta({
  layout: 'focus',
})
</script>

The parent page stays mounted while navigation changes the child route. The computed layout updates from default to focus without requiring the parent to inspect route metadata itself.

Reading route.meta.layout can miss layouts selected elsewhere in Nuxt's resolution chain. Use useLayout() when a component needs the layout Nuxt is actually rendering.

Feature 3: Render multiple outlets with named views

Named views let one route render into multiple page outlets. Nuxt 4.5 uses a name@view.vue filename convention for the additional view files.

The demo uses this structure:

app/pages/
  features.vue
  features/
    index.vue
    overview.vue
    overview@sidebar.vue
    focus.vue
    focus@sidebar.vue

The parent page creates a default outlet and a named sidebar outlet:

<template>
  <section aria-label="Named view outlets">
    <article>
      <NuxtPage />
    </article>

    <aside>
      <NuxtPage name="sidebar" />
    </aside>
  </section>
</template>

When you visit /features/overview, overview.vue fills the default outlet and overview@sidebar.vue fills the sidebar. The focus files do the same work for /features/focus. Both outlets belong to one URL, and the parent does not need a manual component map.

Keep route metadata in the default page file. Nuxt ignores definePageMeta in an @sidebar file. If a route has no matching named-view file, that outlet remains empty.

Finale

I am really impressed by the incremental changes in Nuxt 4.5. SSR streaming is something I'll be using on all my future apps. And useLayout and named views are nice DX bonuses.

Leave a comment and let me know which of these features you'll be using next!

Resources

How To learn Web Development in 2026

Erik Hanchett — Mon, 03 Aug 2026 17:19:26 +0000

Learning web development in 2026 is a lot different than it was when I first learned in 2010. Back then, I used Udemy courses, Stack Overflow, and official documentation. I’d spend hours copying and pasting code, only to discover that the blog post I was pulling it from was out of date. It was frustrating, to say the least.

Luckily, learning a new framework in 2026 is a lot easier than it was.

Recently I was at Chain React. It's a React Native conference and for my talk I decided to really deep into the framework and learn it. I started doing the same thing I always did, reading the docs, buying courses etc. Then I realized I could use AI to speed up my learning. This is what I want to teach you today, with a few additional tips along the way.

Want to watch instead, check out my full video on the subject!

(Full disclosure before I start naming tools: I'm a Developer Advocate at AWS, and Kiro is an AWS product. It's the agentic harness I use daily. Everything here works the same in Claude Code, Cursor, or whatever you already have open.)

Start with a goal, not a curriculum

I don't start by learning a framework. I start with something that I want to build for fun.

When I was learning React Native, it was a workout tracker. I wanted to learn a program called 75 Hard, which is 75 days of hitting the same set of daily goals including a diet, an outdoor workout, and a second workout. I wanted to check those off on my phone. That was the goal.

Making sure you have a goal is really important. A todo list app teaches you nothing, because it means almost nothing. A real app forces decisions you have to make, like does it work offline, where does the data live, what happens when permissions get denied. Pick something with a little resistance in it, ideally tied to a hobby so you'll still care as your learning progression continues.

Decide how much you actually need to know

In other words, how much of it do I need to actually learn to achieve my goal?

In today's age, you need to learn the primitives. The basics, and some architecture of how it all works. You do not need to memorize API signatures anymore.

Let's imagine you are learning React. If you're using useState everywhere, understand what it does and why re-renders happen. Whether you can recall the exact argument order from memory is irrelevant, because the model will write it. Same with optional chaining, same with whatever config format the build tool wants this year. Learn the basics of the framework or library you are learning. Let the agent handle the syntax.

Ask three models what they'd build today

Before I learn anything, I want to know what the ecosystem actually looks like right now. So I ask several models the same broad question and compare.

When I was learning React Native, I ran the same prompt through Gemini, Claude, and GPT. Something like this:

Build a mobile application for iOS.

That comes back with Swift, which tells me something. Then:

Build a cross-platform iOS and Android application.

Now I get Flutter or React Native. I'm not asking for code here. I'm reading the consensus from the agent to find out which frameworks and libraries it's recommending, which tells me whether the thing I'm about to learn is the thing I should be learning.

When the models disagree, that's when I dig in further to find out why. I'll usually google around a bit to see if I'm on the right path.

Get a personalized learning path

Finally, I work on a personalized learning path, based on what I know already. Here is an example:

Build me a curriculum to learn React Native. Assume I already
have basic knowledge of React, HTML, CSS, and JavaScript.

The second sentence is where I brought in my own personalization. I know web development, so I wanted to make sure my learning path is tailored to me. Also, I called out React Native, as per the last section, I learned it's the most popular and makes the most sense for me.

Because I told it I already knew web basics, it skips React fundamentals and goes straight to what's different: native components instead of the DOM, StyleSheet instead of the CSS cascade, navigation as a stack instead of URLs, you get the idea. I then get topics with a suggested time frame, and I can work through them at my own pace.

Heads up: model selection matters here more than almost anywhere else. I ran this against Sonnet 4 and Opus 5. Sonnet 4 handed me what was essentially 2023 React Native. Opus 5 gave me current information and a noticeably better curriculum. Every model has a different training cutoff, and a stale curriculum is worse than no curriculum, because you don't know which parts are wrong.

If you're stuck on an older or a local model, run an adversarial review. Have the cheap model draft the learning path, then hand it to a current model and ask what's out of date. Going past two or three models surfaces a surprising amount, and it's also a good idea when you are trying to save tokens.

Also make sure you use some of the tools your harness gives you. Most harnesses have search built in, plus MCP servers and skills. If you're learning React, install the current React skills before you generate anything. Scaffolding tools help here too: create-next-app now drops an AGENTS.md in your project, and that file is a better starting point for your curriculum than the model's memory.

Build it: I do, we do, you do

A learning path is a good start. It's still reading. To move to actual understanding I used an old teaching framework from 1983.

It's called gradual release of responsibility, from a paper by Pearson and Gallagher, and it sits on top of Vygotsky's zone of proximal development. The sequence is I do, we do, you do. The teacher demonstrates, then you work together, then you work alone.

To use this framework today, the the AI becomes the "I." It does, you watch. Then you work together with the AI, and finally you do it yourself. It's really helped me learn. Let's start with ** I do **

I do: let it build, then read it

Let the agent build the whole thing. Just create a simple prompt, and let it do it's thing. Don't type anything. Read the output, look at the file structure, see how it wired things together.

You are not learning yet, and that's fine. This phase is the right one because it gives you an idea what is possible. If you like you could look over the code that was written, but it's not the best way to learn.

We do: spec-driven development

This is where most of the learning actually happened for me.

Spec-driven development means writing structured specifications first, so the agent can build and verify against them. In practice I ask for a spec instead of an app:

Create a spec that helps build a retro workout planner app.

What comes back is a design document, and the design document is the cheat sheet. Mine told me to use Expo Router 57, expo-sqlite, an image picker, and notifications. That's a map of the architecture and the current library choices for a framework I didn't know yet. When I was working like this, I would constantly ask clarifying questions and ask why certain decisions were made. I would even often ask for changes.

Then it generates requirements, usually as user stories. I skip this one when I'm learning. It's more useful when you're shipping to other people.

The implementation plan is the part you need to pay attention to. It's a task list. Instead of letting the agent execute it, I work through the tasks myself, with the design doc open. When I get stuck, I say so:

I tried to install NativeWind 5 and I don't understand what to do here. Can you help?

Then I get help, and I might even read the official documentation anyways. That's the "we do" phase working exactly as designed. I have enough context to attempt it and a patient buddy for the gaps. It's almost like rubber ducking, but with something that can respond.

Keep in mind, if you write a spec and then let the agent implement all of it, you haven't learned much. You can now explain what your app does and still not explain how the framework does it. So I settled on a rule. Spec the what, hand-write the how, at least once per concept. Write the spec for the app, but make sure your writing things yourself (with help if needed).

You do: turn it off

Close the tab. Build something small with no assistance.

Don't skip this step. This is the best way to check your recall and that you really understand everything. I wouldn't write the whole thing from scratch, mind you, but a few pieces just to make sure I understand the underlying concepts.

Two more patterns worth stealing

Let the AI quiz you. Take the learning path you already generated and ask for a quiz on it, then go back and forth. It's a quick way to find out which parts you only think you know.

The stronger version of this flips the direction. Don't ask the model to explain hooks to you. Explain hooks to the model and ask it to grade you. "Here's my understanding of the New Architecture, what did I get wrong?" Use text-to-speach if you can, to make this even quicker.

The other pattern is learning in public, which I was doing long before agents existed. Post what you're learning, on YouTube or Bluesky or a blog. Writing it down for someone else is what exposes the parts you weren't sure on. This post exists because I told a conference I'd stand up and explain React Native, and that deadline taught me more than any course.

Where I've landed

Start with a goal you care about. Use your usual harness on a current model. Have it build you a plan, with search and MCP servers turned on so it isn't working from memory. Learn the primitives and the architecture, skip memorizing the APIs. Then try out something like: having the AI build it, build alongside it, then build alone.

AI didn't replace the learning. It replaced the searching. All those hours of hunting for the right Stack Overflow answer are gone, and I don't miss them. But the part where you sit with something confusing until it stops being confusing? That still has to happen. There's just no tab for it.

How do you learn a new framework these days? Let me know in the comments if you do it differently. Until next time.

7 Kiro Features You're Probably Not Using

Erik Hanchett — Mon, 27 Jul 2026 15:39:49 +0000

Did you know that Kiro doesn't just have a Spec-Driven Development (SDD) flow, but also a bug fix workflow that helps you resolve one issue at a time? That's one of seven features worth knowing about.

If you're completely new to Kiro, it's an agentic harness for the CLI, web, IDE, iOS, and more. It helps teams and individuals do their best work while coding. I've been using it since it launched in July last year, and I keep finding features I didn't know were there.

(Full disclosure: I'm a Developer Advocate at AWS, and Kiro is a part of AWS. I use it every day, and I'll be forthcoming about the parts that are still preview or experimental.)

Heads up: Kiro ships fast. I've flagged the version-sensitive bits of these features inline. Check the docs if something looks different in your build.

1. Stop approving every single command

After talking to a lot of people about Kiro, one of the main pieces of feedback I get is on approving commands. When Kiro asks permission to run a shell command, the default reaction is to hit yes and move on. Then it asks again for the next git command. And the next one.

Press Tab instead in the CLI. This allows you to edit it and put the exact permissions you'd like. For example you can be pickier on the trust tiers:

git pull --rebase     # this exact command
git pull *            # git pull with any arguments
git *                 # anything git
*                     # the entire shell tool

Whatever you pick persists for the session and gets stored as a regex in your agent's allowedCommands.

There's also /tools trust-all, which trusts everything. It's the documented replacement for the old /acceptall, and the security docs are blunt about it: don't use it in production or with sensitive data, and you're responsible for whatever it does.

One version note: on CLI v3 this moves to a permissions.yaml file, so the agent JSON advice above is v2. More on v3 in a minute.

Full details: tool permissions

2. The `#` menu is bigger than `#file` in the IDE

Type # in the IDE chat and you get a list of context providers. #file is the one I use a lot. The full list:

#codebase · #file · #folder · #git diff · #terminal · #problems · #url: · #code: · #repository · #current · #steering: · #docs: · #spec: · #mcp:

You can stack them in a single message. #git diff #problems review my changes is a different request than either one alone.

The one I've been using more is the #terminal. It hands Kiro your recent terminal output and command history, so you stop copying and pasting errors:

#terminal why did this build fail

One thing I find handy is the "#Currently Open files." However, keep in mind that Kiro pulls in your open files and their dependencies automatically without you asking.

Full list: context providers

Also you can't drag a file in the IDE's own explorer to the chat window, however you can copy and past the location of the file and past that into the chat window as a workaround.

3. Pick a workflow instead of freeform chatting

Kiro gives you structured starting points, and it's tempting to just start typing into the chat box instead. Instead you can choose any of these in the IDE.

Spec for a full feature, with requirements, design, and tasks
Plan when you want an implementation plan and zero code changes
Bug Fix to investigate, diagnose, and resolve one problem
Quick Spec when you want Kiro to ask a couple of clarifying questions and then generate the requirements, design, and tasks for you

Bug Fix is the one I'd try first. It writes down current behavior, expected behavior, and unchanged behavior. I like how it doesn't change a bunch of files it shouldn't. It basically tells the agent what it is not allowed to touch.

On a feature spec you also get a choice between requirements-first and tech design-first. If you already know your architecture, pick design-first. There's no reason to answer requirements questions you already have answers to.

4. Skills are slash commands

Kiro activates a skill automatically when your prompt matches the skill's description. That works, but I feel like it doesn't always automatically activate.

You can invoke one directly instead. Skills in .kiro/skills/ or ~/.kiro/skills/ show up as slash commands, so a skill named pr-review becomes:

/pr-review

That loads the entire instruction file, not just the description. Works in the CLI and the IDE.

Powers are a different thing and worth knowing about separately. A power bundles MCP server config with steering and optional hooks, and Kiro loads it only when your task is relevant to it. Powers are keyword-activated, and they're free on every plan.

5. You might be running an old build

Open Help > About and check your version against kiro.dev/downloads.

Kiro's own changelog says auto-updates were paused for IDE 1.0.x and tells you to download the latest release directly from the site. So if your version doesn't match what's on the downloads page, that's why, and no amount of restarting will fix it. Reinstalling keeps your settings, extensions, and sign-in state.

On the CLI:

kiro-cli --version
kiro-cli update
kiro-cli doctor      # install and config problems

And /changelog in the CLI inside a chat session shows the release notes inline, which is a nicer way to find out what shipped than scrolling a webpage.

6. The work doesn't have to run on your laptop

One subscription covers the IDE, the CLI, Kiro on the web, ACP-compatible editors, and automation in CI/CD. Same credit pool.

I really like the web version. You kick off a session, it runs in a cloud sandbox, and it opens the pull request when it's done. Your laptop can be closed. There are also Automations, which are cron-scheduled agent runs that open PRs on their own.

Web is still in preview, gated to Pro and above, and it needs a connected GitHub account. There's an iOS app too, but it's early access via TestFlight, Pro or higher, and it's a surface for starting and reviewing cloud sessions rather than an editor. No Android yet.

7. The experimental stuff is opt-in and worth trying

Three of these are behind a flag or a toggle.

CLI v3. Run kiro-cli --v3 and it runs alongside your existing 2.x setup without touching it. You get the spec agent in the terminal:

kiro-cli --v3
/spec new my-feature

Plus capability-based permissions.yaml, standalone hooks in .kiro/hooks/*.json, and markdown agent configs. See the v3 docs for the full list of features.

Agent Focus in the IDE. Toggle it from the button in the top right. The layout flips: parallel sessions down the left, chat in the middle, specs and diffs in a panel on the right. It's a different job than editing files. You're directing several agents and reviewing what they produce. Settings, powers, MCP management, the terminal, and direct file editing all still live in the normal view, so you'll toggle back and forth.

/goal. Give it an objective and a definition of done, and it loops implement-then-verify until the criteria are met:

/goal Migrate the auth module to the new SDK. Done when all tests pass and there are no TypeScript errors.

This is available in v3 CLI.

Default is five iterations, --max <n> raises it, /goal clear cancels. The docs are right that the definition of done is the part that matters. "All tests pass" works. "Make it better" does not. You can interrupt mid-loop, or nudge it without cancelling using queue steering with Ctrl+S.

A few more worth a mention

While I'm listing CLI commands: /rewind forks the conversation at an earlier turn instead of you fighting a thread that went off the rails, and the original session is preserved. /compact summarizes history to free up context. /tangent (Ctrl+T) lets you run commands on the side (like /btw in Claude). /guide is a docs-grounded agent for "how do I do X in Kiro" questions, and it can write agents, prompts, and steering files into .kiro/ for you.

If Shift+Enter for multi-line input has been annoying you, /settings terminal fixes it and backs up your terminal config first.

Where to go when you're stuck

The Kiro Discord is the main support channel, and there's an active subreddit at r/kiroIDE. Note the name, it's kiroIDE, not r/kiro. Billing lives in your account settings. Bugs and feature requests go to the GitHub repo, and /issue in the CLI opens that workflow for you. If you need to send logs along with a bug report, /logdump zips them up.

Which of these did you not know about? Let me know in the comments. Until next time.

Nuxt vs SvelteKit: What works better?

Erik Hanchett — Wed, 22 Jul 2026 01:13:24 +0000

Nuxt vs SvelteKit. Which one is better?

That is is what I've been testing out this week. I built the same app twice. Once in Nuxt with the version 5 compatibility preview turned on, and once in SvelteKit using its experimental remote functions.

I created a basic task app. Where you can add or remove tasks. I also logged the network requests and timing. The biggest thing I noticed was that the SvelteKit app would make one request, when creating a new task, while the Nuxt app needed two.

That one difference turned out to be the most interesting part of the whole comparison, so let's jump in.

The setup

Both apps are a simple task list backed by an in browser memory store. Both are production builds running locally, and both render the initial task list on the server.

Quick caveat, Nuxt 5 is not released yet. My Nuxt app is stable Nuxt 4.5 with the compatibility flag set:

// nuxt.config.ts
export default defineNuxtConfig({
  compatibilityDate: '2026-07-01',
  future: {
    compatibilityVersion: 5,
  },
})

And SvelteKit's remote functions are still marked experimental in the docs. So this is a comparison of directions, not finished products.

The numbers

When I add a task in the Nuxt app, I get a POST to /api/tasks (about 690 ms) followed by a GET to /api/tasks (about 450 ms) to refresh the list. A little over 1,100 ms total, and the timeline panel reports two browser requests.

When I add a task in the SvelteKit app, I get one request. About 1,100 ms. The server still does both operations, the mutation and the read, but they come back in a single response.

Plain refreshes were nearly identical. 447 ms in Nuxt, 448 ms in SvelteKit. I ran this quite a few times, and if I had to pick, SvelteKit felt slightly faster overall. But the totals were close enough that I wouldn't choose a framework based on them.

Let's talk about how requests work in each.

The Nuxt version: explicit API routes

If you've used Nuxt before, this will feel familiar. I have two handlers in server/api:

// server/api/tasks.get.ts
import { defineEventHandler } from 'h3'
import { readTasks } from '../utils/task-store'

export default defineEventHandler(() => readTasks())

The POST handler validates the title and saves the task. These are normal HTTP endpoints. Anything that speaks HTTP can call them.

On the page, useFetch loads the initial data during SSR, so hydration doesn't fetch it again. When I add a task, I post with $fetch and then call refresh():

const { data: snapshot, refresh } = await useFetch<TaskSnapshot>('/api/tasks', {
  key: 'task-dashboard',
})

async function submitTask() {
  await $fetch('/api/tasks', {
    method: 'POST',
    body: { requestId: crypto.randomUUID(), title },
  })
  await refresh()
}

The code is explicit, and the network tab matches the code exactly. POST first, GET second.

Could I avoid the second request? Sure. The POST could return the updated list and I could patch local state myself. I wrote it this way because invalidate-and-refetch is the workflow most of us reach for, and it's exactly the pattern SvelteKit's remote functions are designed to improve. I also find by adding a GET request we are verifying the exact output after the POST.

The SvelteKit version: remote functions

This is the experimental feature. You turn it on in svelte.config.js:

const config = {
  kit: {
    adapter: adapter(),
    experimental: {
      remoteFunctions: true,
    },
  },
  compilerOptions: {
    experimental: {
      async: true,
    },
  },
}

Then you create a file ending in .remote.ts and export your server functions:

// tasks.remote.ts
import { command, query } from '$app/server'
import { addTask as addTaskToStore, readTasks } from '$lib/server/task-store'
import * as v from 'valibot'

const taskInput = v.object({
  requestId: v.pipe(v.string(), v.trim(), v.minLength(1), v.maxLength(100)),
  title: v.pipe(v.string(), v.trim(), v.minLength(1), v.maxLength(80)),
})

export const getTasks = query(async () => readTasks())

export const addTask = command(taskInput, async ({ requestId, title }) => {
  const result = await addTaskToStore(title, requestId)

  // This runs on the server, and the refreshed query value
  // comes back in the same command response.
  void getTasks().refresh()

  return result
})

The function bodies always run on the server. In the browser, they become typed wrappers around endpoints SvelteKit generates for you. I really enjoy how there is no public endpoint to hit, it's isolated. It's created for the call, which means I can use environment variables and secrets in there without thinking about it.

The void getTasks().refresh() line is the API on the server side to trigger the refresh. After the mutation, SvelteKit refreshes the query on the server and packages the new value into the command's response. That's the single-flight mutation, and it's why the network tab shows one request instead of two.

On the page, I just import and call the functions:

<script lang="ts">
  import { addTask, getTasks } from './tasks.remote'

  const tasks = getTasks()

  async function submitTask(event: SubmitEvent) {
    event.preventDefault()
    await addTask({ requestId: crypto.randomUUID(), title })
  }
</script>

{@render dashboard(await tasks)}

That await tasks at the bottom works almost like a subscription. When the server-side refresh happens, the task list updates automatically. No server routes to worry about.

My first look at this pattern, I thought it was a little complicated. But it clicked pretty fast, and the query-refreshes-inside-the-command idea makes sense once you see it in the network tab. If you've used server actions in Next or TanStack Start, this will feel like family. I'd say I still like TanStack Start's server actions a bit better, but this is close.

Heads up: remote functions have been available since SvelteKit 2.27 and they are still experimental. The API has changed several times over the past few months. If you adopt them early, pin your versions and budget time for migrations.

What does Nuxt 5 offer?

Nuxt 5 doesn't have an answer to remote functions. Most of the confirmed work is in the underlying structure. A new version of Nitro, a new Vite integration, and framework internals. The upgrade guide walks through what to expect, and it's mostly foundation work rather than new application-level APIs.

My verdict

I'm sticking with Nuxt. I love the API routes pattern, I love Vue, and nothing in this demo is a reason to rewrite an existing app. You can return updated data from a mutation today and skip the second request yourself if it matters.

But I do miss server actions. Frameworks like SvelteKit, Next, and TanStack Start all have some version of a typed, non-public server function you can call from a component. I hope Nuxt adds something like it in a future update, beyond the server components they have now.

If you're starting a SvelteKit project and can live with an experimental API, try remote functions first. The single-flight mutation is awesome, and the types crossing the boundary for free is a great developer experience.

Which side are you on: explicit API routes, or remote functions that generate the transport for you? Let me know in the comments if you agree or disagree.

BTW, I used Kiro for all my research for this post and video! Check it out , it's an amazing harness!

How I Used Spec-Driven Development to Build a Game (TanStack Start)

Erik Hanchett — Tue, 14 Jul 2026 22:26:53 +0000

I've been deep in spec-driven development (SDD) lately, and I want to walk through what it actually is, then show you how I used it to build a game for Kiro's first birthday.

If you haven't run into spec-driven development, or SDD, don't worry, I got you. We'll cover what it is, where it helps, where it's overkill, and how I used it to make this game!

Would you like to watch a video instead? Check it out!

What is spec-driven development?

SDD breaks down into three phases, and all of this happens before any code gets written.

First you create a requirements document. Then you have your AI editor turn that into a design document. Then, from the requirements and the design, you generate a list of tasks.

The most important part is that there's a human in the middle at every step. You check the requirements. You check the design. You review and edit the tasks that get created. Nothing gets built until you've signed off on the plan.

This isn't set in stone, though. Sometimes the requirements and design get combined into a single document. Other times you run it in a quick mode where all three happen at once. It depends on what you're trying to do. When I work on big features I create all three documents, when I'm trying to do something quick, like a demo, I might just use some sort of quick or plan mode.

The trade-offs

Like anything else, SDD comes with trade-offs.

The thing I like most is the high first-pass success rate. If you actually do your job up front, writing a real requirements doc and a real design, the end product is a lot more likely to be what you wanted.

It's also easier to review. You're breaking a big, complex feature into smaller steps, so you can check each one instead, and push up multiple smaller PRs. And it helps prevent you from going in the wrong direction. Instead of letting the agent run off in a bunch of directions and finding out way too late, you're checking the code after every step or two.

The downside is the up front planning time. SDD takes more time before you see any code, so it's not meant for every task. For throwaway code or a small issue, it's not needed. On the other hand any features that takes more thought it does really well. You give up a little time at the start, and in return you get a more stable, better working app at the end.

The project: a Kiro birthday game

Let me show you what I built.

It's a rogue-like game where you walk around and explore a bunch of buildings. Each building represents a different point in time for Kiro, because this is part of our Kiro birthday celebration. Kiro is turning one. So one building covers when Kiro went generally available, another is the house we had at re:Invent, and so on. Visit all the houses and you unlock a bonus house/section. I thought it would be a fun way to tell Kiro's history.

Under the hood it's Phaser and TanStack Start. Phaser is the gaming library doing the 2D Final Fantasy style look, and TanStack Start is the web library wrapping it all. There's music in there too, which I'll get to.

How I used SDD to build it

I opened up Kiro and told it to use spec mode. You can do this right in the IDE, and as of v3 of the CLI you can use spec mode there as well. Either way, it creates those three documents: requirements, design, and tasks.

I gave it a prompt describing the game. Something like, I'm creating this 2D video game, Final Fantasy style, here are the different classes and names, here are the different buildings we're going to have. From that it generated the requirements in EARS format, which is the classic structure of a user story plus acceptance criteria. As I mentioned earlier, I double checked it at every stage to make sure the docs it created were correct.

From the requirements it built a design. You can skip this part if you'd rather keep everything in one doc, but I like having it. The design got into the technical details. Phaser as the TypeScript library for the front end, TanStack Start with useEffect all over the place, the high-level structure, the scenes, the boundaries, the game shell.

Then came the task list, with every single task broken out. I told it to build an MVP first, so it took the full list and pulled the four most important tasks to the front. I went in and made sure that ordering made sense, had it implement those first four, looked at the output, and confirmed it held up before moving on.

The tools that made it easier

A few things helped a lot here.

I used a couple of MCP servers. Context7 to grab the Phaser documentation, so the agent wasn't guessing at the API. And the Chrome browser MCP extension, so Kiro could open the app, look at it, and make sure it matched the requirements.

I also ran auto mode. I bounced between models, and while Claude 4.8 is great, it does chew through a lot of credits. Auto mode did really well, especially paired with SDD. That's one of the underrated parts of this approach. When everything is already written down in the spec, you don't need the greatest state-of-the-art model to get what you need. Auto mode was more than enough for most of this.

On top of that I used some skills. The AWS Agent Toolkit, plus the Amplify and serverless skills. I ran /aws-amplify and it helped me get the game hosted on Amplify hosting. For the music I used ElevenLabs. I had a scripts folder wired up to a bunch of services, PixelLab for art, ElevenLabs for audio, even Hugging Face. All of it driven from inside Kiro, with a .env file holding the keys, and it generated the assets for me too.

Wrapping up

That's the basic version of my spec-driven development workflow. It's more planning up front, but for a real feature it pays off.

If you want to try the game, check it out!

Do you use spec-driven development in your day-to-day? I'm curious what your experience has been. Take care, and thanks for reading.

TanStack Start vs Nuxt: One Framework to rule them all?

Erik Hanchett — Tue, 07 Jul 2026 21:38:55 +0000

I love Nuxt and I really like TanStack Start. But which one is better? Or are they about the same?

And if they are about the same, does it do anything my Nuxt setup can't, and is that worth leaving Vue for React? So I decided to build the same app in both frameworks and take a look. Read on below to find out!

If you'd rather watch a video, check out the video on the same topic!

The app

In both frameworks I built a small GitHub user lookup app. You type a username, the profile gets fetched on the server, and the username lands in the URL as a ?user= query param so the result is shareable. Type ErikCH, hit enter, and the card renders. Refresh the page and it's still there. It has the same behaviour so the difference lies in the code.

Difference one: server functions vs server routes

On the Nuxt side we call a server route from useAsyncData. Server routes are the more idiomatic way to use Nuxt to call things on the server.

<!-- app/pages/index.vue -->
<script setup lang="ts">
import { z } from 'zod'
import type { GithubUser } from '~~/server/api/github.get'

definePageMeta({
  props: route => z.object({ user: z.string().default('') }).parse(route.query),
})

const props = defineProps<{ user: string }>()
const router = useRouter()
const input = ref(props.user)

const { data, error } = await useAsyncData(
  'github-user',
  () =>
    props.user
      ? $fetch<GithubUser>('/api/github', { query: { user: props.user } })
      : Promise.resolve(null),
  { watch: [() => props.user] },
)

function lookup() {
  router.push({ query: { user: input.value.trim() } })
}
</script>

The props option on definePageMeta maps the query into a typed page prop and re-runs on client navigation. useAsyncData fetches when there's a username and refetches whenever it changes. The conditional that returns Promise.resolve(null) skips the request on an empty query param, (or when you first load).

The server route does the outbound call:

// server/api/github.get.ts
import { z } from 'zod'

const querySchema = z.object({
  user: z.string().trim().min(1, 'Missing ?user='),
})

export default defineEventHandler(async (event): Promise<GithubUser> => {
  const { user } = await getValidatedQuery(event, querySchema.parse)
  return $fetch<GithubUser>(
    `https://api.github.com/users/${encodeURIComponent(user)}`,
  )
})

getValidatedQuery runs the schema and hands back a typed, validated user. A bad shape, like an array or an empty string, gets a 400 before the handler runs.

TanStack Start takes a different route. There's no separate API endpoint. You write a server function and call it directly from the loader.

// src/routes/index.tsx
import { createServerFn } from '@tanstack/react-start'

const getGithubUser = createServerFn({ method: 'GET' })
  .inputValidator((username: string) => username)
  .handler(async ({ data: username }): Promise<GithubUser> => {
    const res = await fetch(
      `https://api.github.com/users/${encodeURIComponent(username)}`,
    )
    if (!res.ok) throw new Error(`GitHub API error: ${res.status}`)
    return (await res.json()) as GithubUser
  })

One API covers reads and writes. This same createServerFn handles a GET here, and it would handle a POST mutation the same way, called from a loader or straight from a component. The return type flows through to the caller with no manual annotation.

The route wires it up:

const searchSchema = z.object({ user: z.string().catch('') })

export const Route = createFileRoute('/')({
  validateSearch: searchSchema,
  loaderDeps: ({ search: { user } }) => ({ user }),
  loader: async ({ deps: { user } }) => {
    if (!user) return { user: null, error: null }
    return { user: await getGithubUser({ data: user }), error: null }
  },
  component: Home,
})

validateSearch defines the query, loaderDeps narrows it to just what the loader needs, and the loader runs on navigation, a lot like script setup running when a Nuxt page loads.

Between the two, I really like TanStack and it's server functions. I don't have to worry about another end point being exposed to the internet, and it's simple to use. Though both work for a lot of different scenarios.

Server components in both

Both frameworks also let you skip the client entirely with server components, and both still label the feature experimental.

Nuxt calls them islands. You flip one flag in nuxt.config.ts:

export default defineNuxtConfig({
  experimental: {
    componentIslands: true,
  },
})

Then a component named with a .server.vue suffix renders only on the server. It can call useFetch directly, and no client-side JavaScript ships for it. Basically you embed the server component in a client component and that's it.

<!-- app/components/GithubUserCard.server.vue -->
<script setup lang="ts">
import type { GithubUser } from '~~/server/api/github.get'

const props = defineProps<{ user: string }>()

const { data, error } = await useFetch<GithubUser>('/api/github', {
  query: { user: props.user },
})
</script>

The card fetches on the server and streams its HTML into the page. When ?user= changes, Nuxt refetches the island in place. The GitHub response never lands in the browser bundle, which is nice to help reduce bundle size.

TanStack Start added server components too, back in April. They're also experimental, and from the docs they look pretty different from the Next.js version people know, built around a readable-stream API. I tried it and found it more complicated than the Nuxt island, so for this app I stayed on the server function.

Of everything here, the server function is still my favorite. Server routes earn their place when something outside your app needs to call in, like a webhook, or some sort of callback. For the rest, the function felt better and cleaner.

Typed search params

This is where TanStack Start made me a little jealous.

Because validateSearch puts the query schema on the route itself, the user param is typed everywhere it shows up. Not only in the component, but in navigation and links.

// Typed against the route's search schema:
navigate({ search: (prev) => ({ ...prev, user: input.trim() }) })

<Link to="/" search={{ user: 'ErikCH' }}>Look up</Link>

Pass a key that isn't in the schema and you get a red squiggle before you save. Delete the target on a <Link> and the editor lists the real routes, because the routes are typed as well. I could see me using this all over, and if you're using an agent to help code, this will help catch the errors even quicker.

Nuxt gets you close, with two caveats. Turn on experimental.typedPages and your <NuxtLink> routes are typed, so that half matches. With the props plus Zod pattern above, the user value reaching your component is typed and validated too. What Nuxt doesn't give you yet is the query itself typed on the link. You can type the prop, but not the ?user= on a <NuxtLink>.

If you are on the Nuxt team, does anyone know a workaround? Leave a comment? I'd love a typed-query-params story on the router in Nuxt.

What they actually share

Interesting enough, both of these frameworks share a lot. Both build on Vite, so both dev servers start are super fast. Both run on Nitro for the server layer, which adds a lot of flexibility when deploying to different places. Overall in that sense they are very similar.

One practical thing to weigh. As of this recording TanStack Start is still a Release Candidate (RC), so expect a few rough edges and bugs. Nuxt is on 4.4.x, production-hardened, with a modules ecosystem for images, i18n, SEO, and a lot that TanStack Start doesn't have yet.

The verdict

So, should a Nuxt developer switch? For me, no, at least not today. I'm staying on Nuxt. I like Vue, the framework is mature, and TanStack features are nice, but not enough for me to move over (specially since it's still React).

If you're already a React developer, or starting something new in React, TanStack Start is genuinely fun and I'd reach for it. React fans will feel at home in TanStack Start, Vue fans in Nuxt. I'll keep an eye on TanStack Start and pull it out for the odd project every now and then.

One last note. I did all the research for the video and this post in Kiro, an agent that works on the IDE, CLI and Web.

If you've run both, tell me which way you'd go in the comments.

Loop Engineering: Do Frontend and Fullstack Devs Actually Need It?

Erik Hanchett — Tue, 30 Jun 2026 17:59:18 +0000

Introduction

I keep hearing the term loop engineering. It's all over my feed, every AI newsletter, half the dev videos I open. So I had the same question you probably have. Is this actually important, and do I need to learn it as a frontend or fullstack developer?

I spent some time with it and made a video breaking down what it is and where it fits. This post is the written version, with a practical example you can copy.

What loop engineering actually is

Here's how I think about it. You give your coding agent a goal, and it runs over itself again and again, almost recursively, until that goal is met.

You can also frame it as four parts. You give the agent a trigger or a system prompt with a clear ending state. It acts on that trigger. It observes to check whether the work is actually done. If it hits the stop condition, it stops. If it doesn't, it goes around again.

That's basically it. The idea is that you are defining a goal and a stop condition, then letting the agent close the gap on its own.

It's the agentic loop you already know

If you've built anything with agents, this should feel familiar. It's the classic agentic loop. You give an agent a set of tools, and it uses those tools with its own reasoning to reach an answer.

Say I want to research the latest tech trends. I give the agent a tool to search Google and a tool to search Reddit. On the first pass it searches Google and pulls what it finds. That isn't enough, so it loops again and pulls from Reddit. Then it combines both and hands the answer back to me.

You've seen the same thing in a chatbot. Ask it for the weather and it might call a few tools, look at the context of your question, and come back with what you asked for. Loop engineering is that pattern, pointed at your actual work.

A practical example: fixing a PR on a loop

Let me show you where this earns its place day to day.

I had a pull request that I pushed up using Kiro Web. It connected straight to my GitHub repo, I gave it an action, and it opened the PR for me. You can do this with Claude Code, Cursor, and other agents too.

Then I noticed some tests were failing in my CI/CD pipeline. My GitHub Actions were red. So I gave it one prompt:

Fix all issues on the PR. Keep going until it's all fixed.

That last sentence is the stop condition. Kiro went to work in the background, running again and again, fixing the failures and looping until everything passed. I didn't babysit it through each round.

Tests are a great place to start with this, because the pass or fail signal gives the loop a clear way to check its own work.

Automations are the other big use case

The other place loops shine is on a schedule. Addy Osmani wrote a great article on loop engineering where he points out that automations running on a schedule, doing discovery and triage on their own, are a strong fit for this.

If you can find work that a cron job or a scheduled tool can kick off every day, that's a candidate. A couple of examples:

At the end of every day, run all the tests, and if anything is broken, let the agent fix it. Or keep your documentation current. The loop checks the docs against the latest code and keeps going until they match.

If you use Claude Code, there's a /loop command and a /goal command worth knowing. They let you set up in-session scheduled work, and /goal lets you set a persistent, verifiable objective instead of a single one-off task. You can do the same thing in Kiro and other tools, you just have to be more explicit and write your own system prompts to drive it.

My take

Now the part where I push back a little.

Don't tear up your whole workflow to jam loops in everywhere. There are real spots where they make sense, especially when your agent supports them and you've found an automation worth setting up. But I still think spec-driven development and plain back-and-forth vibe coding will solve most of your problems day to day. Loops are a tool to reach for in the right moment, not a religion.

If you want to go deeper, three people shaped how I think about this. Kent C. Dodds made an excellent video on what he's discovered and how he works this way. Theo did a great one too. And Addy Osmani's article on loop engineering is worth your time.

So I'll ask you what I asked at the end of the video. On your next project, are you going to try loop engineering? Or is it just hype? Let me know.

Resources:

3 Tools That Make AI Suck Less at Coding

Erik Hanchett — Mon, 22 Jun 2026 00:47:45 +0000

I've completely updated my workflow, and I use AI coding agents for everything. Writing code, testing, and just helping me be more productive. However, AI isn't perfect and often after a long back-and-forth session I'll have working code, but it will have a few code smells. Duplicated code, dead-end code, lengthy functions are common. One way to fix that is to add all these problems to an AGENTS.md file and that works. But that's not always possible, depending on the codebase and team I'm working with.

To that end, I went looking for tools that could help me detect and fix these issues. And so after some research I found three tools that could work almost as a pipeline. One finds these issues, one reviews the changes before they ever reach a pull request, and one helps me evaluate my agents. I use Kiro for most of my day to day, so I wired all of these into that loop, but they run with whatever agent you already have.

If you'd rather watch than read, here's the full walkthrough:

This post covers:

Finding dead code and duplication with Fallow
Reviewing the AI's diff with CodeRabbit before you open a PR
Measuring whether the output improves with Kiln

Prerequisites

Node.js 20 or newer, so you have npx
A JavaScript or TypeScript project, ideally one with some AI-generated code in it
A coding agent like Kiro, Claude Code, or Cursor for the review-loop parts
Git, for the diff-based workflows

Find the mess: Fallow

The first problem I've seen often is that AI can generate a mess of code. It will duplicate a block, leave an orphaned file behind, and grow a function to a thousand lines without ever flagging it, because each individual edit looked reasonable in isolation. You need a tool that reads the whole codebase at once.

Fallow is the one I reached for. It's static codebase intelligence for JS and TS, and it works a lot like ESLint, except it's built around these common AI code issues. You can run it with:

npx fallow

That gives you a full report. The sections I care about most are dead code, duplication, and complexity. Dead code finds files that aren't reachable from any entry point, exports nothing imports, and dependencies you've stopped using. When I ran this on my vibe-coded chess app (see video) it found dozens of these problems Duplication shows you the exact line ranges that got copied between two places. Complexity scores each function on how branchy and how hard to test it is, then ranks your worst offenders so you know where to start.

There's a fix command for most things:

npx fallow fix

If you'd rather have an agent fix it you can use a JSON output and the skill. Run it with --json and you get structured findings an agent can read and act on. Fallow also ships an agent skill you can install:

npx skills add fallow-rs/fallow

Once that's in place, I can tell Kiro to build a feature and then run Fallow on its own work to clean up after itself. It catches the duplicate block it just wrote and removes it before I even see it. You can also drop fallow audit into CI so it compares your branch against main and only flags what your change introduced.

Bonus: Knip

If Fallow is more than you need, Knip does the dead-code half on its own and has been around longer. It finds unused files, dependencies, and exports in JS and TS projects in one command:

npx knip

I've found knip to be a little slower then Fallow. YMMV.

Review the diff: CodeRabbit

Finding dead code is great, but what about reviews?

CodeRabbit puts a review step back in. It's AI code review that runs on your diff, and the version I like runs locally from the CLI so it happens before the PR exists. Install it with one line:

curl -fsSL https://cli.coderabbit.ai/install.sh | sh

Then point it at your uncommitted changes:

coderabbit review --plain

It reads the diff and comes back with specific findings. It also hands you a fix prompt you can paste straight back into your agent, so the loop closes quickly.

Jack Herrington made the point in his video that lower-end models get noticeably more useful once CodeRabbit is in the loop, because the review catches what the cheaper model missed. That makes sense to me. The agent writes, CodeRabbit reviews, the agent fixes.

Measure the improvement: Kiln

The first two tools clean up individual changes. This last one answers a bigger question. When I tweak a prompt, swap a model, or add a skill, is my agent's output actually better, or does it just feel better because the last three runs went well?

Kiln is the tool I use to stop guessing. It's built for creating and evaluating AI systems, so you set up datasets, run evals, and compare results across changes.

For my use case, I connected it to some output a LLM was producing. I ran an eval on it to make sure it was as I expected. When I added the Fallow skill, I could iterate on the system prompt and strings. It's the same instinct behind writing tests for your code, pointed at the thing generating the code.

This is the least flashy of the three and the one I'd skip first if you're in a hurry. But if you're serious about tuning a workflow you'll use every day, measuring beats vibes every time.

How to pick

You don't have to use all three, so here are some good guide lines for each:

If your agent leaves dead code and duplication everywhere, start with Fallow, or Knip if you want something smaller.
If you need more code reviews, add CodeRabbit and let it review before you do.
If you're tuning prompts, models, or skills and want proof you're improving, set up Kiln.

Keep in mind these tools don't replace knowing what good code looks like. They raise the floor on what your AI ships so the version that lands in your editor is closer to something you'd have written yourself. That's extremely important. AI made writing code fast, and it made reviewing code the bottleneck. These three move that bottleneck.

Conclusion

AI compresses how long it takes to generate code and stretches how long it takes to trust it. Fallow and Knip find the mess it leaves behind, CodeRabbit reviews the change before it slips past you, and Kiln tells you whether any of your tuning is working.

If you want to see these running inside a real agent loop, I walk through all of them in the companion video.

Resources:

The most popular AI coding skills right now

Erik Hanchett — Mon, 15 Jun 2026 17:04:07 +0000

Introduction

It's crazy to me that some GitHub repos, that were just created in the last year, have more stars then some of the most popular programming frameworks out there. At the time of writing, Superpowers, is around 226,000, ahead of the Vue repo and way ahead of Next.js. A separate repo based on Andrej Karpathy's coding advice has 174,000. And they aren't even code. They're folders of markdown files that tell your AI coding agent how to write software better.

In other words these are agent skills, and they've blown up over the past year into one of the most-starred new categories of developer tooling. The format started at Anthropic, a SKILL.md file with a short description and a set of instructions, and now it works in Claude Code, Kiro and all your other favorite coding agents.

This post is a tour of some of the skills I find most interesting that people are using everyday. I'll be in Kiro for most of this, but these run in whatever agent you already have, with install paths that vary per agent.

This post covers:

What an agent skill actually is
The big workflow skills (Superpowers, Karpathy, Matt Pocock, GStack, GSD)
Framework skills and the "ships with your package" model
The Agent Toolkit for AWS
How to pick one and try it safely

If you like, you can watch a full video on the subject instead! Also if nothing else, please check out the Agent Toolkit for AWS! More information below. Full disclosure, I'm a developer advocate for AWS

What is an agent skill?

A skill is a directory with a SKILL.md file inside it. The file has a name, a one-line description, and instructions. These instructions include which steps to follow, which APIs to call, which mistakes to avoid and how to check the result.

Skills should only run when needed. Your agent reads the short description, decides if the skill is relevant to what you asked, and only then loads the full instructions. Reference files load on demand after that. So you can have fifty skills installed and your context window stays clean, because the agent pulls in the two it needs and ignores the rest. In practice, I've found I still need to manually tell my agent to run the skills by using the / command and the skill name. YMMV

The big workflow skills

Most of the popular general-purpose skills are trying to fix the problem agents often have, going in the wrong direction. Agents when left alone often rush in, touch too many files, and they skip planning. These five take different approaches to slowing it down.

Superpowers (obra/superpowers)

Superpowers is the most-starred of the bunch and the most opinionated. It is a full development methodology that triggers automatically. It really reminds me of a super powered Spec-Driven Development (SDD) workflow.

The moment the agent sees you are building something, it stops and asks what you are actually trying to do. It works a spec out of the conversation, shows it to you (optionally in a web browser), and only after you sign off does it write an implementation plan. Then it hands the plan to subagents that build and review each other's work. Be aware, this can eat up a lot of tokens.

It is available through the official Claude plugin marketplace, plus Codex, Cursor, Gemini CLI, and a handful of others. You can also get it working with Kiro by from Skills.sh. Though, I'd probably skip it if you're using Kiro, since most of the SDD is already there in Kiro.

If you want one system that owns the whole loop from idea to reviewed code, this is the one to reach for. In Claude Code, install it from the official plugin marketplace:

/plugin install superpowers@claude-plugins-official

The Karpathy guidelines (multica-ai/andrej-karpathy-skills)

This one is almost the opposite. It is a short file of behavioral rules, now at 174,000 stars. Andrej Karpathy did not write it, despite the name, which I find really funny. It is a community-built file derived from a January post where Karpathy listed the ways LLM coding agents tend to fail, and the repo later moved to the multica-ai org.

The rules come down to four simple ideas. Think before coding, keep it simple, make surgical changes, and stay focused on the goal. If Superpowers feels like too much process for you, this is the low-commitment starting point. It is a single CLAUDE.md (or AGENTS.md, or you can use it as a Skill), so the simplest install is to drop it into your project:

curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

Personally, I'm not sure if this is worth it in my own testing. However, it's easy enough to add it to your own CLAUDE.md or AGENTS.md so give it a shot though and make your own opinion.

Matt Pocock's skills (mattpocock/skills)

Matt Pocock's collection sits in the middle and takes a deliberate stance against the all-in-one systems. In fact, he's often said he doesn't like SDD, and thinks it's too cumbersome. His framing is that approaches which own your entire process also take away your control and make bugs in that process hard to fix. So his skills are small, composable, and easy to adapt. You install the ones you want with the Vercel skills CLI:

npx skills@latest add mattpocock/skills

His most popular one, and the one I like the most, is the grill-me, which makes the agent interview you about what you are building before it writes anything. There is a more powerful version, grill-with-docs, that does the same interview and also builds a shared-language document for your project. The repo's pitch is that this shared-language document pays off across sessions. There is also tdd for a red-green-refactor loop, diagnose for debugging, and improve-codebase-architecture for rescuing a project that has turned into spaghetti.

Another skill called caveman helps reduce token costs. I find the caveman and grill-me skills the most useful. Though, I find grill-me a little annoying after a while, when I just want to get something done.

GStack (garrytan/gstack)

GStack is Garry Tan's Claude Code setup, and at nearly 110,000 stars it is one of the most popular skill collections out there. Instead of one mode that handles everything, it gives the agent distinct roles, each behind its own slash command. It has product vision, designer, engineering manager, release manager, doc engineer, QA, and post-launch retrospective. It is the same genre as Superpowers, a full workflow, but organized around the roles on a software team rather than a sequence of phases. If you think in terms of "who would handle this part," GStack maps to that mental model nicely. It installs with a clone and a setup script (pass --host kiro, --host cursor, and so on for other agents):

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

It also works with Kiro nicely.

GSD Core (open-gsd/gsd-core)

GSD Core (Git. Ship. Done.) is a spec-driven system that pitches itself as a fix for context rot, the slow drop in quality as your context window fills up during a long session. It breaks work into atomic plans that run in fresh context windows, keeping the main session light while subagents do the heavy lifting. It targets more than a dozen agents. The project moved from the old gsd-build org to its current home at open-gsd/gsd-core, and the installer prompts for your runtime:

npx @opengsd/gsd-core@latest

While using this, I found that it burned through tokens fast. It also takes over your whole workflow, that I disliked. Still, it's worth trying out to see if it works well for your own personal projects.

Framework skills and the "ships with your package" model

The skills above are framework-agnostic. The more interesting development for frontend folks is skills that know your specific stack.

The Vue community moved early here. vuejs-ai/skills is a community Vue 3 skills project (the README notes the author may propose transferring it to the Vue org), and its vue-best-practices skill is a structured workflow covering the Composition API, reactivity, and the patterns you want a model to follow. Anthony Fu's collection covers Vue, Vite, Nuxt, Pinia, VueUse, and Vitest. Both install through the same CLI:

npx skills add vuejs-ai/skills
npx skills add antfu/skills --skill='*'

The newer idea is shipping skills inside the package itself. Three things are worth knowing:

skilld generates version-aware skills from the npm dependencies you already have, pulling from docs, release notes, and GitHub issues. It solves the problem where a model's training cutoff means it writes last year's version of your library.
TanStack Intent (@tanstack/intent) flips that around for maintainers. It lets library authors generate and ship SKILL.md files inside their npm package, versioned with each release, so the skill updates when the library does. It launched recently and ties straight into the TanStack ecosystem.
The Vercel skills CLI is the npx skills tool that installs any of this across 70-plus agents. If you use Kiro, it loads skills from .kiro/skills/ automatically with no config, which makes it an easy way to try things on camera or in a real project.

Here is each of those three:

# Generate version-aware skills from your installed npm dependencies
npx -y skilld

# Library maintainers: scaffold SKILL.md files inside your own package
npx @tanstack/intent scaffold

# The universal installer used throughout this post — pattern is `npx skills add <owner/repo>`
npx skills add vercel-labs/skills

The Agent Toolkit for AWS

AWS ships skills too, in the same open format, so they run in Kiro, Claude Code, Cursor, and Codex.

The Agent Toolkit for AWS was announced in May 2026 and is the officially supported way to bring AWS expertise into your agent. It pairs plugins for Claude Code and Codex with a curated collection of skills and the AWS MCP Server, which reached general availability on May 6, 2026. The toolkit covers areas like deployment, serverless, and database work. Setup is per-agent. In Kiro you add the AWS MCP Server through your MCP config and then pull in skills with npx skills:

# Install AWS-curated skills via the universal CLI
npx skills add aws/agent-toolkit-for-aws/skills

If you are building on AWS, you should download this. Even if you are not using AWS I would download it for the future. Because with this the agent loads service-specific guidance instead of guessing at an API it half-remembers from training.

How to pick one and try it safely

Personally, I would use Matt Pococks skills and try out one of the other larger skill workflows like Superpowers. See if it works for you. Then pair it with a framework specific skills as well.

Last thing, and it matters. A skill is instructions you are dropping into your agent's context, so treat it the way you treat an npm dependency. Read the SKILL.md before you install it. A repo with 100,000 stars is popular, but stars are a popularity signal, not a quality review. Skim the file, see what it tells your agent to do, and keep the ones that match how you actually work.

Conclusion

Agent skills went from a quiet Anthropic format to repos with more stars than the frameworks we build on, and it makes sense why. They take the patterns a good engineer carries in their head and hand them to the model at the start of every task. The big workflow skills give you structure while the framework skills give you correctness, and the AWS plugins give you service-specific knowledge you would otherwise paste in by hand.

My advice: install one, read what it actually tells the agent, and see if the output matches how you'd have built it yourself. That's the real test, and it's the one only you can run. If you want to see these in action, I walk through them in the companion video.

TanStack Start Is Kind of a Big Deal

Erik Hanchett — Mon, 08 Jun 2026 17:06:43 +0000

Introduction

People keep telling me TanStack Start is kind of a big deal, and I wanted to know if that holds up or not. I've been spending a lot of time at conferences lately, and TanStack Start comes up quite often in conversation. The community is split if server components is the right answer. TanStack Start has gone the opposite direction with it's clean client-side first components approach, with lot so ways to call server-side code, even in the same component.

I'm a Vue and Nuxt person most days, so I'm not here to dunk on anyone's framework. What I want to figure out is simpler: are there specific things TanStack Start does that Next.js and Nuxt don't, and are they good enough to switch for?

After some research I have come up with three things I really like about TanStack Start. These things alone aren't probably enough for me to switch, but I'm getting close.

If you'd like to watch a video instead, check this out!

Prerequisites

Node.js 22+
Comfort with React and TypeScript
You do not need any Next.js or TanStack experience

What we're building

A GitHub user lookup. You type a username, the app fetches that user from the GitHub API on the server, and renders their profile. It's a perfect app to show these three features.

You can find the full code in the demo repo. Let's start by creating the app.

Step 1: Create the app

TanStack has a CLI, so scaffolding is one command:

npx @tanstack/cli@latest create my-app --framework React

It asks about a package manager and a few add-ons, then sets up a project on Vite with file-based routing. Run it:

cd my-app
npm install
npm run dev

The dev server was ready in under a second on my machine. That Vite-powered startup is really nice, and it's the same Vite speed I covered in my earlier Vite videos.

The structure is small:

src/
├── routes/
│   ├── __root.tsx      # the document shell
│   └── index.tsx       # the home route
├── router.tsx          # router config
└── routeTree.gen.ts    # auto-generated, don't edit

Now the three features.

Feature 1: One server function for reads and writes

Let me be fair up front, Next.js can also call server code directly. Next has React Server Functions, and in mutation contexts those are Server Actions. You mark a function with "use server" and call it from a component, no API route required. Nuxt has its own version with server/api routes plus useFetch, which gives you typed responses too. So "call a function on the server" is not unique.

However, the difference is the constraint. Next.js Server Actions run as POST requests and are built for mutations. The Next docs themselves steer you to Server Components or Route Handlers for reading data. You can call a Server Action from a client component to read, but it still goes over POST and isn't the idiomatic, cacheable GET path.

TanStack Start doesn't split it this way. One primitive, createServerFn, handles both a GET read and a POST mutation, and you call it the same way from anywhere.

import { createServerFn } from '@tanstack/react-start'

interface GithubUser {
  login: string
  name: string | null
  avatar_url: string
  html_url: string
  bio: string | null
  public_repos: number
  followers: number
  following: number
}

const getGithubUser = createServerFn({ method: 'GET' })
  .inputValidator((username: string) => username)
  .handler(async ({ data: username }): Promise<GithubUser> => {
    const res = await fetch(`https://api.github.com/users/${username}`, {
      headers: {
        Accept: 'application/vnd.github+json',
        // a token here stays on the server, never ships to the client:
        // Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
      },
    })
    if (!res.ok) throw new Error(`User "${username}" not found`)
    return (await res.json()) as GithubUser
  })

That .handler runs only on the server, so a token never reaches the browser. I set method: 'GET' because this is a read, and I call it straight from my route loader like a normal async function. There is no route handler, or RSC boundary to think about and no endpoint string to keep in sync. (This snippet is trimmed for clarity. The version in the repo adds encodeURIComponent on the input and separate handling for 404 and 403 rate-limit responses.)

You can watch this happen in the browser too. Open the network tab, run a lookup, and you won't see a request to api.github.com anywhere. The only call is the one to my own server. The GitHub fetch is happening server-side, which is exactly where I want it, and any token isn't leaked.

I really like how types work here. I annotate the handler's return as GithubUser once, and that type flows through the loader and into the component without me re-typing it at each call, and that holds whether it's a GET or a POST. Rename a field in the interface and every call that still reads the old property lights up red. (One caveat, that's compile-time propagation, not runtime validation. I cast the GitHub response with as GithubUser, so if you want to prove the external JSON actually matches, you'd add a runtime schema check.) You can get there with a route handler too, with shared types or a schema validator. The difference is that TanStack infers the chain for you by default instead of asking you to wire it up.

Feature 2: Search params that are actually typed

This is the one where TanStack genuinely has an advantage as of today. Next.js gives you generic string and string-array search params, not route-local schema validation. useSearchParams hands you a read-only URLSearchParams, and while typedRoutes plus the PageProps helper have improved path, navigation, and page-prop typing, none of that validates or transforms the values inside the query string the way TanStack Router does. You can get there in Next with Zod, nuqs, or next-typesafe-url, but it's something you add on. Nuxt can validate a route with definePageMeta's validate function, which can return false or a Partial<NuxtError> to reject a route, but it doesn't turn route.query into a typed, validated query object for your component.

TanStack Router treats search params as validated route state out of the box:

export const Route = createFileRoute('/')({
  validateSearch: (search): { user: string } => ({
    user: typeof search.user === 'string' ? search.user : '',
  }),
  loaderDeps: ({ search: { user } }) => ({ user }),
  loader: async ({ deps: { user } }) => {
    if (!user) return { user: null, error: null }
    return { user: await getGithubUser({ data: user }), error: null }
  },
  component: Home,
})

I validate ?user= once. After that, Route.useSearch() gives me { user: string }, fully typed, anywhere in the component. The loader reads that param and runs the server function, so loading the page with ?user=ErikCH in the URL loads the profile directly, with no extra client wiring. The lookup is shareable and survives a refresh, and I never wrote client state to make that happen. You can plug in Zod if you want richer schemas.

Feature 3: Type safety that runs end to end by default

Typed navigation by itself isn't unique, and I want to be straight about that. Next.js has typedRoutes for statically typed links, and Nuxt has typed navigation built in through experimental.typedPages, plus the nuxt-typed-router module for more. So all three can stop you from typoing a route.

The difference is how far the chain reaches and how much setup it takes. Next's typedRoutes types the path, not the search param values. Nuxt's typed pages are opt-in and cover routes and params. In TanStack it's on by default, and the same type system covers your route params, your search params, and your loader data in one connected chain.

const navigate = useNavigate({ from: Route.fullPath })

function lookup(e: React.FormEvent) {
  e.preventDefault()
  navigate({ search: { user: input.trim() } })  // typed: { user: string }
}

If I pass a search param that doesn't exist, or the wrong type, the type checker flags it. Vite itself transpiles TypeScript without type checking, so this is tsc --noEmit (I keep it in a typecheck script and run it in CI) or your editor catching it inline. And because the loader's return type flows into Route.useLoaderData(), the data I render is typed by the same chain that typed the navigation. That whole path, from the server function return through the loader, the search params, and the link, is one thing instead of three features you wire up separately.

Adding in AI

I lean on AI coding assistants like Kiro for a lot of my code, and TanStack Start is new enough that the models don't have great knowledge on it. When I asked for a server function, I'd sometimes get an older API shape back, because the training data is behind.

TanStack ships a fix for exactly this, and it's the last thing I showed in the video. There's a package called TanStack Intent that wires your coding agent into current TanStack patterns. You install it like this:

npx @tanstack/intent@latest install

That creates or updates your agent config, defaulting to AGENTS.md (it can target others like CLAUDE.md or .cursorrules too), with skill-loading instructions. Your agent reads it, sees which TanStack skills are available, and pulls the current docs for whatever it's working on instead of guessing from stale training data.

So I opened Kiro CLI, which picks up that AGENTS.md on its own, and gave it this:

Please review my existing repository against the newly loaded TanStack Intent rules. Check my implementation for anti-patterns, missing edge cases, or deprecated syntax.

It worked through the skills and came back with a list, a couple of verbatimModuleSyntax notes, some dev-tools setup for TanStack Start, a shell component thing. One last thing, I wasn't pinning the latest version tags in my package.json. Though not really required all the time, I did like how it was looking at the package.json file in general.

The second guardrail is the type safety from earlier. When the AI guessed an old createServerFn shape, tsc and my editor flagged it right away. I didn't have to catch it in review. The types caught it for me.

This is the same point I made in my Vue in the Age of AI video. AI writes more of our code now, so the frameworks that verify the AI's work for you are worth more than they used to be.

Cleanup

Nothing to tear down for local development. Stop the dev server with Ctrl+C. If you deployed, TanStack Start uses Nitro under the hood, so you can remove whatever Node target you set up. Those hosting resources can incur charges, so tear them down if you were only testing.

Conclusion

So is it kind of a big deal? I'd put it this way. If you want explicit control, fast Vite builds, and type safety that runs from the server function through search params to your links, TanStack Start is genuinely the most compelling React framework I've tried in a while. The server functions and typed search params alone are just really nice to have.

It's not for everyone yet. The ecosystem is smaller than Next.js, there are fewer plugins and it's young. The TanStack CLI is still marked alpha, there are fewer production references to learn from, and the deployment and debugging knowledge isn't as standardized as Next.js. If you need the hiring pool and the deployment story Next.js has, that's a real reason to wait.

But "the default React framework is finally in question" is true for the first time in years, and after building with it, I get why people are switching. If you're a Nuxt person like me, the typed search params and server functions will feel like the things you wish you had without reaching for extra modules.

Resources:

Mastering the Latest TypeScript: What's New in 6.0 (and a Peek at 7)

Erik Hanchett — Thu, 04 Jun 2026 17:01:27 +0000

TypeScript 6.0 has been out for a few months now, and it's a bit of an unusual release. It's the last compiler that will be written in TypeScript and JavaScript. Later this year, TypeScript 7 arrives with the compiler rewritten in Go. Microsoft has seen roughly 10x speed improvements on large codebases. That makes 6.0 the bridge release.

The good news is that the features I want to show you aren't going anywhere. Everything here is forward compatible with TypeScript 7. They're also just genuinely nice to use. I'll walk through five additions worth adopting today, show the tsconfig.json changes that add them, and finish with what the Go rewrite means for you.

If you'd rather watch than read, the full video is here.

Prerequisites

Node.js 20 or newer
TypeScript 6.0 (npm install -D typescript@6)
A code editor with TypeScript support (I'm using Kiro)
Basic familiarity with tsconfig.json

1. Native Temporal date and time types

The built-in JavaScript Date API isn't that great. Months are zero-indexed, time zone handling is painful, and most of us reach for an API library to help. TypeScript 6 ships type support for Temporal, the TC39 date/time API, so you get a modern API with no extra dependency.

Creating a date is readable now. You pass the year, month, and day as named fields instead of memorizing argument order.

const launch = Temporal.PlainDate.from({ year: 2026, month: 9, day: 1 });

// Arithmetic that reads the way you think about it
const twoWeeksLater = launch.add({ weeks: 2 });
const aMonthEarlier = launch.subtract({ months: 1 });

Time zones are really neat to use. You can format the same instant across several zones without juggling offsets by hand.

const now = Temporal.Now.zonedDateTimeISO("America/Los_Angeles");

const zones = ["America/Los_Angeles", "America/New_York", "Europe/London", "Asia/Tokyo"];
for (const zone of zones) {
  const local = now.withTimeZone(zone);
  console.log(zone, local.toLocaleString());
}

And duration math, the thing that usually sends you to a library, is built in.

const today = Temporal.Now.plainDateISO();
const target = Temporal.PlainDate.from("2026-09-01");
const diff = today.until(target, { largestUnit: "day" });

console.log(`${diff.days} days until launch`);

You get all this without a date library, and you avoid the off-by-one month bugs that Date gives you. This is the feature I expect people to adopt first.

2. Map.getOrInsert() and getOrInsertComputed()

If you work with Map, you know the check-then-set code you have to write. You want to insert a value only if the key isn't already there, so you write something like this.

const cache = new Map<string, number>();

if (!cache.has("a")) {
  cache.set("a", 1);
}
const value = cache.get("a")!; // non-null assertion because get() can return undefined

Two things bother me there. The if guard is boilerplate, and the ! non-null assertion exists only because get() is typed to possibly return undefined. TypeScript 6 adds Map.getOrInsert(), which adds all of that into one call.

const cache = new Map<string, number>();

const value = cache.getOrInsert("a", 1); // returns 1, inserts if missing
cache.getOrInsert("a", 99);              // key exists, so this is ignored
console.log(cache.get("a")); // still 1

It checks for the key, returns the existing value if present, and inserts only when the key is missing. You don't overwrite anything, and the guard and the assertion both go away.

There's a companion method, getOrInsertComputed(), that takes a factory function instead of a value. The function only runs when the key is actually missing.

const cache = new Map<string, number>();

cache.getOrInsertComputed("a", () => {
  console.log("computing a");
  return 1;
}); // logs "computing a", inserts 1

cache.getOrInsertComputed("a", () => {
  console.log("this never runs");
  return 2;
}); // key already exists, so the factory is skipped entirely

That second factory never executes. If your value is expensive to produce, a database call, a heavy calculation, parsing something large, getOrInsertComputed() skips the work entirely when the key already exists. getOrInsert() evaluates its argument no matter what, so reach for the computed version when the value isn't cheap.

3. RegExp.escape() for safe dynamic regex

Building a regular expression from user input is a classic problem that we all run into. Say you take a version string and try to match it.

const userInput = "1.0";
const pattern = new RegExp(userInput, "g");

const text = "version 1.0 and build 1x0 are different";
console.log(text.match(pattern)); // matches BOTH "1.0" and "1x0"

That matches more than you wanted. The . in the input is a regex wildcard, so it matches any character, including the x in 1x0. TypeScript 6 adds RegExp.escape(), which escapes special characters in a string so it's treated literally.

const userInput = "1.0";
const pattern = new RegExp(RegExp.escape(userInput), "g");

const text = "version 1.0 and build 1x0 are different";
console.log(text.match(pattern)); // matches only "1.0"

Now the dot is a literal dot, and you match exactly what you meant. Any time you build a regex from a value you didn't write yourself, wrap it in RegExp.escape().

4. The `#` subpath imports (and the tsconfig that powers them)

Deep relative imports like ../../../utils/format are hard to read and break when you move files. The common fix is a path alias with @, but that can collide with real npm packages, since plenty of scoped packages start with @. TypeScript 6 leans into Node's subpath imports, which use a # prefix that can't be confused with a package name.

Setup happens in two files. First, tsconfig.json needs a module resolution mode that understands subpath imports.

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler"
  }
}

If you're not using a bundler, the Node-native equivalent works too.

{
  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext"
  }
}

Then you declare the actual mapping in package.json under imports.

{
  "imports": {
    "#utils/*": "./src/utils/*.js",
    "#components/*": "./src/components/*.js"
  }
}

Now your imports are clean.

import { formatDate } from "#utils/format";
import { Button } from "#components/Button";

Without one of those module resolution settings, the # imports won't resolve, so the tsconfig change is the part that actually unlocks the feature. If you watched my earlier video on tsconfig paths, this is the modern, standardized version of that same idea.

5. Smarter generic inference

This one removes annotations you used to have to write by hand. Take a generic interface like this.

interface CreatePair<T> {
  config: { value: T };
  consume: (value: T) => void;
}

Before TypeScript 6, you usually had to pin the generic explicitly when you used it.

const pair: CreatePair<number> = {
  config: { value: 42 },
  consume: (value) => console.log(value),
};

TypeScript 6 infers T from the value you provide, so the annotation becomes optional.

const pair = {
  config: { value: 42 },        // T inferred as number
  consume: (value: number) => console.log(value),
};

Because the compiler reads 42 and figures out the type, you write less and still get full type safety and autocomplete everywhere. It's a small change you'll feel constantly in real code.

tsconfig.json changes worth making now

Beyond the subpath imports config above, TypeScript 6 shifts a few defaults in a direction that TypeScript 7 will push as well. A few minutes auditing your config today saves friction later.

strict now defaults to true. If you've explicitly set strict: false, you're working against where the language is heading. This is a good moment to enable it or write down why you're opting out.
verbatimModuleSyntax: true is encouraged and replaces the older importsNotUsedAsValues. It forces explicit import type for type-only imports, which keeps your emitted output predictable.
baseUrl is no longer required for paths to work. If you only kept baseUrl around to enable path aliases, you can drop it.
moduleResolution: "node" is on its way out. If you're still on the legacy resolver, 6.0 is the time to move to nodenext or bundler.

What's coming in TypeScript 7

TypeScript 7 is the headline behind all of this. The compiler is being rewritten in Go (the project codename is Corsa), and the speed gains look impressive. The Go compiler parallelizes across CPU cores, so the bigger your codebase, the more you benefit.

Wrapping up

TypeScript 6 isn't a flashy release, and that's the point. Temporal, the new Map methods, RegExp.escape(), subpath imports, and smarter inference all make day-to-day code a little cleaner, and none of it gets in your way when you move to 7. The single most valuable thing you can do today is adopt these APIs and audit your tsconfig.json so the Go-compiler upgrade is a non-event.

I also built an experimental skill that helps you upgrade older TypeScript projects to 6.0. If you use Kiro, Claude Code, or another agentic editor, give it a try on a TypeScript 5 project and let me know how it goes. The link is in the video description.

Watch the full walkthrough on YouTube, and drop a comment if you've started using any of these in your own projects.

Your Default Vite Config Is Not Enough (New with Vite 8)

Erik Hanchett — Mon, 25 May 2026 17:14:13 +0000

Introduction

Last week I was at Vueconf US. It's one of my favorite conferences and I try to go every year. This year Evan You gave a talk on the future of Vue and tooling. Halfway through he started talking about Vite and some of the new features of Vite 8 that just came out. I was amazed at how far Vite has come and the millions of downloads a month it's getting. What I found especially interesting was how few people really knew about these features. Evan asked the audience by a show of hands who had tried out Vite 8, and only a few people raised their hands! So when I got home I decided to write this blog post and create a video on some configurations you must try out with Vite, including some new features that just came out with Vite 8.

If you haven't heard yet, Vite 8 shipped in March 2026 with the most significant architectural change since Vite 2. One of the most significant is the Rust-based bundler called Rolldown that delivers 10-30x faster builds. If you've been using Vite with zero config, that's fine. The defaults are great. However, there are a handful of options that, once you know them, you'll reach for in every project.

This post covers 8 config options that you should know. Two are new in Vite 8, and six have been around but you probably have not heard of them. All of them go in your vite.config.ts.

I put this post together using Kiro, an AI-powered IDE. The forwardConsole option in section 1 is something Kiro benefits from directly.

I also made a video covering all of these with a live demo. Check it out if you prefer watching over reading:

Prerequisites

Node.js 20.19+ or 22.12+ (required by Vite 8)
A Vite project (any framework)

To upgrade to Vite 8:

npm install vite@latest

Steps

1. server.forwardConsole

New in Vite 8. When you enable this, browser console errors and warnings show up in your Vite terminal instead of only in DevTools.

export default defineConfig({
  server: {
    forwardConsole: true,
  },
})

It's useful when you're working with AI coding agents that can't see the browser, or when you just want to keep your eyes on the terminal instead of switching to DevTools. Vite auto-enables it when it detects an AI coding agent via @vercel/detect-agent. Otherwise it defaults to false.

You can get more granular with it too:

server: {
  forwardConsole: {
    unhandledErrors: true,
    logLevels: ['warn', 'error'],
  },
}

The output includes source-mapped stack traces, so you see the original TypeScript line numbers, not the compiled output.

2. resolve.tsconfigPaths

Also new in Vite 8. Before this you had to install the vite-tsconfig-paths plugin to use TypeScript path aliases. Now it's built in and works in both the dev server and build.

export default defineConfig({
  resolve: {
    tsconfigPaths: true,
  },
})

One setup mistake I see a lot: make sure paths is inside compilerOptions, not at the top level of the JSON. Easy to get wrong when editing by hand:

// wrong — paths at top level, ignored by Vite
{
  "files": [],
  "paths": { "@/*": ["./src/*"] },
  "references": [{ "path": "./tsconfig.app.json" }]
}

// correct — paths inside compilerOptions
{
  "files": [],
  "references": [{ "path": "./tsconfig.app.json" }],
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"],
      "@components/*": ["./src/components/*"]
    }
  }
}

There's a small performance cost, so it's opt-in rather than the default. The TypeScript team also notes that paths is intended to inform TypeScript about mappings handled by other tools, not to change emit behavior. Still, I think it's well worth trying out.

resolve.alias vs resolve.tsconfigPaths: which should you use?

	`resolve.alias`	`resolve.tsconfigPaths`
Config location	`vite.config.ts`	`tsconfig.json`
Works with plain JS	✅	❌
Single source of truth	❌	✅
Requires Vite 8	❌	✅ (built-in)
Performance cost	None	Small

Use tsconfigPaths if you want one place to define aliases and you're already on TypeScript. Use alias for plain JS projects, monorepos, or when you want aliases independent of TypeScript's config.

3. server.proxy

I don't see a lot of developers using this one. The proxy isn't really about fixing CORS. It's about making your dev environment behave like production.

In production, your frontend and API are usually on the same domain. They might have the same origin, so CORS is not needed. For example, in dev, your frontend may be on localhost:5173 and your backend on localhost:8080. If you have different ports, and different origins, tne you'll get a CORS error. The proxy closes helps fix this.

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
    },
  },
})

Any request to /api/* gets forwarded to http://localhost:8080/*. The browser only ever sees localhost:5173, so no cross-origin request and no CORS error.

A few other reasons to reach for it:

Working against a teammate's service or a third-party API that hasn't added localhost to their CORS config? You can't change their server, but you can proxy through Vite.
Adding Access-Control-Allow-Origin: localhost:5173 to your backend is a dev concern leaking into prod config. The proxy keeps that out entirely.
You can inject auth headers for external services in the proxy configure callback, keeping them out of the browser bundle. This is dev-only though. For production, handle auth server-side.

changeOrigin: true makes the request appear to come from the target host, which some backends require. rewrite strips the /api prefix before forwarding.

4. server.hmr.overlay

By default, Vite shows a full-screen red overlay when there's a server error. Runtime errors, HMR failures, and transform errors all trigger it. If you find it disruptive while editing, you can turn it off.

export default defineConfig({
  server: {
    hmr: {
      overlay: false,
    },
  },
})

Errors still appear in the terminal and browser console. Turn it off when you're doing UI-heavy work and the overlay keeps blocking the component you're editing. I've been turning the overlay off a lot when I work. It's been so much nicer. Leave it on if you like the overlay.

5. resolve.alias

While I prefer the tsconfigpaths, sometimes you have to use resolve.alias instead. It is the explicit way to set up import shortcuts without touching tsconfig at all. It's great for JS projects, monorepos, or when you want aliases that aren't tied to TypeScript's path resolution.

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, 'src'),
      '@components': path.resolve(__dirname, 'src/components'),
      '@utils': path.resolve(__dirname, 'src/utils'),
    },
  },
})

Use path.resolve (or fileURLToPath with ESM) to get a proper absolute path. Passing a bare string like '/src' resolves to the filesystem root on most systems, not your project root.

6. server.open

I've been really liking this option. Yes it's small but once you turn it on, you'll never turn it off (at least most of the time). Set server.open: true and Vite opens your browser automatically when the dev server starts.

export default defineConfig({
  server: {
    open: true,
  },
})

You can also pass a path string to land on a specific route:

server: {
  open: '/dashboard',
}

Pairs well with conditional config (see the Bonus section) so you can set open only when running vite dev, not during build.

7. build.sourcemap

By default, Vite doesn't generate sourcemaps for production builds, so errors in production point at minified output. Turn this on and stack traces point at your actual source files.

FYI: Source maps are turned on for dev builds, so don't accidentaly turn this on by accident and leak your source code in production!

export default defineConfig({
  build: {
    sourcemap: true,
  },
})

Run npm run build then npm run preview (preview runs vite preview). Open DevTools, go to Sources, and you'll see your actual .vue and .ts files. Click any line in a stack trace and it jumps to the original source. This is perfect for debugging and adding in break points.

Three modes are available:

build: {
  sourcemap: true,      // separate .map files alongside the bundle
  sourcemap: 'inline',  // sourcemap embedded directly in the JS file
  sourcemap: 'hidden',  // .map files generated, no reference in the bundle
}

'hidden' is useful if you're uploading sourcemaps to an error monitoring service like Sentry. They can decode your stack traces server-side without the browser ever loading the maps. One thing to know: 'hidden' only removes the //# sourceMappingURL= comment from the bundle. The .map files are still generated and will be deployed alongside your JS unless you explicitly exclude them. If you want them truly private, add a step to strip *.map files before uploading. Otherwise your source maps might leak to production!

8. envPrefix

Occasionally I look for this one, it's useful when I'm migrating code and the prefixs are different. By default, Vite only exposes env variables prefixed with VITE_ to your client code. Everything else in your .env file stays server-side. envPrefix lets you change that prefix.

export default defineConfig({
  envPrefix: 'PUBLIC_',
})

With this set, your .env file might look like:

PUBLIC_API_URL=https://api.example.com
PUBLIC_APP_NAME=My App
SECRET_DB_PASSWORD=supersecret

And in your components:

import.meta.env.PUBLIC_API_URL   // "https://api.example.com"
import.meta.env.PUBLIC_APP_NAME  // "My App"
import.meta.env.SECRET_DB_PASSWORD // undefined, never sent to the browser

Only variables matching your prefix make it into the bundle. Everything else is stripped at build time, even if it's in the same .env file.

If you're migrating from Create React App (REACT_APP_) or Next.js (NEXT_PUBLIC_), you can match your existing naming convention instead of renaming every variable. You can also pass an array to expose multiple prefixes:

envPrefix: ['PUBLIC_', 'APP_']

Bonus: conditional config and define

This bonus is more for the advanced users out there! If you are let me know in the comments! You can pass a function to defineConfig instead of an object. It receives command ('serve' or 'build') and mode ('development' or 'production'), so you can change config based on context:

export default defineConfig(({ command, mode }) => ({
  server: {
    open: command === 'serve',
  },
  build: {
    sourcemap: mode !== 'production',
  },
}))

define bakes global constants into the build at compile time. Values are inlined directly into the output, so there's no runtime cost:

define: {
  __APP_VERSION__: JSON.stringify('1.0.0'),
  __BUILD_DATE__: JSON.stringify(new Date().toISOString()),
}

Add type declarations to vite-env.d.ts so TypeScript knows about them:

declare const __APP_VERSION__: string
declare const __BUILD_DATE__: string

Cleanup

Most of these are config-only changes. A few touch other files: tsconfigPaths requires paths in your tsconfig.json, envPrefix pairs with a .env file, and define needs type declarations in vite-env.d.ts. To revert any option, remove it from vite.config.ts and Vite falls back to its defaults.

Frequently Asked Questions

Why aren't my TypeScript path aliases working in Vite?
Make sure paths is inside compilerOptions in your tsconfig.json, not at the top level. Vite 8's built-in resolve.tsconfigPaths: true reads from compilerOptions.paths only. A top-level paths key is silently ignored.

What's the difference between resolve.alias and resolve.tsconfigPaths in Vite?
resolve.alias is defined directly in vite.config.ts and works for any project including plain JavaScript. resolve.tsconfigPaths reads aliases from your tsconfig.json and requires TypeScript. Use tsconfigPaths if you want a single source of truth; use alias for JS projects or monorepos.

Does Vite's server.proxy fix CORS errors?
Yes, but the real purpose is making dev match production. The proxy routes requests through the Vite dev server so the browser never makes a cross-origin request. No CORS header needed on your backend. It's cleaner than adding Access-Control-Allow-Origin: localhost:5173 to your server config.

Are Vite production sourcemaps safe to deploy?
sourcemap: 'hidden' generates .map files without referencing them in the bundle, so browsers won't load them. You can upload them to Sentry or similar for private stack trace decoding. Note: the .map files are still built and will be deployed unless you add a step to strip *.map files before uploading.

What env variables does Vite expose to the browser?
Only variables prefixed with VITE_ by default (or your custom envPrefix). Everything else in .env is stripped at build time and never sent to the browser. That includes secrets like database passwords or API keys that don't have the prefix.

Does server.forwardConsole work with all frameworks?
Yes, it's a Vite dev server feature, not framework-specific. It works with Vue, React, Svelte, and any other Vite-based setup. Vite auto-enables it when it detects an AI coding agent via @vercel/detect-agent; otherwise it defaults to false.

Conclusion

forwardConsole and tsconfigPaths are both opt-in and default to false. The others (proxy, hmr.overlay, resolve.alias, server.open, build.sourcemap, envPrefix) have been around for a while but are easy to miss if you've never needed them.

The full demo project is available at https://github.com/ErikCH/vite-config-tips.

Here is me speaking at VueConf this year!

Written by Erik Hanchett, AWS Developer Advocate. He covers frontend development, AWS, and AI/agents at programwitherik.com.

DEV Community: Erik Hanchett

Nuxt 4.5 SSR Streaming Is Kind Of A Big Deal

Prerequisites

Feature 1: Experimental SSR streaming

Create a controlled slow component

Enable streaming in production

Compare the responses

Check the production constraints

Feature 2: Read the resolved layout with useLayout()

Feature 3: Render multiple outlets with named views

Finale

Resources

How To learn Web Development in 2026

Start with a goal, not a curriculum

Decide how much you actually need to know

Ask three models what they'd build today

Get a personalized learning path

Build it: I do, we do, you do

I do: let it build, then read it

We do: spec-driven development

You do: turn it off

Two more patterns worth stealing

Where I've landed

7 Kiro Features You're Probably Not Using

1. Stop approving every single command

2. The # menu is bigger than #file in the IDE

3. Pick a workflow instead of freeform chatting

4. Skills are slash commands

5. You might be running an old build

6. The work doesn't have to run on your laptop

7. The experimental stuff is opt-in and worth trying

A few more worth a mention

Where to go when you're stuck

Nuxt vs SvelteKit: What works better?

The setup

The numbers

The Nuxt version: explicit API routes

The SvelteKit version: remote functions

What does Nuxt 5 offer?

My verdict

How I Used Spec-Driven Development to Build a Game (TanStack Start)

What is spec-driven development?

The trade-offs

The project: a Kiro birthday game

How I used SDD to build it

The tools that made it easier

Wrapping up

TanStack Start vs Nuxt: One Framework to rule them all?

The app

Difference one: server functions vs server routes

Server components in both

Typed search params

What they actually share

Links

The verdict

Loop Engineering: Do Frontend and Fullstack Devs Actually Need It?

Introduction

What loop engineering actually is

It's the agentic loop you already know

A practical example: fixing a PR on a loop

Automations are the other big use case

My take

3 Tools That Make AI Suck Less at Coding

Prerequisites

Find the mess: Fallow

Bonus: Knip

Review the diff: CodeRabbit

Measure the improvement: Kiln

How to pick

Conclusion

The most popular AI coding skills right now

Introduction

What is an agent skill?

The big workflow skills

Superpowers (obra/superpowers)

The Karpathy guidelines (multica-ai/andrej-karpathy-skills)

Matt Pocock's skills (mattpocock/skills)

GStack (garrytan/gstack)

GSD Core (open-gsd/gsd-core)

Framework skills and the "ships with your package" model

Feature 2: Read the resolved layout with `useLayout()`

2. The `#` menu is bigger than `#file` in the IDE

4. The `#` subpath imports (and the tsconfig that powers them)