¿Cuándo conviene utilizar un framework, un CMS o código propio?
Un sitio web puede construirse de distintas maneras. Un sistema de gestión de contenidos puede ofrecer un área administrativa y una estructura establecida para publicar información. Un framework puede aportar convenciones y herramientas reutilizables para construir aplicaciones con mayor interacción o complejidad. El código propio permite mantener la solución más cerca de los requerimientos específicos del proyecto.
Ninguna de estas alternativas es automáticamente mejor. La pregunta útil es cuál resuelve el problema real con un nivel adecuado de complejidad.
Primero hay que entender qué necesita hacer el proyecto
La tecnología resulta más fácil de evaluar después de comprender las funciones del proyecto. Un sitio principalmente informativo, una publicación que cambia con frecuencia, un sistema operativo interno y una interfaz con muchas interacciones simultáneas no tienen las mismas necesidades.
Si el proyecto necesita principalmente publicar páginas, recibir formularios y presentar información estable, agregar un framework amplio de aplicación puede no ofrecer un beneficio proporcional. Si varias personas necesitan publicar y editar contenido sin trabajar con archivos fuente, un CMS puede ser más adecuado. Si la interfaz contiene muchos estados relacionados, componentes reutilizables e interacciones que cambian continuamente, un framework de frontend puede reducir parte de esa complejidad.
¿Qué problema resuelve un CMS?
Un CMS resuelve principalmente la administración de contenido. Separa la información que se publica de las páginas públicas donde aparece y puede ofrecer usuarios, borradores, estados de publicación, administración de medios y registros estructurados.
Su valor aumenta cuando el contenido cambia con frecuencia o varias personas necesitan mantenerlo. Un sitio con poca información estable puede no necesitar esa capa administrativa.
¿Qué problema resuelve un framework?
Un framework proporciona convenciones para organizar software y normalmente ofrece formas establecidas de dividir una interfaz en componentes, administrar cambios de la interfaz, organizar vistas, reutilizar lógica y coordinar el desarrollo dentro de una base de código mayor.
Esto puede ser valioso en aplicaciones con una interacción considerable. Sin embargo, el framework también pasa a formar parte del proyecto: introduce su propia estructura, dependencias, actualizaciones y necesidades de mantenimiento.
Por esa razón, utilizar un framework solamente porque es común en el mercado no demuestra por sí mismo que el proyecto lo necesite.
¿Qué ofrece el código propio?
El código propio permite construir únicamente las funciones que requiere el proyecto y mantener la implementación cerca de las tecnologías que el navegador y el servidor comprenden directamente.
Esto no significa colocar todas las responsabilidades en un solo archivo ni evitar una arquitectura. Un desarrollo propio también puede separar presentación, acceso a datos, reglas de negocio, servicios y módulos reutilizables sin adoptar un framework completo de aplicación.
La principal ventaja es el control. La principal responsabilidad es que el equipo de desarrollo debe definir y mantener sus propias convenciones en lugar de recibirlas de una plataforma o framework.
Más tecnología no siempre significa mayor capacidad
Las capas adicionales son útiles cuando reducen un problema mayor. Si un framework evita lógica duplicada en la interfaz, mejora la consistencia entre muchos módulos o facilita el mantenimiento de una aplicación grande, su costo puede estar justificado.
Si el proyecto tiene poca interacción y el mismo resultado puede obtenerse claramente con tecnologías estándar de la web, esas capas adicionales pueden aumentar instalación, dependencias, procesos de compilación y mantenimiento futuro sin cambiar lo que el usuario realmente puede hacer.
¿Cómo tomar la decisión?
La decisión puede basarse en el tipo de información, frecuencia de cambio, cantidad de interacción, número de usuarios que administrarán el sistema, crecimiento esperado, integraciones, tamaño del equipo y mantenimiento a largo plazo.
Un CMS, un framework y el código propio no son respuestas que compitan para todos los proyectos web. Son herramientas distintas para responsabilidades distintas.
La tecnología adecuada es la que resuelve los requerimientos reales sin introducir más complejidad de la que el proyecto puede justificar.
Definir primero el problema permite elegir la arquitectura más pequeña que pueda resolverlo correctamente hoy y continuar evolucionando cuando los requerimientos realmente cambien.