En Solucionex llevamos años trabajando con PHP en proyectos de muy distinto calado, y hace unos días leímos un artículo de Brent Roose en stitcher.io que pone el dedo en una llaga que muchos profesionales del sector compartimos pero pocos se atreven a verbalizar: el mayor obstáculo al que se enfrenta PHP hoy no está en el código, sino fuera de él.
Estamos de acuerdo. Y queremos contarte por qué.
Un lenguaje moderno con fama de antiguo
Si alguien que abandonó PHP allá por la versión 5.3 volviera hoy a echarle un vistazo, probablemente no reconocería el lenguaje. Tipado estricto, enums, propiedades readonly, fibers, attributes, un sistema de tipos cada vez más expresivo, JIT... La distancia entre el PHP de hace una década y el actual es enorme.
Y sin embargo, en muchas conversaciones técnicas —sobre todo fuera del ecosistema PHP— sigue arrastrando una reputación que ya no le corresponde. La narrativa popular se quedó congelada en una versión del lenguaje que prácticamente nadie usa hoy en producción seria.
Brent lo plantea con claridad: el lenguaje es sólido, el ecosistema es rico, las herramientas han madurado, la Foundation aporta estabilidad y el desarrollo no se detiene. El problema no es ninguna de esas cosas. El problema es cómo se cuenta todo eso al mundo. O, más bien, lo poco que se cuenta.
La lección que nos deja Laravel
El artículo señala un caso evidente: Laravel. Más allá de si te gusta su filosofía o si prefieres otros enfoques, es innegable que es probablemente el proyecto PHP más exitoso de la última década (con permiso de WordPress).
¿Y qué ha hecho Laravel especialmente bien? Marketing. Comunicación. Cuidar la marca. Producir contenido constantemente. Hacer que su web parezca actual cada vez que la visitas. Construir comunidad alrededor de eventos, cursos, podcasts y productos satélite. Esa atención al "envoltorio" no es accesoria: forma parte del producto.
El contraste con la imagen oficial del propio lenguaje es revelador. Y conviene preguntarse por qué.
La percepción es un activo técnico (aunque no lo parezca)
En Solucionex defendemos una idea que conecta directamente con la tesis del artículo: la percepción de una tecnología afecta al negocio que se construye sobre ella. Y de forma muy concreta.
Cuando un cliente decide la stack de su próximo proyecto, rara vez lo hace solo con argumentos técnicos. Pesan también la facilidad para encontrar talento, la confianza del equipo directivo en la elección, lo que dicen los foros de inversores, lo que se cuenta en LinkedIn o lo que aparece en los rankings de tendencias. Todo eso es marketing, aunque a los ingenieros nos cueste reconocerlo.
Por tanto, cuando un lenguaje arrastra una imagen desactualizada, no solo se resiente el ego de quien lo programa: se resienten las decisiones de contratación, los presupuestos y los proyectos que llegan o dejan de llegar. Es un problema económico real, no estético.
Las propuestas tienen sentido
Las recomendaciones que propone el artículo son razonables y, en nuestra opinión, urgentes. Una web oficial que comunique el estado actual del lenguaje. Documentación cuidada por profesionales dedicados a tiempo completo. Presencia activa en las redes sociales donde está la audiencia, y no solo donde la comunidad se siente cómoda. Apertura del proceso interno de desarrollo para que cualquiera pueda seguir lo que está pasando sin tener que bucear en una mailing list. Y, por supuesto, comunicar bien las novedades cuando llegan, en lugar de dejarlas languidecer en un changelog.
Nada de esto es trivial. Como apunta el propio Brent, hablamos de tres o cuatro puestos a tiempo completo. Es una inversión seria. Pero es la inversión que hoy le falta a PHP.
Nuestra postura
En Solucionex seguimos apostando por PHP en muchos de los proyectos que desarrollamos, precisamente porque conocemos su estado real, no el imaginario. Vemos cómo evoluciona, cómo mejora con cada versión y cómo el ecosistema sigue ofreciendo soluciones competitivas para construir aplicaciones modernas, mantenibles y rentables.
Pero también compartimos la inquietud de fondo: si la comunidad y la Foundation no asumen que el marketing es parte del trabajo, el lenguaje seguirá siendo subestimado en demasiadas mesas donde se decide qué se construye y con qué.
Te recomendamos leer el artículo original de Brent en stitcher.io. Es breve, directo y, sobre todo, oportuno. A veces el problema más grande de una tecnología no se resuelve escribiendo más código, sino contando mejor el código que ya existe.