¿Qué es un framework?

Imagina que estás construyendo una pequeña aplicación web: cuentas de usuario, un feed, una página de configuración. Antes de que aparezca en pantalla cualquier idea tuya, necesitas código que convierta URLs en páginas, código que se comunique con una base de datos, código que mantenga las contraseñas seguras y código que redibuje la pantalla cuando algo cambia. Nada de eso es idea de tu aplicación. Toda aplicación lo necesita, y la mayor parte es igual de un proyecto a otro.

Podrías escribir toda esa "plomería" tú mismo, y así se hizo durante años. Es lento, ahí es donde viven los errores sutiles, y cada equipo terminaba con una versión ligeramente distinta y ligeramente rota de la misma maquinaria. Un framework es la respuesta acumulada a ese problema: la plomería compartida, escrita una sola vez y puesta a prueba por miles de proyectos, empaquetada con una estructura que te indica dónde va tu propio código. Tú construyes las partes que hacen único a tu proyecto; el framework se encarga de las partes que todo proyecto repite.

Los frameworks no son solo cosa de la web. Existen en todos los ámbitos donde se construyen programas, y este capítulo trata sobre la idea en sí misma, en cualquier lenguaje y cualquier campo.

Qué es un framework (y qué es una librería)

La palabra se usa de forma imprecisa, así que veamos la distinción que realmente importa, en código:

// Una librería: tu código está a cargo y llama a la librería cuando le conviene.
const label = dateLibrary.format(order.createdAt, "MMM D");

// Un framework: el framework está a cargo y llama al código que tú conectas.
export default function OrdersPage() {
  return listOfOrders();
}

La primera línea eres tú al mando: tu programa se ejecuta y toma prestada una herramienta para una tarea puntual. La segunda es diferente por naturaleza. Tú nunca llamas a OrdersPage directamente. Lo escribes, lo colocas donde el framework lo espera, y el framework lo llama en el momento correcto, aquí, cuando un visitante abre la página de órdenes.

Ese cambio de mando tiene nombre: inversión de control. Con una librería, tu código controla el flujo del programa y toma prestados ayudantes. Con un framework, el framework controla el flujo, y tu código completa los espacios que él te deja. Una forma útil de recordarlo: tú llamas a una librería; un framework te llama a ti.

Esta misma forma aparece en todos los rincones de la programación. Django recibe la petición web y llama a tu función de vista. Flutter ejecuta la aplicación y les pregunta a tus widgets qué dibujar. Unity ejecuta el bucle del juego y llama a tus scripts en cada cuadro. pytest encuentra tus funciones de prueba y las ejecuta por ti. Son campos distintos, pero una sola idea: el framework es dueño del motor, y tú aportas las piezas para las que fue diseñado.

Si te ayuda una imagen: una librería es una caja de herramientas que está a tu lado mientras construyes, y tomas una herramienta cada vez que te resulta útil. Un framework se parece más a la estructura de un edificio, que ya está en pie cuando llegas. Las paredes, el cableado y las tuberías ya tienen su lugar, y tu trabajo va en las habitaciones que hacen que ese edificio sea tuyo. Ambos te ahorran esfuerzo; la diferencia está en quién decide la forma de la construcción.

La estructura viene con expectativas, y eso es justamente una ventaja. La mayoría de los frameworks siguen el principio de convención sobre configuración: pon los archivos donde el framework los espera, nombra las cosas como él espera que las nombres, y todo se conecta solo, sin código de configuración. Rails hizo famosa esta frase, y la mayoría de los frameworks modernos siguen alguna versión de ella. La ventaja es que cualquier desarrollador que conozca el framework puede abrir cualquier proyecto construido con él y saber dónde buscar. El costo es que las convenciones son algo más que aprender antes de que nada funcione, y luchar contra ellas casi siempre resulta más doloroso que seguirlas.

La inversión de control cambia la forma en que lees y depuras un programa. En un script simple, la pila de llamadas empieza en tu código y todo lo que hay en ella es tuyo. Dentro de un framework, la pila empieza en las profundidades internas del framework, y tus funciones aparecen como entradas que el framework decidió llamar: hooks, manejadores, métodos de ciclo de vida. El viejo chiste lo describe con precisión: "no nos llames, nosotros te llamaremos". En la práctica, esto significa que aprender un framework tiene menos que ver con su superficie de API y más con su temporización: cuáles de tus funciones llama, cuándo, y qué espera que le devuelvas. Cuando el comportamiento te sorprende, la respuesta suele estar en esa temporización, y la documentación del ciclo de vida del framework es el mapa que conviene tener siempre a la mano.

JunoFrameworks y librerías Una librería es una caja de herramientas: tu programa lleva las riendas y toma una herramienta cuando la necesita. Un framework se parece más a la estructura de un edificio: la estructura ya está construida, y tú armas tus habitaciones dentro de ella. La frase que me hizo entenderlo fue esta: tú llamas a una librería, pero un framework te llama a ti.

JunoFrameworks y librerías Tú llamas a una librería; un framework te llama a ti, y ese cambio se llama inversión de control. Los frameworks lo combinan con convenciones: pones el código donde el framework lo espera y todo se conecta solo. Seguir las convenciones en lugar de luchar contra ellas es la mayor parte de la habilidad para usar bien un framework.

JunoFrameworks y librerías La inversión de control significa que la pila de llamadas empieza en el framework y tu código aparece como los hooks que él invoca. Así que lo que realmente hay que aprender es la temporización: cuáles de tus funciones se llaman, cuándo, y qué espera el framework que le devuelvas. Depurar una aplicación basada en un framework es leer su ciclo de vida, y cuanto antes deje de sentirse como magia, mejor.

Qué te da un framework, y qué te cuesta

El argumento a favor de un framework es concreto. Problemas que te tomarían semanas llegan ya resueltos, y resueltos por personas que se topraron primero con los casos límite más difíciles: manejo de contraseñas, validación de formularios, ruteo, renderizado. Tu proyecto obtiene una estructura que un nuevo compañero de equipo puede reconocer en minutos, porque es la misma estructura que la de cualquier otro proyecto hecho con ese framework. Y heredas un ecosistema: plugins, tutoriales, preguntas ya respondidas, y una reserva de personas para contratar que ya conocen cómo moverse en él.

Los costos son igual de concretos, y merecen la misma mirada honesta. Un framework es una dependencia grande que no controlas, con sus propios errores, su propio ritmo y sus propias opiniones. Hay una curva de aprendizaje antes de que se renderice tu primera página, y parte de lo que aprendes es conocimiento sobre el framework, no sobre programación en general. Tu código se adapta a sus formas, lo que hace que dejarlo sea más difícil cuanto más tiempo lo uses. Y los frameworks cambian con el tiempo: llegan versiones mayores, se repiensan patrones, y mantenerse al día es un trabajo continuo que no tenías con código plano.

Ninguna de las dos listas gana por sí sola. El equilibrio depende por completo del proyecto, así que la pregunta que hay que hacerse frente a cualquier framework es "¿este framework hace más simple este proyecto en particular?". Un framework se gana su lugar cuando hace más simple tu proyecto. Cuando lo logra, úsalo con gusto. Cuando no, los próximos dos capítulos tratan sobre cómo reconocer eso a tiempo.

El efecto del ecosistema es el punto a favor que menos se valora. En un framework maduro, las probabilidades de que tu problema sea nuevo son casi nulas: autenticación, subida de archivos, envío de correos, despliegue; alguien ya empaquetó o documentó cada uno de esos casos. Eso convierte muchos días de construcción en horas de ensamblaje. El punto equivalente en la columna de los costos es que esa fluidez está denominada en los términos del framework: parte de lo que sabes es "cómo lo hace Django" en lugar de "cómo funcionan los servidores web". Presta atención a la idea general que hay debajo de cada comodidad, que es justamente para lo que sirve esta documentación.

Hay dos costos que solo se hacen visibles en producción. Primero, las abstracciones tienen fugas: la superficie conveniente del framework oculta la maquinaria real, y el día en que la magia falla, terminas depurando esa maquinaria de todos modos, ahora a través de una capa extra que no escribiste tú. Reserva tiempo para entender qué hace tu framework por debajo, porque eventualmente lo vas a necesitar. Segundo, la rutina de actualizaciones es un costo real: las migraciones de versión mayor en una base de código grande pueden absorber semanas, y postergarlas silenciosamente se convierte en problemas de seguridad sin parchear. Sopesa ambos costos frente a la alternativa de código plano, que tiene menos piezas en movimiento y nada que migrar, pero te obliga a resolver de nuevo, bajo tu propio riesgo, cada problema que ya estaba resuelto. Ese intercambio es el tema de Elegir y aprender un framework.

JunoQué te da un framework y qué te cuesta Un framework te entrega problemas ya resueltos, una estructura reconocible y todo un ecosistema de ayuda. A cambio, asumes una dependencia grande, una curva de aprendizaje y su manera particular de hacer las cosas. Ambos lados son reales, así que la pregunta que hay que llevarse es si hace más simple tu proyecto en particular. A veces la respuesta es un sí con gusto, ¡y a veces el código plano es el camino más tranquilo!

JunoQué te da un framework y qué te cuesta El ecosistema es la mitad menos valorada del trato: en un framework maduro casi ningún problema con el que te topas es realmente nuevo. Aun así, sigue prestando atención a la idea general detrás de cada comodidad, o tu conocimiento se vuelve "cómo lo hace este framework" en lugar de cómo funciona realmente. El framework debería hacer más simple el proyecto; esa es toda la prueba que importa.

JunoQué te da un framework y qué te cuesta Hay dos costos que se cobran después: las abstracciones tienen fugas, así que un día terminas depurando la maquinaria del framework a través de una capa que no escribiste tú, y las migraciones de versión mayor son trabajo real que no se puede postergar para siempre. Cálculalos desde el principio, junto al costo propio del código plano, que es tener que resolver de nuevo problemas que el framework ya había terminado de resolver. Yo he pagado ambas facturas; ninguna es divertida, y ninguna es motivo para el dogmatismo.

Hacia dónde va esto ahora

Con esta idea ya clara, la pregunta natural que sigue es qué hay realmente disponible: Los tipos de frameworks recorre las grandes familias, desde la web hasta los videojuegos y las pruebas, con las opciones más populares de cada una. Después, Elegir y aprender un framework se pone práctico sobre cómo elegir uno, aprenderlo, y saber cuándo no necesitas ninguno. Y si los ejemplos de JavaScript de arriba te resultaron poco familiares, el curso de JavaScript cubre el lenguaje en sí, que es el primer paso correcto antes de cualquier framework construido sobre él.