Hay algo que cualquiera que lleve tiempo en el mundo del desarrollo ha escuchado más de una vez: críticas bastante duras hacia WordPress. Comentarios sobre código desordenado, malas prácticas, rendimiento, seguridad… y en muchos casos, un rechazo casi automático a usarlo en proyectos “serios”.
Y lo curioso es que, en parte, lo entiendo.
Porque cuando alguien ha tenido una mala experiencia con WordPress, normalmente no ha sido con un WordPress bien planteado. Ha sido con instalaciones llenas de plugins sin control, con temas sobrecargados, con código tocado directamente en producción y sin ningún tipo de estructura. Y claro, cuando trabajas en ese contexto, es fácil sacar conclusiones.
El problema es que esa experiencia se generaliza.
Se asume que WordPress es eso. Que siempre es así. Y que, por tanto, no es una herramienta válida para proyectos complejos. Pero en realidad, lo que se está evaluando no es la tecnología en sí, sino una forma concreta —y bastante común— de utilizarla.
También hay un componente cultural importante. Muchos desarrolladores vienen de trabajar con frameworks donde todo parte de una arquitectura definida desde el inicio. Hay convenciones claras, estructuras pensadas, separación de responsabilidades… y eso da una sensación de orden y control desde el primer momento.
WordPress, en cambio, no te obliga a trabajar así.
Te permite hacerlo bien, pero también te permite hacerlo mal. Y esa flexibilidad, que es una de sus mayores virtudes, también es una de las razones por las que genera rechazo en ciertos perfiles más técnicos.
Porque no hay barreras.
Y donde no hay barreras, es fácil encontrarse con proyectos caóticos.
Otro punto que influye es la percepción. WordPress está muy asociado a proyectos rápidos, económicos y, muchas veces, poco cuidados a nivel técnico. Eso hace que se relacione más con ejecución que con arquitectura, más con implementación que con diseño de sistemas.
Y eso, para muchos desarrolladores, resta atractivo.
Pero hay otra cara que no siempre se ve.
Cuando WordPress se trabaja con criterio, cuando se define una arquitectura, se controlan dependencias, se establecen entornos y se aplican buenas prácticas, el resultado no tiene nada que ver con esa imagen inicial. Se convierte en una herramienta muy capaz, flexible y, sobre todo, eficiente para resolver muchos tipos de proyectos.
No es perfecta. Tiene limitaciones, decisiones históricas discutibles y partes mejorables, como cualquier tecnología que lleva tantos años evolucionando. Pero reducirlo a “no sirve” es simplificar demasiado.
Al final, el rechazo a WordPress muchas veces no viene de lo que es, sino de lo que se ha visto.
Y eso es importante tenerlo en cuenta.
Porque si solo conoces la peor versión de una herramienta, es normal que no quieras volver a usarla.
La pregunta interesante no es por qué algunos desarrolladores odian WordPress.
Es qué versión de WordPress han conocido.
Y ahí es donde empieza realmente la conversación.