Definición
Un framework es una estructura que te da resuelto el esqueleto de una aplicación y te deja rellenar los huecos. Trae decisiones tomadas: cómo se organizan los ficheros, cómo se gestionan las rutas, cómo se conecta con la base de datos.
La diferencia con una librería no está en el tamaño, está en quién llama a quién:
- Con una librería, tú mandas. La llamas cuando la necesitas y sigues con lo tuyo.
- Con un framework, manda él. Tú escribes funciones y componentes, y el framework los llama cuando corresponde.
Eso se llama inversión de control, y es la frase que resume la relación: "no nos llames, ya te llamaremos".
Qué ganas y qué pierdes
Ganas velocidad de arranque —no empiezas de cero cada vez—, decisiones ya tomadas por gente que se dedicó a pensarlas, seguridad razonable por defecto y una comunidad que ya se encontró tus problemas antes.
Pierdes libertad y ligereza. Si tu problema no encaja con lo que el framework espera, pelearás contra él. Y añades una dependencia grande de la que dependerá tu proyecto durante años: cuando saquen una versión nueva con cambios de ruptura, la migración es tuya.
La pregunta útil al elegir no es "¿cuál es mejor?", sino "¿mi problema se parece a aquel para el que se diseñó esto?".
Ejemplo práctico
En mis proyectos conviven dos decisiones opuestas, y las dos son correctas.
Esta web usa Next.js, un framework completo. Tiene 101 páginas de diccionario que se generan solas a partir de ficheros Markdown, rutas dinámicas, generación de imágenes para redes sociales, sitemap automático y exportación a HTML estático. Todo eso viene resuelto. Escribirlo a mano serían semanas y quedaría peor.
El CRM de IMDICA no usa framework. Es PHP directo, con sus propias funciones y su estructura. Son 73 secciones creciendo desde hace años, y el motivo de no meter un framework fue práctico: se despliega en un hosting compartido con Plesk, y la sencillez de "sube los ficheros y funciona" vale más ahí que la elegancia. Sin composer install, sin proceso de compilación, sin sorpresas al actualizar.
La conclusión que saco de tener los dos delante: el framework es una herramienta, no una señal de calidad. Hay proyectos serios sin framework y proyectos horrendos con el más moderno del momento.
Cómo elegir uno
- ¿Sigue vivo? Mira la fecha del último lanzamiento y cuánta gente responde en su repositorio. Un framework abandonado es deuda garantizada.
- ¿Cuánto duran sus versiones? Un proyecto que rompe la compatibilidad cada año te obliga a migrar cada año.
- ¿Hay gente que lo sepa? Si mañana no estás tú, ¿alguien puede coger el proyecto?
- ¿Encaja con dónde se va a desplegar? Un framework que necesita Node corriendo no vale para un hosting compartido de 3 € al mes.
- ¿Cuánto tienes que aprender antes de producir algo? Si son dos semanas para una web de cinco páginas, no compensa.
Errores comunes
- Elegir por moda. El framework del que todo el mundo habla este año puede estar en la mitad de descargas dentro de tres.
- Meter un framework pesado para algo pequeño. Una landing de una página no necesita una aplicación con enrutador y estado global.
- Pelearse contra sus convenciones. Si te ves escribiendo trucos para saltarte cómo el framework quiere hacer las cosas, o el framework está mal elegido o tú estás mal planteando el problema.
- No leer cómo se actualiza. Antes de adoptarlo, mira su historial de cambios de ruptura. Ahí está el coste real a tres años.
- Confundir framework con arquitectura. Un framework organiza carpetas; no decide si tu lógica de negocio está bien pensada.
Cuándo usarlo
Sí cuando el proyecto es mediano o grande, cuando lo va a mantener más de una persona, cuando necesitas cosas que el framework ya resuelve (rutas, sesiones, seguridad, base de datos) o cuando la velocidad de entrega importa.
No cuando el proyecto es minúsculo, cuando tienes limitaciones fuertes de entorno, o cuando lo que ganas en comodidad lo pierdes en control sobre algo que en tu caso es crítico.
