Qué es un framework: el ahorro de hoy y la atadura de mañana
Todo el software se construye sobre algo que ya existe. Esa decisión te ahorra meses al principio y condiciona lo que podrás hacer durante años.
Cuando una empresa necesita un local nuevo tiene dos caminos que no se parecen en nada, aunque los dos terminen en un negocio abierto al público. Puede comprar un solar vacío y levantar la estructura entera: cimientos, paredes, instalación eléctrica, fontanería, salida de emergencia, todo decidido pieza por pieza desde cero. O puede alquilar una nave que ya tiene todo eso resuelto —la luz ya está instalada, los baños ya están donde tienen que estar, la salida de emergencia ya cumple la normativa— y dedicar el tiempo y el dinero que se ahorra a lo que de verdad distingue ese negocio: el escaparate, la distribución del espacio, la experiencia de quien entra.
En software pasa lo mismo, y la nave que ya viene con la instalación resuelta tiene nombre: framework.
#Lo que un framework resuelve por ti
Todo programa necesita cosas que no tienen nada que ver con lo que ese programa hace de especial. Necesita un sistema para que un usuario inicie sesión sin que su contraseña quede expuesta. Necesita guardar y recuperar información de una base de datos sin que dos personas escribiendo a la vez se pisen los datos. Necesita decidir qué pantalla mostrar según la dirección que el usuario ha escrito en el navegador. Necesita protegerse de los intentos más comunes de ataque, que son los mismos en casi cualquier sistema del mundo.
Nada de esto es lo que hace especial a tu negocio. Es la instalación eléctrica y los baños: imprescindible, invisible cuando funciona, y exactamente igual de necesaria para una sala de conciertos que vende entradas que para una tienda que gestiona un catálogo de productos. Un framework es un conjunto de piezas ya construidas, probadas por miles de proyectos antes que el tuyo, que resuelven todo eso para que el equipo que te desarrolla el sistema dedique su tiempo a lo que sí es tuyo: cómo se reparten los asientos por zonas, cómo se calcula el descuento de una compra grande, cómo se avisa a tu equipo cuando entra un pedido.
Por eso un proyecto sobre un framework conocido suele salir más rápido y más barato que uno levantado desde cero: hay menos por construir, y lo que hay que construir ya lo ha construido y depurado antes mucha otra gente.
Esto explica también por qué casi ningún proyecto de software se construye hoy completamente desde cero. No es pereza ni falta de ambición técnica: es la misma lógica que lleva a cualquier negocio a comprar la maquinaria de cocina en lugar de fabricarla, o a contratar la gestoría en lugar de llevar la contabilidad inventando un sistema propio de cero. Reconstruir lo que ya existe, resuelto y probado por otros miles de veces antes, no demuestra más capacidad: demuestra menos criterio sobre en qué merece la pena gastar el tiempo del equipo.
#El precio que se paga después
La nave alquilada tiene una condición que el solar vacío no tiene: no puedes tirar las paredes que no son tuyas. Puedes decorar, dividir el espacio, adaptar la distribución, pero dentro de lo que la estructura permite. Si tu negocio necesita algo que esa nave no está pensada para dar —un techo el doble de alto, una carga eléctrica que su instalación no soporta— cambiarlo cuesta más que si hubieras construido desde el principio pensando en eso.
Con un framework ocurre lo mismo. Mientras lo que necesitas se parece a lo que miles de proyectos anteriores ya necesitaron, vas más rápido que nadie. El problema aparece cuando tu caso es distinto de lo previsto: entonces el equipo técnico no está construyendo tu función, está discutiendo con una herramienta que insiste en hacer las cosas a su manera. Ese forcejeo tiene un nombre entre quien desarrolla —«pelearse con el framework»— y un efecto muy concreto en tu presupuesto: lo que en un sistema construido a medida sería una tarde de trabajo, sobre un framework que no contempla ese caso puede convertirse en una semana de rodeos para conseguir lo mismo sin romper el resto.
Esto no convierte al framework en mala idea. Convierte en mala idea elegirlo sin preguntar antes si tu negocio tiene ese tipo de necesidad especial que se sale de lo previsto. La mayoría de negocios no la tiene. Algunos sí, y para esos, el ahorro de hoy puede acabar costando más que el que se hubiera gastado construyendo desde cero.
#Lo que pasa cuando el framework cambia
Un framework se mueve bajo tus pies. Lo mantiene un equipo o una comunidad que lo sigue actualizando, y de vez en cuando saca una versión que no solo añade cosas: cambia cómo funcionan piezas que tu sistema ya estaba usando de una manera concreta. Cuando eso pasa, tu sistema puede dejar de funcionar sobre la versión nueva hasta que alguien revise y ajuste las partes afectadas. A eso se le llama, en la jerga, un «cambio incompatible», y es exactamente lo que suena: lo que antes funcionaba, tal cual estaba escrito, deja de hacerlo.
Y existe un escenario peor todavía: que el equipo que mantiene el framework decida dejar de hacerlo. Pasa con más frecuencia de la que parece, sobre todo con herramientas pequeñas creadas por una sola persona o un grupo reducido. Si eso ocurre, tu sistema sigue funcionando el día después —nada se rompe de golpe— pero deja de recibir parches de seguridad, y cada mes que pasa sin ellos es un mes más de exposición a fallos ya conocidos y sin corregir. Es la misma situación que un local alquilado en un edificio cuyo propietario ha dejado de hacer mantenimiento: hoy sigue en pie, pero nadie va a arreglar la próxima gotera.
Cuando un framework saca una versión que rompe compatibilidad, actualizar no es pulsar un botón: es revisar, una por una, las partes del sistema que dependían del comportamiento anterior. En proyectos grandes esto puede suponer semanas de trabajo que no añaden ni una función nueva, solo mantienen lo que ya había. Conviene saberlo antes de decidir framework, no cuando llega la factura de esa migración.
#Quién mantiene la nave que te van a alquilar
Nadie te va a pedir opinión sobre qué framework usar, y no hace falta que la tengas: esa es una decisión técnica que corresponde a quien te desarrolla el sistema. Lo que sí puedes —y conviene— hacer es preguntar sobre el framework elegido antes de dar el visto bueno al presupuesto, con tres preguntas que no requieren saber programar para entender la respuesta:
- ¿Cuánta gente lo usa hoy? Un framework con una comunidad grande tiene más gente resolviendo los mismos problemas que tú vas a tener, más documentación escrita, y más facilidad para encontrar, dentro de tres años, a alguien que sepa mantenerlo si tu proveedor actual desaparece.
- ¿Quién lo mantiene? No es lo mismo un framework respaldado por una empresa grande o por una fundación con financiación estable que uno mantenido, en su tiempo libre, por una persona sin más compromiso que las ganas que tenga ese año.
- ¿Qué pasó la última vez que sacaron una versión mayor? Si la respuesta es «fue una migración tranquila de un par de días» es una señal buena. Si la respuesta es «obligó a reescribir media aplicación» o nadie en el equipo se acuerda de que haya pasado nunca, conviene indagar más antes de construir sobre esa base los próximos años de tu negocio.
Si las tres respuestas llegan sin titubeos, lo que te están alquilando es una nave con la instalación en regla y el propietario localizable. Si llegan a medias, sigue siendo una nave alquilada, solo que nadie sabe decirte quién responde de la próxima gotera.