PHP 8.2 strict en 2026: por qué sigue siendo nuestro piso para PYMEs

Cada vez que alguien revisa Suite HUB por dentro, la primera reacción es la misma: “¿PHP? ¿En 2026?”. Es comprensible — los discursos en X y Hacker News no le hacen muchos favores. Pero la decisión no fue por inercia ni nostalgia. Fue una elección calculada con base en quién es nuestro cliente, dónde corre el sistema y qué dura más que la moda técnica del año.

El contexto: hostings de $5/mes y cPanel#

Nuestro cliente típico es una PYME panameña que paga Hostinger compartido o un VPS modesto. Nada de Kubernetes, nada de Vercel, nada de Lambda edges. cPanel sigue siendo la realidad operativa de la mayoría de hospedajes accesibles en Latinoamérica.

PHP corre out-of-the-box en cualquier de esos entornos sin tocar nada. Node necesita PM2, systemd, pasarela, monitoring. Go o Rust necesitan compilación cruzada y deploy de binarios. Para un cliente que no tiene equipo de DevOps, eso es fricción que mata el proyecto antes de empezar.

PHP 8.2 strict no es el PHP del 2010#

La gente que ve “PHP” mentalmente carga la versión 5.x con mysql_query() y archivos sueltos. Pero PHP 8.2 con declare(strict_types=1) te da:

<?php declare(strict_types=1);

namespace HubCore\Modules\Pos;

final readonly class CartItem
{
    public function __construct(
        public string $sku,
        public int $quantity,
        public Money $unitPrice,
    ) {}

    public function subtotal(): Money
    {
        return $this->unitPrice->multiply($this->quantity);
    }
}

final readonly class, tipos de retorno estrictos, named args, enums, match expressions, first-class callable syntax, never return type, intersection types. La ergonomía está al nivel de C# o Kotlin modernos.

Composer es real, PHPUnit es real#

Hub Core gen 2 tiene 37 tests PHPUnit verificando 32 reglas DGI específicas. El adapter de PAC se rompe en CI antes de que llegue a producción. Composer maneja el árbol de dependencias con composer.lock igual de robusto que package-lock.json o Cargo.lock.

La narrativa de “PHP no tiene tooling” no aplica desde hace una década.

El frontend no es donde duelen las decisiones#

Para UI usamos Tailwind 3 + Flowbite + Alpine.js. Alpine es la “navaja suiza” del frontend declarativo cuando no necesitas React. En HUB Pro sumamos HTMX 2 para interacciones server-driven más ricas. Esto cubre el 95% de los casos sin la complejidad de un SPA.

¿Te suena minimalista? Es la decisión correcta cuando tu app vive embebida en un navegador de tablet ARM barato con conexión 4G inestable. Cada KB cuenta.

El día que sí pivotamos#

Hay casos donde PHP no es la herramienta correcta:

• Cómputo intensivo en tiempo real: ahí preferimos Go o Rust como sidecar.
• WebSockets persistentes a escala: Soketi en Node corre paralelo.
• Servicios de IA/embeddings: Python con FastAPI vive en su propio contenedor.

PHP es el corazón transaccional. Los workers especializados son satélites llamados por HTTP. Esa arquitectura distribuye complejidad sin obligarnos a un monolito Node que luego nadie sabe operar.

La verdadera ventaja: encontrar talento#

En Panamá hay una base enorme de desarrolladores PHP con experiencia real, muchos con background en WordPress / Laravel. Reclutar para extender Suite HUB es trivial. Reclutar para extender un stack Rust + GraphQL + microservicios es prácticamente imposible localmente.

Esa disponibilidad de talento es lo que hace al stack económicamente sostenible para nuestra escala.

Conclusión#

PHP 8.2 strict no es la opción aspiracional ni la que da clout en redes. Es la opción correcta para nuestro contexto: PYMEs panameñas, hosting accesible, equipos pequeños y disciplinados, mantenibilidad a 10 años. La modernidad técnica importa, pero importa más resolver el problema del cliente con la herramienta que sobreviva al hype.

Y honestamente: ver un sistema PHP bien escrito sirviendo 2,300+ facturas electrónicas reales al mes desde un VPS de $40/mes, sin caer una vez, es un argumento que rara nostalgia puede igualar.