1 
2Jahrelang bedeutete die Wahl eines JavaScript-Web-Frameworks einen Kompromiss: Express war universell, aber langsam und an Node gebunden, Fastify war schnell, aber nur für Node, Next.js war vollständig, aber schwer. Mit dem Aufkommen von Edge-Runtimes - Cloudflare Workers, Deno Deploy, Bun, Vercel Edge - zeigten diese Frameworks ihre Grenzen: inkompatible Abhängigkeiten, riesige Bundles, an `req`/`res` gebundene APIs.
3 
4[Hono](https://hono.dev) (japanisch für "Flamme" 🔥) ist die moderne Antwort. Ein Framework unter 14KB, vollständig auf Web Standards (`Request`, `Response`, `fetch`) aufgebaut, das überall läuft, wo es eine JavaScript-Runtime gibt. Derselbe Code wird ohne Änderung auf Cloudflare Workers, Bun, Deno, Node.js, Vercel, Netlify und AWS Lambda deployt.
5 
6## Warum Hono
7 
8Hono macht drei Dinge besser als jeder andere:
9 
101. **Performance.** Der `RegExpRouter` kompiliert alle Route-Patterns zu einer einzigen Regex und vermeidet die linearen Schleifen traditioneller Router. Benchmarks zeigen über 400.000 Ops/s und reihen Hono unter die schnellsten Router des JavaScript-Ökosystems ein.
112. **Portabilität.** Web Standards bedeutet null Node-Abhängigkeiten. Dasselbe `app.fetch` wird als Default in einem Cloudflare Worker exportiert, an `Bun.serve` übergeben, in einem Deno-Server gemountet oder mit `@hono/node-server` adaptiert.
123. **TypeScript-First DX.** Path-Parameter als Literal-Types, ein End-to-End-typsicherer RPC-Client, Validatoren mit Input- und Output-Inferenz. Die Autovervollständigung ist nahezu telepathisch.
13 
14```mermaid
15graph LR
16    Client[Client] -->|Request| App[app.fetch]
17    App --> MW1[Middleware 1]
18    MW1 --> MW2[Middleware 2]
19    MW2 --> Router[RegExpRouter]
20    Router --> Handler[Route Handler]
21    Handler --> Context[c.json / c.text]
22    Context -->|Response| Client
23    App -.->|deploy| CF[Cloudflare Workers]
24    App -.->|deploy| Bun[Bun]
25    App -.->|deploy| Deno[Deno]
26    App -.->|deploy| Node[Node.js]
27    App -.->|deploy| Vercel[Vercel]
28```
29 
30## Erste Schritte
31 
32Der schnellste Weg ist der offizielle Starter, der das Projekt für die gewählte Runtime erstellt.
33 
34```bash
35npm create hono@latest my-api
36cd my-api
37npm install
38npm run dev
39```
40 
41Der Starter fragt nach einem Template: `cloudflare-workers`, `bun`, `deno`, `nodejs`, `vercel`, `aws-lambda`, `nextjs` und mehr. Er wählt passende Konfigurationen und Deploy-Skripte. Für einen schnellen Test reicht auch eine einzelne Datei:
42 
43```typescript
44// src/index.ts
45import { Hono } from 'hono'
46 
47const app = new Hono()
48 
49app.get('/', (c) => c.text('Hello Hono!'))
50 
51export default app
52```
53 
54Auf Cloudflare Workers reicht das. Auf Bun: `Bun.serve({ fetch: app.fetch, port: 3000 })`. Auf Node: `serve({ fetch: app.fetch })` aus `@hono/node-server`. Die Oberfläche ist identisch.
55 
56## Routing
57 
58Routes werden mit HTTP-Verb-Methoden deklariert und unterstützen Parameter, Wildcards und Regex.
59 
60```typescript
61import { Hono } from 'hono'
62 
63const app = new Hono()
64 
65app.get('/', (c) => c.text('Home'))
66app.get('/posts/:id', (c) => {
67  const id = c.req.param('id') // string, typisiert
68  return c.json({ id })
69})
70app.get('/posts/:id/comments/:commentId', (c) => {
71  const { id, commentId } = c.req.param()
72  return c.json({ id, commentId })
73})
74app.get('/files/*', (c) => c.text('Wildcard'))
75app.post('/posts', async (c) => {
76  const body = await c.req.json()
77  return c.json({ created: body }, 201)
78})
79```
80 
81Parameter werden als Literal-Types abgeleitet: TypeScript weiß, dass `c.req.param('id')` nur dann ein `string` zurückgibt, wenn `:id` im Pattern deklariert wurde. Ein Tippfehler ist ein Compile-Time-Error.
82 
83### Routes gruppieren
84 
85Mit `app.route()` lassen sich Sub-Anwendungen als Module komponieren, jede mit eigenem Präfix.
86 
87```typescript
88// routes/posts.ts
89import { Hono } from 'hono'
90 
91const posts = new Hono()
92posts.get('/', (c) => c.json({ posts: [] }))
93posts.get('/:id', (c) => c.json({ id: c.req.param('id') }))
94export default posts
95 
96// src/index.ts
97import { Hono } from 'hono'
98import posts from './routes/posts'
99 
100const app = new Hono()
101app.route('/posts', posts)
102```
103 
104Verschachtelte Routes erben den Base-Path und den Typ der Root-App, sodass der RPC-Client die gesamte Struktur sieht.
105 
106## Das Context-Objekt
107 
108Jeder Handler erhält ein `c` - den Context für die aktuelle Anfrage. Es ist die einzige API, die du lernen musst, um Eingaben zu lesen und Antworten zu produzieren.
109 
110```typescript
111app.post('/echo', async (c) => {
112  // Lesen
113  const userAgent = c.req.header('User-Agent')
114  const page = c.req.query('page')
115  const body = await c.req.json()
116  const env = c.env // Bindings (KV, D1, Secrets auf Cloudflare)
117 
118  // Variablen zwischen Middleware und Handler geteilt
119  c.set('requestId', crypto.randomUUID())
120  const id = c.get('requestId')
121 
122  // Antwort
123  c.header('X-Request-Id', id)
124  c.status(200)
125  return c.json({ userAgent, page, body, id })
126})
127```
128 
129Die wichtigsten Response-Methoden sind `c.text`, `c.json`, `c.html`, `c.body` (raw) und `c.redirect`. Alle akzeptieren einen Statuscode als zweites Argument.
130 
131## Middleware: das Onion-Modell
132 
133Middleware sind `(c, next) => ...`-Funktionen, die Code vor und nach dem Handler ausführen können. Komponiert ergeben sie das klassische Onion-Modell: die zuerst registrierte Middleware startet als erste und endet als letzte.
134 
135```typescript
136import { Hono } from 'hono'
137import { logger } from 'hono/logger'
138import { cors } from 'hono/cors'
139import { secureHeaders } from 'hono/secure-headers'
140 
141const app = new Hono()
142 
143app.use('*', logger())
144app.use('*', secureHeaders())
145app.use('/api/*', cors({ origin: 'https://spinny.dev' }))
146 
147app.use('*', async (c, next) => {
148  const start = performance.now()
149  await next()
150  c.header('X-Response-Time', `${performance.now() - start}ms`)
151})
152```
153 
154`await next()` übergibt die Kontrolle an die nächste Middleware. Alles, was danach kommt, läuft in der Response-Phase, nachdem der Handler ein Ergebnis produziert hat. Das Zurückgeben einer `Response` vor `next()` bricht die Kette ab.
155 
156### Eingebaute Middleware
157 
158Hono liefert eine reichhaltige Auswahl produktionsreifer Middleware aus, importierbar aus `hono/...`:
159 
160| Middleware | Zweck |
161|-----------|---------|
162| `logger` | Strukturierte Logs zu Methode, Pfad, Status, Dauer |
163| `cors` | CORS konfigurierbar nach Origin, Methoden, Headern |
164| `csrf` | Origin-basierter CSRF-Schutz |
165| `secureHeaders` | Setzt CSP, HSTS, X-Frame-Options |
166| `bearerAuth` / `basicAuth` | Bearer/Basic-Auth out of the box |
167| `jwt` | JWT-Verify/Sign mit `jose` |
168| `etag` | Generiert ETag und behandelt 304 |
169| `cache` | Caching über die Web Cache API |
170| `compress` | gzip/deflate auf der Response |
171| `bodyLimit` | Lehnt Bodies über einer Grenze ab |
172| `timing` | Server-Timing-Header für Profiling |
173 
174### Typsichere Custom-Middleware
175 
176Um den `Context` mit typisierten Variablen zu erweitern, nutze `createMiddleware`:
177 
178```typescript
179import { createMiddleware } from 'hono/factory'
180 
181type AuthVars = { userId: string; role: 'user' | 'admin' }
182 
183export const requireAuth = createMiddleware<{ Variables: AuthVars }>(
184  async (c, next) => {
185    const token = c.req.header('Authorization')?.replace('Bearer ', '')
186    if (!token) return c.json({ error: 'Unauthorized' }, 401)
187 
188    const payload = await verifyJwt(token)
189    c.set('userId', payload.sub)
190    c.set('role', payload.role)
191    await next()
192  }
193)
194 
195// Verwendung
196app.get('/me', requireAuth, (c) => {
197  const userId = c.var.userId // string, typisiert
198  return c.json({ userId })
199})
200```
201 
202Nach der Middleware ist `c.var.userId` ohne Cast typisiert. Das pflanzt sich durch die gesamte Kette fort.
203 
204## Validierung mit Zod
205 
206`@hono/zod-validator` bindet Zod in den Request-Zyklus ein. Du definierst ein Schema, wendest es auf die Route an und erhältst bereits validierte, typisierte Eingaben.
207 
208```typescript
209import { Hono } from 'hono'
210import { zValidator } from '@hono/zod-validator'
211import { z } from 'zod'
212 
213const createPost = z.object({
214  title: z.string().min(1).max(200),
215  body: z.string().min(1),
216  tags: z.array(z.string()).default([]),
217})
218 
219app.post(
220  '/posts',
221  zValidator('json', createPost),
222  (c) => {
223    const data = c.req.valid('json') // typisiert nach Schema
224    return c.json({ ok: true, post: data }, 201)
225  }
226)
227```
228 
229Schlägt die Validierung fehl, antwortet Hono mit 400 und dem Zod-Fehler, ohne den Handler aufzurufen. Du kannst auch `query`, `param`, `header`, `cookie` und `form` validieren.
230 
231## RPC: End-to-End-typsicherer Client
232 
233Das Feature, das Hono wirklich abhebt, ist der **RPC-Modus**. Du exportierst den Typ deiner App vom Server, der `hc`-Client importiert ihn und du erhältst vollständige Autovervollständigung - inklusive Pfade, Query, Body, Header und Response - ohne Codegen oder OpenAPI.
234 
235```typescript
236// server.ts
237import { Hono } from 'hono'
238import { zValidator } from '@hono/zod-validator'
239import { z } from 'zod'
240 
241const app = new Hono()
242  .get('/posts/:id', (c) =>
243    c.json({ id: c.req.param('id'), title: 'Hello' })
244  )
245  .post(
246    '/posts',
247    zValidator('json', z.object({ title: z.string(), body: z.string() })),
248    (c) => c.json({ ok: true }, 201)
249  )
250 
251export type AppType = typeof app
252export default app
253```
254 
255```typescript
256// client.ts
257import { hc } from 'hono/client'
258import type { AppType } from './server'
259 
260const client = hc<AppType>('https://api.spinny.dev')
261 
262const res = await client.posts[':id'].$get({ param: { id: '42' } })
263if (res.ok) {
264  const data = await res.json() // { id: string, title: string }
265  console.log(data.title)
266}
267 
268const created = await client.posts.$post({
269  json: { title: 'Hallo', body: 'Hono ist eine Flamme' }, // validiert
270})
271```
272 
273Benenne eine Route auf dem Server um und das TypeScript des Clients bricht sofort in CI. Derselbe Vorteil wie tRPC, aber über Standard-HTTP, ohne spezifische Middleware und mit einem winzigen Bundle.
274 
275### Statuscode-Diskriminierung
276 
277Wenn du verschiedene Status zurückgibst, diskriminiert der Client sie automatisch.
278 
279```typescript
280.get('/posts/:id', (c) => {
281  const post = findPost(c.req.param('id'))
282  if (!post) return c.json({ error: 'not found' }, 404)
283  return c.json({ post }, 200)
284})
285```
286 
287```typescript
288const res = await client.posts[':id'].$get({ param: { id } })
289if (res.status === 404) {
290  const { error } = await res.json() // { error: string }
291}
292if (res.status === 200) {
293  const { post } = await res.json() // { post: Post }
294}
295```
296 
297## Router und Performance
298 
299Hono bietet fünf Router mit verschiedenen Trade-offs. Default ist der `SmartRouter`, der beim Start misst, welcher Router deine Routes am besten bedient, und sich darauf festlegt.
300 
301| Router | Stärken | Wann einsetzen |
302|--------|---------|----------------|
303| `RegExpRouter` | Höchste Geschwindigkeit, kompilierte Regex | Default für die meisten APIs |
304| `TrieRouter` | Unterstützt jedes Pattern | Komplexe Patterns, die RegExp nicht abdeckt |
305| `SmartRouter` | Wählt automatisch den besten | Empfohlener Default |
306| `LinearRouter` | Ultraschnelle Registrierung | One-Shot-Worker, kritische Cold Starts |
307| `PatternRouter` | Kleinstes Bundle (<15KB) | Extreme Größenbeschränkungen |
308 
309Für stateless Worker mit häufigen Cold Starts vermeidet `LinearRouter` die initialen Kompilierungskosten und ist 33-mal schneller als `find-my-way`, wenn Registrierung plus Matching gemessen werden.
310 
311```typescript
312import { Hono } from 'hono'
313import { LinearRouter } from 'hono/router/linear-router'
314 
315const app = new Hono({ router: new LinearRouter() })
316```
317 
318## Multi-Runtime-Deployment
319 
320Dieselbe `export default app` wechselt das Ziel, indem nur die Entry-Datei getauscht wird.
321 
322### Cloudflare Workers
323 
324```typescript
325// src/index.ts
326import { Hono } from 'hono'
327 
328type Bindings = { MY_KV: KVNamespace; DB: D1Database }
329const app = new Hono<{ Bindings: Bindings }>()
330 
331app.get('/cache/:key', async (c) => {
332  const value = await c.env.MY_KV.get(c.req.param('key'))
333  return c.json({ value })
334})
335 
336export default app
337```
338 
339Deploy: `npx wrangler deploy`. KV/D1/R2/Queues-Bindings sind nativ.
340 
341### Bun
342 
343```typescript
344import { Hono } from 'hono'
345const app = new Hono()
346app.get('/', (c) => c.text('Bun + Hono'))
347 
348Bun.serve({ fetch: app.fetch, port: 3000 })
349```
350 
351### Node.js
352 
353```typescript
354import { serve } from '@hono/node-server'
355import { Hono } from 'hono'
356 
357const app = new Hono()
358app.get('/', (c) => c.text('Node + Hono'))
359 
360serve({ fetch: app.fetch, port: 3000 })
361```
362 
363### Deno
364 
365```typescript
366import { Hono } from 'jsr:@hono/hono'
367const app = new Hono()
368app.get('/', (c) => c.text('Deno + Hono'))
369Deno.serve(app.fetch)
370```
371 
372### Vercel
373 
374```typescript
375// api/[[...route]].ts
376import { Hono } from 'hono'
377import { handle } from 'hono/vercel'
378 
379const app = new Hono().basePath('/api')
380app.get('/hello', (c) => c.json({ msg: 'Hello from Vercel' }))
381 
382export const GET = handle(app)
383export const POST = handle(app)
384```
385 
386Gleicher Business-Code, gleiches Routing, gleiche Middleware. Nur der Adapter ändert sich.
387 
388## Praxisbeispiel: REST-API mit Auth und DB
389 
390Alles zusammengeführt. Eine Blog-API auf Cloudflare Workers + D1, mit JWT-Auth, Validierung und RPC.
391 
392```typescript
393import { Hono } from 'hono'
394import { jwt } from 'hono/jwt'
395import { logger } from 'hono/logger'
396import { cors } from 'hono/cors'
397import { zValidator } from '@hono/zod-validator'
398import { z } from 'zod'
399 
400type Bindings = { DB: D1Database; JWT_SECRET: string }
401type Variables = { jwtPayload: { sub: string } }
402 
403const app = new Hono<{ Bindings: Bindings; Variables: Variables }>()
404 
405app.use('*', logger())
406app.use('/api/*', cors({ origin: 'https://spinny.dev', credentials: true }))
407 
408const auth = (c: any, next: any) =>
409  jwt({ secret: c.env.JWT_SECRET })(c, next)
410 
411const api = app.basePath('/api')
412 
413api.get('/posts', async (c) => {
414  const { results } = await c.env.DB
415    .prepare('SELECT id, title, created_at FROM posts ORDER BY created_at DESC LIMIT 50')
416    .all()
417  return c.json({ posts: results })
418})
419 
420api.post(
421  '/posts',
422  auth,
423  zValidator('json', z.object({
424    title: z.string().min(1).max(200),
425    body: z.string().min(1),
426  })),
427  async (c) => {
428    const { title, body } = c.req.valid('json')
429    const userId = c.var.jwtPayload.sub
430    const result = await c.env.DB
431      .prepare('INSERT INTO posts (title, body, author_id) VALUES (?, ?, ?) RETURNING id')
432      .bind(title, body, userId)
433      .first<{ id: number }>()
434    return c.json({ id: result?.id }, 201)
435  }
436)
437 
438api.onError((err, c) => {
439  console.error(err)
440  return c.json({ error: 'Internal error' }, 500)
441})
442 
443export type AppType = typeof api
444export default app
445```
446 
447Ein React-Client konsumiert sie mit voller Typsicherheit:
448 
449```typescript
450import { hc } from 'hono/client'
451import type { AppType } from '../api/src/index'
452 
453const api = hc<AppType>(import.meta.env.VITE_API_URL)
454 
455const res = await api.posts.$post({
456  json: { title: 'Hono in 2026', body: '...' },
457}, {
458  headers: { Authorization: `Bearer ${token}` },
459})
460```
461 
462## Testing
463 
464`app.request()` erlaubt das Testen von Routes, ohne einen HTTP-Server zu starten. Es ist derselbe Pfad, den du in Produktion ausführen würdest, im Speicher ausgeführt.
465 
466```typescript
467import { describe, it, expect } from 'vitest'
468import app from '../src/index'
469 
470describe('GET /api/posts', () => {
471  it('liefert die Liste der Posts', async () => {
472    const res = await app.request('/api/posts')
473    expect(res.status).toBe(200)
474    const body = await res.json()
475    expect(body.posts).toBeInstanceOf(Array)
476  })
477})
478```
479 
480Auf Cloudflare Workers führt `@cloudflare/vitest-pool-workers` dieselben Tests in einem echten Worker mit Mock-Bindings aus - maximale Realität, kein Deploy.
481 
482## Best Practices
483 
484### 1. Route-Definitionen verketten
485 
486```typescript
487const app = new Hono()
488  .get('/posts', handler1)
489  .post('/posts', handler2)
490  .get('/posts/:id', handler3)
491```
492 
493Chaining hält den Typ von `app` mit jeder Route aktuell, was für den RPC-Client essenziell ist. Separate `app.get(...)`-Aufrufe in eigenen Zeilen brechen die Inferenz.
494 
495### 2. Den Typ exportieren, nicht die Implementierung
496 
497Der Client muss `AppType` importieren, nicht die App. `import type` stellt sicher, dass der Frontend-Build keinen Backend-Code enthält.
498 
499### 3. Ein Router pro Domäne
500 
501Eine Sub-App für `posts`, eine für `users`, eine für `webhooks`. Komponiere sie mit `app.route()` und jede besitzt ihre eigene Middleware. Die Struktur skaliert ohne Mega-Dateien.
502 
503### 4. Validierung am Rand, immer
504 
505Jede externe Eingabe (Body, Query, Header) muss durch `zValidator`. Vertraue Daten flussabwärts nicht: selbst ein TypeScript-Cast ohne Runtime-Validierung ist ein Bug, der nur darauf wartet zuzuschlagen.
506 
507### 5. Auf Bindings setzen, nicht auf globale Clients
508 
509Auf Cloudflare greife auf KV/D1/R2 über `c.env` zu. Keine globalen Singletons, keine Verbindungen, die zwischen Workern persistieren. Das stateless Modell ist ein Feature, keine Einschränkung.
510 
511### 6. Vor dem Optimieren des Routers messen
512 
513Der Default-`SmartRouter` reicht für 95 % der Fälle. Wechsle den Router erst nach dem Profiling und einem realen Bottleneck.
514 
515## Fazit
516 
517Hono ist 2026 zum De-facto-Standard geworden, um edge-fähige APIs in TypeScript zu bauen. Die Kombination aus Web Standards, Performance, Typsicherheit und Portabilität löst genau die Probleme, die traditionelle Frameworks zurückhielten: Runtime-Lock-in, schwere Bundles, fragiles Typsystem zwischen Client und Server.
518 
519Du nutzt es für Microservices auf Cloudflare Workers, um Express in einem Node-Monolithen zu ersetzen, für eine Function auf Vercel oder eine API auf Bun. Dasselbe Wissen lässt sich überall einsetzen - und das macht es zu einer soliden Investition für die kommenden Jahre.
520 
521> **Erste-Schritte-Checkliste:**
522>
523> - [x] `npm create hono@latest` und Runtime-Template wählen
524> - [x] Routes mit Chaining definieren (`.get(...).post(...)`)
525> - [x] `logger`, `cors`, `secureHeaders` als globale Middleware hinzufügen
526> - [x] Jeden Input mit `@hono/zod-validator` validieren
527> - [x] `AppType` exportieren und die API mit dem typsicheren `hc`-Client konsumieren
528> - [x] Tests mit `app.request()` schreiben - kein HTTP-Server nötig
529> - [x] Mit `wrangler deploy` (CF), `vercel deploy` oder dem Runtime-Bundler deployen
530