AutoGineer
Generated banner for Deno Frontend
Generated logo for Deno Frontend

Deno Frontend

DenoOfficialCreated by denolandDistributed by Deno

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

Use when building a web frontend with Deno — running React, Vite, Astro, SvelteKit, Next.js, Nuxt or other npm frameworks under Deno, or working with Fresh, Deno's own island-architecture framework. Covers which path to pick, Fresh 2.x routes, handlers, islands, Preact signals, Tailwind, and Fresh 1.x to 2.x migration.
— the description by denoland

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides guidance on developing web frontends within the Deno ecosystem. It distinguishes between two primary approaches: using standard npm-based frameworks (like React, Vite, Astro, or Next.js) which run natively in Deno, and using Fresh, Deno's own island-architecture framework. The documentation covers project setup, configuration, and migration paths for Fresh 2.x, including details on routing, handlers, and state management.

What it does

  • Explains how to run popular npm frontend frameworks using Deno's native task runner.
  • Provides setup instructions for Fresh, Deno's server-side rendering framework.
  • Details the project structure for Fresh 2.x applications.
  • Outlines the migration process from Fresh 1.x to 2.x.
  • Describes how to handle routing, data fetching, and state in Fresh.
  • Offers configuration tips for integrating tools like Tailwind CSS with Deno.

When to use it

  • When starting a new web project and deciding between standard npm frameworks or Deno's Fresh.
  • When you need to run existing React, Vite, or Next.js projects using Deno.
  • When building a new Deno-first application that requires server-side rendering.
  • When upgrading an existing Fresh 1.x project to the 2.x version.
  • When you need to understand how to structure routes, islands, and handlers in Fresh.

Advantages

  • Seamless integration with the existing npm frontend ecosystem.
  • Minimal client-side JavaScript overhead via Fresh's island architecture.
  • Clear guidance on project configuration and dependency management.
  • Automated migration tools for upgrading legacy Fresh projects.
  • Consistent patterns for server-side data handling and routing.

Usage examples

“How do I start a new Vite project using Deno?”
You can use 'deno create vite my-app', followed by 'deno install' and 'deno task dev' to run the project.
“How do I migrate my Fresh 1.x project to 2.x?”
Run 'deno run -Ar jsr:@fresh/update' to automatically convert imports, update handler signatures, and switch to the Vite-based build system.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/denoland/deno-frontend/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip deno-frontend.zip -d .agents/skills

Documentation by denoland

Frontend development with Deno

Two paths. Pick by what the project already uses.

Regular npm frameworks — the usual choice

Deno runs the normal frontend ecosystem: React, Vue, Svelte, Solid, Vite, Astro, Next.js, Nuxt, SvelteKit, Remix, SolidStart. Nothing needs to be ported, and there is no Deno-specific way to write them.

deno create vite my-app     # or astro, next, nuxt, svelte…
cd my-app
deno install
deno task dev

deno create is npm create. deno install reads package.json. deno task <script> runs package.json scripts. That is the whole difference.

Follow the framework's own documentation for everything else — routing, components, data loading, and config are the framework's concern, not Deno's. Don't invent Deno-flavoured variants of their APIs, and don't reach for Fresh patterns in a React or Svelte project.

The only things worth knowing:

  • Some frameworks need "nodeModulesDir": "auto" in deno.json; Next.js does.

  • Permissions apply to the dev server too — framework tasks generally want -A.

  • Deploying: see the deno-deploy skill, which lists per-framework build commands and presets.

Fresh — Deno's own framework

Fresh suits a new Deno-first project that wants server rendering with minimal client JavaScript. It uses island architecture: pages render on the server, and only components in islands/ ship JavaScript.

deno run -Ar jsr:@fresh/init
cd my-project
deno task dev                # http://localhost:5173

A Fresh project is Vite-based: vite.config.ts for the build, main.ts for the server, file-based routes in routes/, islands in islands/, server-only components in components/. Preact supplies the component model, with signals for state.

// islands/Counter.tsx — interactive, ships JS
import { useSignal } from "@preact/signals";

export default function Counter() {
  const count = useSignal(0);
  return <button onClick={() => count.value++}>Count: {count.value}</button>;
}

Three rules carry most of the weight:

  1. Islands ship JavaScript — keep them small, leave everything else in components/.

  2. Island props must be serializable. Functions cannot be passed.

  3. Handlers take a single (ctx) parameter.

Load references/FRESH.md for routes, handlers, define helpers, middleware, islands, signals, and Tailwind.

Use Fresh 2.x, imported from "fresh". For an existing 1.x project, or one pinned to a 2.0.0-alpha.* release, see references/FRESH_MIGRATION.md.

Further reading

  • https://fresh.deno.dev/docs — Fresh documentation

  • references/FRESH.md — Fresh 2.x patterns in depth

  • references/FRESH_MIGRATION.md — Fresh 1.x and alpha migration

Files

references/FRESH_MIGRATION.md

Fresh 1.x and alpha migration

Check the version first

Read deno.json imports before changing anything. Three situations look similar and need different handling:

deno.json saysSituation
jsr:@fresh/core@^2Stable 2.x — see FRESH.md
jsr:@fresh/[email protected].*Alpha 2.x — not 1.x, see below
$fresh/ import pathsFresh 1.x — migrate

Grep for $fresh/ to find 1.x imports; every one of them becomes fresh or fresh/runtime.

Migrating 1.x to 2.x

Run the migration tool:

deno run -Ar jsr:@fresh/update

It converts import paths to the fresh package, updates handler signatures to the single (ctx) parameter, removes the generated manifest and legacy config and dev entry points, creates vite.config.ts and client.ts, switches deno.json tasks to Vite, merges the separate error pages into a unified _error.tsx, and updates deprecated context methods.

If it misses anything, check by hand:

  1. Imports — everything from fresh or fresh/runtime.

  2. Handlers — single (ctx) parameter, request via ctx.req.

  3. Files — no generated manifest, dev entry point, or old config file.

  4. Tasks — vite, vite build, deno serve -A _fresh/server.js.

  5. Error pages — one _error.tsx replaces the separate _404.tsx and _500.tsx.

  6. Tailwind — @tailwindcss/vite, not the old Fresh Tailwind plugin.

Deprecated context APIs
1.x2.x
renderNotFound()throw new HttpError(404)
bare render() with no JSXctx.render(<MyComponent />)
basePathctx.config.basePath
data passed through ctx.render()handler returns { data: {...} }

The last one is the most common error. ctx.render() takes JSX, never a data object — a handler passes data by returning { data: {...} }, and the page picks it up with define.page<typeof handler>. See FRESH.md.

Alpha releases (2.0.0-alpha.*)

Alpha projects are 2.x, but predate the Vite setup. A dev.ts in an alpha project is correct, not a 1.x leftover — do not "fix" it.

AlphaStable 2.x
dev.ts entry pointvite.config.ts
deno run -A --watch dev.tsvite
deno run -A dev.ts buildvite build
@fresh/plugin-tailwind@tailwindcss/vite
dev server on port 8000port 5173
no client.tsclient.ts required

The handler pattern is already the same as stable: define.handlers({ GET(ctx) { ... } }) returning { data: {...} }.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
denoland
Publisher
Deno (Official)
Distributed by
Deno
Source
denoland/skills · skills/deno-frontend · commit d5f6ace
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by denoland or Deno.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download deno-frontend.zip