¿Qué es un framework?

docs.scrimba.com

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 cualquiera de tus propias ideas aparezca en pantalla, necesitas código que convierta URLs en páginas, código que hable 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ía es igual de proyecto en proyecto.

Podrías escribir toda esa tubería tú mismo, y la gente lo hizo, durante años. Es lento, es donde viven los bugs sutiles, y cada equipo terminaba con una versión ligeramente diferente y ligeramente rota de la misma maquinaria. Un framework es la respuesta acumulada: la tubería compartida, escrita una sola vez y endurecida por miles de proyectos, empaquetada con una estructura que te dice dónde va tu propio código. Construyes las partes que hacen tu proyecto único; el framework maneja las partes que todo proyecto repite.

Los frameworks no son algo de la web. Existen en todas partes donde se construyen programas, y este capítulo trata sobre la idea en sí, en cualquier lenguaje y en cualquier campo.

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

La palabra se usa de manera imprecisa, así que aquí está la distinción que realmente importa, en código:

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

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

La primera línea eres tú dirigiendo: tu programa se ejecuta y toma prestada una herramienta para un trabajo. La segunda es diferente en esencia. Nunca llamas a OrdersPage tú mismo. La escribes, la pones donde el framework la espera, y el framework la llama en el momento correcto, aquí, cuando un visitante abre la página de pedidos.

Ese cambio tiene un nombre: inversión de control. Con una librería, tu código controla el flujo del programa y toma prestadas herramientas. Con un framework, el framework controla el flujo, y tu código rellena los espacios en blanco que deja para ti. Un atajo útil: llamas una librería; un framework te llama a ti.

La misma forma aparece en cada rincón de la programación. Django recibe la solicitud web y llama tu función de vista. Flutter ejecuta la aplicación y pregunta a tus widgets qué dibujar. Unity ejecuta el bucle de juego y llama tus scripts cada fotograma. pytest encuentra tus funciones de prueba y las ejecuta por ti. Diferentes campos, una idea: el framework posee el motor, y tú suministras las partes para las que fue construido.

Si una imagen ayuda: una librería es una caja de herramientas a tu lado mientras construyes, y alcanzas una herramienta cada vez que es útil. Un framework es más parecido al marco de un edificio, ya en pie cuando llegas. Las paredes, el cableado y la tubería tienen sus lugares, y tu trabajo va en los cuartos que hacen el edificio tuyo. Ambos te ahorran esfuerzo; la diferencia es quién decide la forma de la construcción.

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

La inversión de control cambia cómo lees y debugueas un programa. En un script simple, la pila de llamadas comienza en tu código y todo en ella es tuyo. Dentro de un framework, la pila comienza en lo profundo de las entrañas del framework, y tus funciones aparecen como entradas que el framework eligió llamar: hooks, handlers, métodos de ciclo de vida. El viejo chiste lo describe exactamente: "no nos llames, nosotros te llamaremos". En la práctica, eso significa que aprender un framework es menos sobre su superficie de API y más sobre su sincronización, cuál de tus funciones llama, cuándo, y qué espera a cambio. Cuando el comportamiento te sorprende, la respuesta usualmente vive en esa sincronización, y la documentación del ciclo de vida del framework es el mapa que vale la pena tener abierto.

JunoFrameworks y librerías Una librería es una caja de herramientas: tu programa dirige el espectáculo y agarra una herramienta cuando la necesita. Un framework es más como el marco de un edificio: la estructura ya está en pie, y construyes tus cuartos en él. El atajo que hizo clic para mí es que llamas una librería, pero un framework te llama a ti.

JunoFrameworks y librerías Llamas una librería; un framework te llama a ti, y ese cambio se llama inversión de control. Los frameworks lo emparejan con convenciones: pon código donde el framework lo espera y se conecta solo. Sigue las convenciones en lugar de luchar contra ellas, eso es la mayoría de la habilidad de usar uno bien.

JunoFrameworks y librerías La inversión de control significa que la pila de llamadas comienza en el framework y tu código aparece como hooks que invoca. Entonces la cosa real para aprender es sincronización: cuál de tus funciones se llama, cuándo, y qué espera el framework a cambio. Debuguear una aplicación con framework es leer su ciclo de vida, y cuanto antes deje de parecer magia, mejor.

Qué gana un framework y qué cuesta

El caso para un framework es concreto. Problemas que te tomaría semanas resuelven ya, y resueltos por gente que golpeó los casos extremos difíciles primero: manejo de contraseñas, validación de formularios, enrutamiento, renderizado. Tu proyecto obtiene una estructura que un compañero nuevo puede reconocer en minutos, porque es la misma estructura que todo otro proyecto en ese framework. E heredas un ecosistema: plugins, tutoriales, preguntas respondidas, y un fondo de contratación de gente que ya sabe cómo moverse.

Los costos son igualmente concretos, y merecen la misma mirada directa. Un framework es una dependencia grande que no controlas, con sus propios bugs, su propio ritmo y sus propias opiniones. Hay una curva de aprendizaje antes de que tu primera página se renderice, y algo de lo que aprendes es conocimiento sobre el framework en lugar de sobre programación. Tu código se dobla a sus formas, lo que hace más difícil irte cuanto más tiempo te quedes. Y los frameworks se mueven: llegan versiones mayores, los patrones se repiensan, y mantenerse al día es trabajo continuo que no tenías con código simple.

Ninguna lista gana por sí sola. El balance depende enteramente del proyecto, así que la pregunta a hacer de cualquier framework es "¿hace este uno este proyecto más simple". Un framework se gana su lugar haciendo tu proyecto más simple. Cuando lo hace, úsalo con gusto. Cuando no lo hace, los próximos dos capítulos tratan sobre reconocer eso temprano.

El efecto del ecosistema es la entrada subestimada en el lado positivo. En un framework maduro, las probabilidades de que tu problema sea nuevo están cerca de cero: autenticación, cargas de archivos, envío de correos, despliegue, alguien ha empaquetado o documentado cada uno. Eso convierte muchos días de construcción en horas de ensamblaje. La entrada espejada en el lado negativo es que esta soltura se denomina en el framework: algo de lo que sabes es "cómo lo hace Django" en lugar de "cómo funcionan los servidores web". Mantén un ojo en la idea general bajo cada conveniencia, que es lo que estos documentos son.

Dos costos solo aparecen en producción. Primero, las abstracciones tienen fugas: la superficie conveniente del framework esconde maquinaria real, y en el día que la magia se comporta mal, terminas debugueando la maquinaria de todas formas, ahora a través de una capa que no escribiste. Presupuesta para entender qué hace tu framework por debajo, porque eventualmente lo necesitarás. Segundo, la cinta rodante de actualización es un elemento de línea real: las migraciones de versión mayor de una base de código grande pueden absorber semanas, y saltárselas silenciosamente se convierte en problemas de seguridad sin parches. Pesa ambos contra la alternativa de código simple, que tiene menos piezas móviles y nada que migrar, pero reabre cada problema resuelto para que lo resuelvas nuevamente, a tu propio riesgo. Ese intercambio es el tema de Choosing and learning a framework.

JunoQué ganan y cuestan los frameworks Un framework te entrega problemas resueltos, una estructura reconocible y un ecosistema entero de ayuda. A cambio asumes una dependencia grande, una curva de aprendizaje y su manera de hacer las cosas. Ambos lados son reales, así que la pregunta a llevar es si hace tu proyecto particular más simple. A veces la respuesta es un sí feliz, ¡y a veces el código simple es el camino más tranquilo!

JunoQué ganan y cuestan los frameworks El ecosistema es la mitad subestimada del intercambio: en un framework maduro casi ningún problema que golpees es nuevo. Mantén notando la idea general bajo cada conveniencia aunque, o tu conocimiento se vuelve "cómo lo hace este framework" en lugar de cómo funciona la cosa. El framework debe hacer el proyecto más simple; ese es la prueba completa.

JunoQué ganan y cuestan los frameworks Dos costos te facturan después: las abstracciones tienen fugas, así que un día debugueas la maquinaria del framework a través de una capa que no escribiste, y las migraciones de versión mayor son trabajo real que no puede omitirse para siempre. Precía ambos de frente, junto al precio propio del código simple de re-resolver problemas que el framework había terminado. He pagado ambas facturas; ninguna es divertida, y ninguna es razón para dogma.

Hacia dónde va esto a continuación

Con la idea en su lugar, la siguiente pregunta natural es qué hay realmente afuera: The kinds of frameworks recorre las principales familias, desde web hasta juegos hasta testing, con las opciones más populares en cada una. Después de eso, Choosing and learning a framework se vuelve práctico sobre escoger uno, aprender uno, y saber cuándo no necesitas ninguno en absoluto. Y si los ejemplos de JavaScript de arriba te sintieron desconocidos, el track de JavaScript cubre el lenguaje en sí, que es el primer paso correcto antes de cualquier framework construido en él.