PHP puro, sin Laravel: por qué este sitio no lleva framework

Cuando alguien mira este sitio por dentro, la pregunta llega sola: y Laravel, dónde está. No está. Tampoco Symfony ni CodeIgniter, ni un solo paquete de terceros. La web son 18 ficheros de PHP y 3.263 líneas, y lo único que necesita instalado es el propio PHP con el conector de SQLite y la extensión de curl, que vienen en el paquete. No hay carpeta de dependencias que descargar ni fichero de dependencias que actualizar cada pocas semanas.

Escribo esto porque la decisión se lee a menudo como una rareza o como una pose. No es ninguna de las dos cosas: es una cuestión de tamaño.

Los números, primero

Los datos son la única defensa que vale en una decisión así, y están medidos en el móvil que sirve esta página:

• Código de la web: 18 ficheros y 3.263 líneas. Con las dos herramientas de consola, la del blog y la del registro de cambios, se va a 3.816 líneas.
• Lo que ocupa: 198 kilobytes. Todo el sitio en disco, contando el historial de git, son 1,3 megabytes.
• Dependencias de terceros: ninguna. Ni carpeta de dependencias, ni Composer instalado, que es el gestor con el que PHP reparte sus librerías.
• Aparte del núcleo del lenguaje, hace falta el conector de SQLite (libro de visitas, blog y registro de cambios) y curl (leer el título y la imagen de un enlace cuando se guarda un marcador).
• Una visita a la portada tarda entre 11 y 22 milisegundos, medidos en local contra el servidor de este móvil. Cada proceso que atiende peticiones ocupa unos 6 megabytes.

Qué hace un framework, y qué cuesta

Un framework es una caja de herramientas ya montada. Te da las direcciones de las páginas, la forma de hablar con la base de datos, las plantillas de las vistas, el sistema de usuarios y contraseñas, los cambios de la base de datos ordenados y numerados, y un ecosistema de piezas hechas para encajar entre ellas. Laravel, el más usado en PHP, hace todo eso bien. No es una crítica: es una descripción.

El precio está en las tripas, y son dos facturas. Una se paga al instalar: Laravel pide, según su propia documentación, PHP 8.2 o superior y trece extensiones del lenguaje, más Composer para traer las piezas. La otra se paga en cada visita. Un framework arranca su maquinaria entera antes de ejecutar una sola línea tuya: registra sus proveedores de servicios, monta el contenedor de dependencias, prepara el paso por las capas intermedias y resuelve la ruta. Hay mediciones de terceros que ponen buena parte del tiempo de una petición justo ahí, en ese arranque, y no en el código de la aplicación. Tanto es así que Laravel tiene una pieza, Octane, cuya misión es precisamente no repetir ese arranque en cada visita.

En un servidor grande, esa factura es calderilla. En un móvil que además sirve otras dos webs, un juego y un bingo, no lo es.

Por qué aquí no

Aquí no hay nada de lo que la caja resuelve. El sitio tiene catorce direcciones, tres bases de datos de SQLite con una tabla cada una y un puñado de consultas cortas. No hay cuentas de usuario con contraseñas —en el tres en raya y en el bingo cada jugador lleva una ficha suelta que se guarda en su navegador, no un usuario con clave—, no se suben ficheros, no hay pagos, no hay trabajos en segundo plano y no hay formularios largos que validar. El HTML se escribe directamente; no hay capa de plantillas.

Con ese tamaño, el enrutador es un switch de 178 líneas y la capa de base de datos son 92. Un framework ahí no ordena nada: añade piezas que no voy a abrir.

Lo que me ahorro

• Publicar un cambio es traer los cambios con git y ya está. No hay que descargar dependencias en el servidor ni pelearse con un fichero de dependencias que no cuadra.
• Menos cosas que actualizar. Cuando salta un aviso de seguridad, aquí solo puede venir del propio PHP. En un proyecto con framework, el aviso puede venir de cualquiera de las decenas de piezas que arrastra, y son más ficheros que revisar. Ya escribí en su día sobre los dos agujeros graves de PHP de octubre de 2026 y sobre cómo se comprueba aquí la versión que atiende de verdad.
• Nada cambia por debajo sin que lo haya escrito yo. Un salto de versión menor de un framework mueve decenas de piezas a la vez y alguna cambia de comportamiento; aquí, lo que hay es lo que leo.
• El sitio se lee entero. Alguien que abra la carpeta entiende de qué va en una tarde.

Lo que me cuesta

• El enrutador, las consultas y el escapado del texto los escribo yo. Un framework da escapado por defecto y consultas preparadas sin pedirlo; sin él, hay que acordarse cada vez.
• La seguridad es mía y entera. Nadie revisa mi código. Aquí eso significa cosas concretas: consultas preparadas siempre, escapar el texto al pintarlo y una guarda en el lector de enlaces para que el túnel público no sirva para asomarse a la red de casa. Con framework, parte de esto vendría puesto.
• No hay panel de administración. Publicar un artículo es un comando de consola. Para mí está bien; para alguien que no use la terminal, sería un muro.
• No hay red de seguridad para terceros. En un sitio con más gente, el framework no es un lujo: es lo que evita que cada uno resuelva lo mismo a su manera.

Sin framework, pero no sin pruebas

La ausencia de framework no es ausencia de comprobaciones. Los tres sitios tienen sus pruebas escritas, que piden las páginas al servidor de verdad con la cabecera del dominio: 35 comprobaciones el tres en raya, 58 el bingo, 44 el posicionamiento y el marcado del sitio y 41 el registro de cambios. Más de doscientas en total, todas ejecutadas desde la consola. Eso sustituye en parte lo que da un framework: no la convención, sino la certeza de que algo sigue funcionando después de tocarlo.

Cuándo sí montaría un framework

• Si hubiera cuentas de usuario de verdad, con contraseñas, permisos y sesiones.
• Si entraran pagos o datos personales, con sus formularios, sus validaciones y su rastro de auditoría.
• Si el proyecto lo tuviera que mantener otra persona, o si yo no fuera a escribir cada línea.
• Si fueran muchas pantallas iguales: listar, crear, editar y borrar lo mismo veinte veces. Ahí el ahorro de un framework es enorme.

La parte incómoda

Que no se lea esto como que los frameworks son malos. No lo son: son una buena compra. Pagas memoria y dependencias y recibes convenciones, un camino ya trillado y respuestas para problemas que todavía no has tenido. Lo que ocurre es que aquí no hay ningún problema de esos.

Y hay una trampa en el argumento de la eficiencia. El visitante de esta página no nota esos quince milisegundos: por el túnel y la red que hay en medio, la misma página tarda entre 260 y 320 milisegundos en llegar desde fuera. Si el motivo fuera la velocidad para quien lee, PHP a secas no lo arregla. El motivo real es otro: menos piezas, menos ficheros, menos cosas que se rompen solas y menos sitio donde equivocarse.

PHP a secas tampoco es más seguro por ser a secas. Casi ningún agujero de una web PHP sale del lenguaje; salen de la web: de una consulta montada con trozos de texto, de un dato que se pinta sin escapar, de un fichero que se sube sin mirar. Eso se hace igual de mal con framework y sin él. Lo que cambia es quién lleva la cuenta.

En resumen

La pregunta no es cuál es más moderno, sino cuánto hueso tiene el proyecto. Para tres webs pequeñas, un blog, un libro de visitas y un par de juegos, PHP a secas llega de sobra, y añadir una caja de herramientas que no voy a abrir sería pagar por peso. El día que este sitio sea otra cosa, lo contaré aquí, con sus números delante. Y lo más probable es que ese día escriba que monté un framework.

Fuentes

• Requisitos de Laravel: Deployment y Installation
• Octane, para no arrancar el framework en cada petición: Laravel Octane
• El arranque del framework y el consumo de CPU: Laravel High CPU Usage y Laravel Octane vs RoadRunner vs PHP-FPM
• Los dos fallos de PHP de octubre de 2026 y cómo se comprueba aquí: Dos agujeros críticos en PHP, y cómo está este sitio