Un stack, no un amontonamiento
Un stack no es una lista de herramientas de moda pegadas entre sí. Es un conjunto de decisiones que deben sostenerse juntas — compartir una filosofía, complementarse sin pisarse.
Hemos hablado de las piezas una a una en este diario: HTMX, CodeIgniter 4, el rendimiento, el builder. Aquí está la visión de conjunto — cómo encaja todo y por qué este ensamblaje forma un todo coherente.
El hilo conductor cabe en una frase: el servidor sigue al mando, el cliente sigue ligero.
El principio: el servidor sigue siendo la fuente de la verdad
En el centro, una convicción arquitectónica: el servidor es la fuente de la verdad. Devuelve HTML — no JSON que un front tendría que volver a convertir en interfaz. El navegador muestra, dispara peticiones y recibe a cambio fragmentos de HTML ya listos.
<input type="search" name="q"
hx-get="/recherche"
hx-trigger="input changed delay:300ms"
hx-target="#resultats">
<div id="resultats"></div>public function results()
{
$q = $this->request->getGet('q');
$posts = $this->postModel->search($q);
// Devolvemos un FRAGMENTO Blade, no una página entera
return view('partials/results', ['posts' => $posts]);
}Este bucle — un atributo HTMX dispara una petición, el controlador devuelve un fragmento Blade, HTMX lo inserta — es el corazón que late en todo el stack. Sin lógica duplicada entre back y front, sin estado de cliente que sincronizar.
Todo lo demás se deriva de este principio: cada herramienta se elige porque sirve a ese bucle, con ligereza.
La base: CodeIgniter 4 + MariaDB
La base es CodeIgniter 4 sobre PHP 8.2+: ligero, explícito, dominado de principio a fin (le dedicamos un artículo entero). Gestiona el routing, los modelos, las migraciones y la autenticación vía Shield.
En el lado de los datos, MariaDB — un SGBD relacional probado y fiable, perfectamente cómodo en un hosting OVH/Plesk clásico. Nada exótico: sólido.
Esta base no busca impresionar. Busca durar.
El renderizado: BladeOne
El renderizado HTML pasa por BladeOne, una implementación autónoma del motor Blade. Escribimos plantillas legibles, troceadas en partials — y esos partials son exactamente los fragmentos que HTMX viene a buscar.
Es un detalle que cuenta: el mismo partial sirve tanto para el render inicial de la página como para las actualizaciones parciales. Una sola fuente para una misma pieza de interfaz.
El builder, por su parte, genera archivos Blade en disco (otro tema que exploramos). Todo converge hacia Blade.
La interactividad: HTMX v2
Para la interactividad, HTMX v2: ~10 KB, cero dependencias, que convierte cualquier elemento en disparador de peticiones y solo reemplaza un fragmento. Es lo que da la sensación de «aplicación» sin el peso ni la complejidad de una SPA.
Búsqueda en vivo, paginación, edición inline, dashboards refrescados, modales: lo esencial de la interactividad de un sitio de contenido o un back-office cabe ahí.
Y como es HTML declarativo, se lee en el propio markup y se depura a simple vista.
Lo microinteractivo: Alpine.js
No todo necesita un ida y vuelta al servidor. Un dropdown que se abre, una pestaña que cambia, un toggle: es puramente local. Para eso, Alpine.js — un toque de reactividad directamente en el HTML.
<div x-data="{ open: false }">
<button @click="open = !open">Menu</button>
<ul x-show="open" @click.outside="open = false">
<li>…</li>
</ul>
</div>HTMX y Alpine se reparten el trabajo limpiamente: HTMX para todo lo que toca al servidor (los datos), Alpine para lo que se queda en el navegador (el estado de visualización). Ninguno de los dos invade el terreno del otro.
Dos pequeñas bibliotecas declarativas en vez de un gran framework imperativo: la misma lógica de sobriedad, aplicada al front.
El estilo: Tailwind CSS
El estilo es Tailwind CSS: utility-first, compones la apariencia directamente en el markup, sin idas y vueltas a archivos CSS dispersos. El purge solo conserva las clases realmente usadas — la hoja final es minúscula.
También es el soporte de nuestra dirección artística: bordes marcados (border-2), sombras duras (.hard), aplanados — el brutalismo que elogiamos en otro sitio. Tokens coherentes, reutilizados por todas partes.
Dos configuraciones separadas (front y admin), dos universos visuales, una sola herramienta.
El build: Vite
Para las herramientas del front, Vite: arranque instantáneo, HMR (recarga en caliente), build optimizado. En desarrollo, corremos dos servidores Vite (front y admin) detrás de un proxy.
La ventaja concreta: programas, ves el resultado de inmediato, sin esperar a un bundler pesado. En producción, servimos assets comprimidos y versionados.
Vite incluso lee nuestras variables de entorno (el tema activo, por ejemplo) para adaptar el build — la configuración sigue al contenido.
El rendimiento: un reflejo, no un añadido
El rendimiento no es una opción que se añade al final. Redis cachea lo que es costoso pero estable (configuraciones, menús, agregados), sirve las sesiones y las colas de trabajos. AVIF reduce el peso de las imágenes, el lazy-load solo carga lo visible.
Detallamos estas recetas en un artículo dedicado. La idea: pagar el coste una vez (en la subida, en el build, al guardar) y servir rápido después.
En un hosting modesto, esta disciplina marca la diferencia entre una página ágil y una que se arrastra.
Por qué este ensamblaje se sostiene
Lo que hace coherente este stack no es la lista de herramientas — es su filosofía común. Todas son ligeras, explícitas, orientadas al servidor. Ninguna impone una catedral de abstracciones. Puedes leer toda la cadena, desde un atributo HTMX hasta una consulta SQL.
| Capa | Tecnología | Rol |
|---|---|---|
| Lenguaje | PHP 8.2+ | el cimiento de ejecución |
| Framework | CodeIgniter 4 | routing, modelos, seguridad (Shield) |
| Base de datos | MariaDB | persistencia relacional |
| Caché / colas | Redis | caché, sesiones, cola |
| Plantillas | BladeOne | render HTML servidor + fragmentos |
| Hypermedia | HTMX v2 | fragmentos interactivos, sin SPA |
| Microinteractivo | Alpine.js | estado local ligero |
| Estilo | Tailwind CSS | utility-first + dirección artística |
| Build | Vite | bundling, HMR, assets versionados |
| Medios | ImageProcessor (WebP/AVIF) | optimización de imágenes |
| Alojamiento | OVH / Plesk | producción |
Compara con un stack SPA clásico (front en framework JS + API + gestión de estado + build complejo): dos aplicaciones que mantener, el doble de lógica de negocio, un estado que sincronizar entre ambas. Aquí, una sola aplicación, una sola fuente de la verdad. Menos piezas móviles, menos averías.
No es la opción correcta para todo — una app muy stateful del lado cliente todavía justifica un framework JS. Pero para la inmensa mayoría de los sitios y back-offices que construimos, es el equilibrio ideal.
Entender toda la cadena
Un stack coherente es uno que entiendes por completo, mantienes sin crisis y haces evolucionar pieza a pieza. Es menos espectacular que una demo SPA llamativa — pero dura años, y es exactamente lo que vendemos a nuestros clientes: durabilidad.
El mejor stack no es el más impresionante: es el que entiendes de principio a fin.