Introducción
Este es un starter full-stack construido sobre HonoX, que combina un sistema de estilos tipado con un CMS respaldado por Git, y entrega todo el conjunto como un sitio estático. Está pensado como base con todo incluido para sitios orientados a contenido —— documentación, blogs, páginas de marketing —— que aun así quieren componentes realmente interactivos donde importa.
| Pieza | Qué hace |
|---|---|
| HonoX | Meta-framework sobre Hono —— enrutamiento basado en archivos, islas servidor/cliente |
| PandaCSS | CSS-in-JS tipado y sin runtime, compilado por adelantado |
| Sveltia CMS | Edición de contenido respaldada por Git en /admin/ —— sin base de datos, sin servicio backend |
@hono/vite-ssg |
Pre-renderiza cada ruta a HTML estático en tiempo de build |
Por qué este stack
La mayoría de las bibliotecas de componentes de UI están construidas para un framework de JavaScript específico —— un lastre en el momento en que necesitas mezclar frameworks o cambiar más adelante. HonoX esquiva eso como un meta-framework: te permite traer tu propio framework (BYOF), así nuestros componentes permanecen agnósticos al framework, resueltos totalmente en tiempo de build en lugar de estar atados a una runtime del cliente. Combinado con @hono/vite-ssg, esto también nos da:
- Estático y sin framework por defecto. El resultado del build es HTML/CSS/JS plano —— no se requiere ningún proceso de servidor en tiempo de petición, así que se despliega en cualquier lugar donde se sirvan archivos estáticos (Cloudflare Pages y Vercel ya vienen configurados).
- Interactivo donde importa. No todos los componentes necesitan enviar JavaScript. Un modelo de hidratación de tres niveles permite que cada componente decida si se hidrata de forma inmediata, condicional, o nunca —— manteniendo el bundle del cliente pequeño sin renunciar a una UI rica.
Estos componentes de UI comenzaron como un port de Park UI (Ark UI) de React a Hono/jsx. Para cada uno, hemos construido bindings coincidentes para Sveltia CMS, un CMS respaldado por Git, de modo que el contenido sigue siendo fácilmente editable a través de una interfaz de administración web sin tener que tocar código. Esto también hace que el código de UI sea más limpio y orientado a datos. El CMS es local-first, se ejecuta completamente en el cliente y hace commit directamente en los archivos bajo content/, de modo que los editores pueden escribir entradas de blog, documentación, e incluso componer páginas enteras visualmente mediante el Constructor de Páginas, mientras que los desarrolladores mantienen todo bajo control de versiones.
PandaCSS se usa para generar todo el CSS por adelantado a partir de llamadas de estilo analizables estáticamente —— sin motor de estilos en runtime, sin colisiones de nombres de clase, y con seguridad de tipos completa en los design tokens.
Qué incluye
- Cerca de 60 componentes de UI bajo
app/components/ui/, cubriendo layout, formularios, overlays y presentación de datos, cada uno con su contraparte interactiva enapp/islands/cuando es necesario. - Un blog (
content/posts/) con etiquetas, páginas de autor y una API JSON de solo lectura. - Un constructor de páginas visual (
content/pages/) para componer páginas a partir de componentes anidados enteramente desde el CMS. - Documentación (esta sección), escrita en Markdown plano o MDX, este último para páginas que necesitan un ejemplo renderizado en vivo incrustado en el texto.
- i18n en seis idiomas (
en,zh,es,pt,fr,de) para la documentación, los componentes y la interfaz del sitio.
Por dónde seguir
- Primeros Pasos —— instala las dependencias y ejecuta el proyecto en local.
- Arquitectura —— una mirada más profunda al build, el enrutamiento, la estructura de componentes y los pipelines de contenido.
- Hidratación —— cómo los componentes optan por la interactividad del lado del cliente.
- Constructor de Páginas CMS —— composición visual de páginas a través de Sveltia CMS.