Express pochodzi z 2010 roku i do dziś nie ma wbudowanych typów TypeScript. Musisz doinstalować @types/express i liczyć na to, że deklaracje nadążają za rzeczywistością. NestJS rozwiązuje ten problem, ale dokłada warstwy dekoratorów, modułów i providerów — to poziom ceremoniału Angular dla projektów, które potrzebują kilku endpointów. Kiedy w 2024 roku zaczęliśmy stawiać backendy pod agentów AI, szukaliśmy czegoś, co startuje z TypeScript jako językiem pierwszej klasy, jest szybkie z założenia i nie wymaga trzech plików konfiguracyjnych dla jednej trasy.
Hono jest odpowiedzią na pytanie: jak wyglądałby framework webowy, gdyby ktoś zaprojektował go od zera w erze TypeScript i edge computing?
Czym jest Hono
Hono to ultra-lekki framework webowy ważący 14 KB. Nazwa pochodzi od japońskiego słowa oznaczającego płomień — co trafnie oddaje jego charakter: małe, gorące, szybkie.
To, co wyróżnia Hono na tle konkurencji, to multi-runtime support. Ten sam kod działa na Node.js, Deno, Bun, Cloudflare Workers i AWS Lambda bez żadnych modyfikacji. Piszesz raz, deployujesz wszędzie. Dla backendów AI, gdzie latencja ma znaczenie, możliwość postawienia tego samego kodu na edge Cloudflare — z punktami obecności w 300 miastach — jest realną przewagą.
TypeScript jest tu traktowany jako język, nie jako opcja. Typy są wnioskowane automatycznie przez całą warstwę routingu i middleware. Framework oferuje też wsparcie JSX dla server-side rendering oraz wbudowany system middleware, który pokrywa typowe potrzeby: CORS, autoryzacja, logowanie, kompresja.
Szybkość, która ma znaczenie
W benchmarkach HTTP Hono osiąga 3–4 razy wyższą przepustowość niż Express na tym samym sprzęcie. Na poziomie surowych liczb: Express obsługuje zwykle 40–60 tysięcy requestów na sekundę na pojedynczym wątku, Hono przekracza 150 tysięcy.
Dla prostego CRUD-a ta różnica nie ma znaczenia. Ale backend agenta AI to inna historia. Typowe wywołanie agentyczne to kilka równoległych zapytań do LLM, odpytanie bazy wektorowej, być może dodatkowe narzędzie zewnętrzne — wszystko w jednym flow. Przy 50 równoległych użytkownikach framework, który zajmuje mniej zasobów i oddaje event loop szybciej, przełoży się na mierzalnie niższe czasy odpowiedzi.
Definicja trasy w Hono wygląda jak Express, ale wszystko jest typowane od razu. Zamiast import express from 'express' piszesz import { Hono } from 'hono', tworzysz instancję app, rejestrujesz handler przez app.get lub app.post, a kontekst c daje ci c.req, c.json() i c.text() z pełnymi typami bez dodatkowej konfiguracji. Middleware tworzysz przez app.use() — identyczna składnia, zero pliku definicji typów do dogrania.
TypeScript od pierwszego dnia
Hono nie traktuje TypeScript jako nakładki na JavaScript. Typy są częścią projektu od pierwszego commita. Oznacza to, że parametry trasy, body requestu i odpowiedź są typowane end-to-end.
Integracja z Zod działa przez oficjalny pakiet @hono/zod-validator. Definiujesz schemat Zod, przekazujesz go jako middleware do trasy i walidacja dzieje się automatycznie przed wywołaniem handlera — z typowanym wynikiem dostępnym w kontekście. Nie ma potrzeby ręcznego parsowania i rzutowania.
Jeszcze dalej idzie hono/zod-openapi. Pozwala na deklaratywne opisanie tras razem ze schematem wejścia i wyjścia, a framework generuje z tego kompletną specyfikację OpenAPI 3.1. Dla AI agent API, które musi być opisane maszynom (i ludziom), to gotowe rozwiązanie bez dodatkowego narzędzia.
Brak @types/express nie jest stratą — to uproszczenie. Jeden ekosystem typów, jedna definicja kontekstu, jedno miejsce do sprawdzenia co jest dostępne w handlerze.
Dlaczego używamy Hono w MKM Labs
Przy wszystkich nowych projektach backendowych AI przestawiliśmy się na Hono jako domyślny framework. Nasz stack wygląda następująco: Hono jako warstwa HTTP, Drizzle ORM do typowanych zapytań SQL, PostgreSQL przez Supabase jako baza danych (z pgvector dla embeddingów), Anthropic SDK do integracji z modelami Claude.
Deployment trafia na Railway lub Fly.io. Środowisko lokalne chodzi na Node.js, ale te same pliki mogą wylądować na Cloudflare Workers dla tras, które wymagają minimalnej latencji — np. endpoint sprawdzający status agenta lub cache przechowujący ostatnie odpowiedzi.
Czas wdrożenia ma dla nas znaczenie. Projekt od zera do działającego backendu z uwierzytelnianiem, połączeniem do bazy i pierwszym endpointem agenta zajmuje u nas kilka godzin, nie kilka dni. Hono redukuje boilerplate do minimum, a pełna kompatybilność TypeScript oznacza, że błędy typów wyłapujemy w edytorze, nie na produkcji.
Kiedy jednak zostać przy Express lub Fastify
Hono nie jest odpowiedzią na każde pytanie.
Jeśli masz dużą, działającą aplikację Express z setkami middleware i lat długu technicznego — migracja jest ryzykiem bez proporcjonalnej korzyści. Express nadal działa, nadal jest utrzymywany, nadal ma ogromny ekosystem. Nie ma powodu przepisywać systemu, który działa.
Jeśli Twój zespół ma głębokie doświadczenie z Fastify i wypracowane procesy wokół jego ekosystemu — Fastify jest bardzo dobrym frameworkiem. Szybszy niż Express, dobrze typowany, dojrzały. Koszt zmiany technologii zawsze wchodzi do rachunku i nie zawsze jest uzasadniony.
Jeśli korzystasz z konkretnego middleware Express, który nie ma odpowiednika w Hono i napisanie własnego jest kosztem — to argument za pozostaniem. Ekosystem Hono rośnie szybko, ale nadal jest mniejszy niż ekosystem Express liczący ponad dekadę.
Hono sprawdza się najlepiej przy nowych projektach, greenfield, gdzie możesz zdecydować o stacku od zera — szczególnie jeśli tym projektem jest backend pod agenta AI, mikroserwis lub API z wymaganiami na latencję.
Budujesz backend AI i nie wiesz od czego zacząć? Porozmawiajmy — pokażemy Ci, jak stawiamy to w godziny, nie w tygodnie.
Potrzebujesz podobnego rozwiązania?
Porozmawiajmy o Twoim projekcie
Pierwsza rozmowa jest bezpłatna. Opisz nam swój pomysł — odpowiemy w ciągu jednego dnia roboczego.
Umów bezpłatną rozmowę