Los tipos de frameworks

docs.scrimba.com

¿Qué es un framework? cubrió la idea: estructura más plomería resuelta, siendo el framework quien llama tu código. Este capítulo es el mapa de lo que realmente existe: un recorrido con una tranquilidad integrada, porque nadie conoce todos estos. Los desarrolladores que trabajan conocen una o dos familias bien y reconocen el resto, y ese es el objetivo aquí también. Las familias importan más que los nombres: aprende bien un miembro y sus hermanos vienen rápidamente.

La web: front-end y back-end

Los frameworks web se dividen siguiendo la línea donde se divide la web misma. Los frameworks front-end se ejecutan en el navegador y manejan lo que el usuario ve; los frameworks back-end se ejecutan en un servidor y manejan datos, cuentas y todo lo que hay detrás. Si te diriges al desarrollo web, probablemente uno de cada lado se convertirá en una herramienta diaria, y cuál es generalmente decidido por el equipo o proyecto al que te unas en lugar de por ti.

Los nombres front-end que encontrarás:

• React: el más usado por un amplio margen, con el ecosistema más grande y mercado laboral. Técnicamente una librería de UI más que un framework completo, una distinción con un núcleo útil cubierto abajo.
• Vue: conocido por una curva de aprendizaje suave y documentación que la gente realmente disfruta; un camino intermedio completo y bien organizado.
• Angular: el framework de Google todo incluido, con opiniones sobre todo; más cómodo en grandes organizaciones que quieren una forma sancionada para hacer cada cosa.
• Svelte: hace su trabajo en tiempo de compilación y envía menos código al navegador; comunidad más pequeña, frecuentemente admirada por la gente en ella.

Y los nombres back-end, donde el framework generalmente está vinculado a un lenguaje:

• Django (Python): todo incluido, desde la base de datos hasta la interfaz de administración; un compañero frecuente del Python que ya podrías conocer.
• Rails (Ruby): el framework que popularizó la convención sobre configuración; sus ideas se repiten en la mayoría de los frameworks web modernos, Laravel incluido.
• Laravel (PHP): el estándar moderno del mundo PHP, que sigue ejecutando una parte muy grande de la web.
• Express (JavaScript): deliberadamente minimalista, más cerca de un kit de herramientas que un framework completo; ensamblas el resto tú mismo.
• Spring (Java): el caballo de batalla empresarial; extenso, profundamente establecido, y presente en grandes empresas.

Una vez que puedes ver más allá de los logos, las mismas ideas se repiten en cada uno de estos. Los frameworks front-end todos convergieron en componentes: pequeños fragmentos reutilizables de interfaz que son dueños de su apariencia y comportamiento. Los frameworks back-end todos ofrecen enrutamiento (qué URL ejecuta qué código), alguna forma de hablar con una base de datos (a menudo un ORM, que te permite trabajar con filas de bases de datos como objetos ordinarios), y un espacio para tu lógica comercial. Aprende para qué sirven estas ideas en un framework y ya has aprendido la mayoría del siguiente framework; cambiar entre ellos principalmente significa nueva sintaxis y nuevos nombres de carpetas sobre los mismos conceptos.

El front-end actual tiene una capa más. React, Vue y Svelte manejan la interfaz pero dejan el enrutamiento, la carga de datos y la renderización del servidor para ti, así que cada uno creció un meta-framework: un framework construido sobre la librería que suministra esas piezas faltantes. Next.js juega ese papel para React, Nuxt para Vue, y SvelteKit para Svelte, y en la práctica la mayoría de las nuevas aplicaciones de producción llegan al meta-framework en lugar de la librería simple. Esto también resuelve el viejo argumento "¿es React un framework o una librería?" de una manera útil: React en sí mismo solo renderiza UI e invierte el control sobre nada excepto tus componentes, lo que lo hace una librería según la definición del último capítulo; envuélvelo en Next.js y el par se comporta exactamente como un framework. La etiqueta importa menos que saber qué capa posee qué decisión, porque ese es el lugar donde buscas cuando algo se comporta mal.

JunoFrameworks web Los frameworks front-end como React y Vue se ejecutan en el navegador y manejan lo que la gente ve; los frameworks back-end como Django y Rails se ejecutan en servidores y manejan datos y cuentas. No necesitas elegir el perfecto hoy, y definitivamente no los necesitas todos. ¡La mayoría de las personas aprenden el que usa su primer equipo, y eso funciona bien!

JunoFrameworks web Los nombres web difieren, las ideas se repiten: componentes en el front-end; enrutamiento, un ORM y espacios de lógica comercial en el back-end. Aprende las ideas a través de un framework y el siguiente es principalmente nueva sintaxis sobre formas familiares. Esa transferencia es por qué elegir "el incorrecto" primero cuesta menos de lo que la gente teme.

JunoFrameworks web El trabajo front-end moderno generalmente significa un meta-framework: Next.js sobre React, Nuxt sobre Vue, SvelteKit sobre Svelte, suministrando el enrutamiento y la renderización del servidor que la librería base deja fuera. Mantén claro qué capa posee qué decisión, ya que ese es donde comienza la depuración. Y React realmente es una librería según nuestra definición; Next.js es lo que hace del par un framework.

Aplicaciones y juegos

El desarrollo móvil tiene su propia historia de frameworks, y se centra en una pregunta: ¿construir por separado para iPhone y Android, o una sola vez para ambos? Dos frameworks dominan la respuesta de construir una sola vez. Flutter (de Google, utilizando el lenguaje Dart) dibuja su propia interfaz píxel por píxel, así que las aplicaciones se ven idénticas en todas partes. React Native trae el modelo de componentes de React a móvil e impulsa las piezas de interfaz nativa de cada plataforma, que es una continuación natural si ya conoces React.

Los motores de juegos son frameworks en su forma más total: poseen el bucle que se ejecuta sesenta veces por segundo, y tu código completa lo que hace cada objeto dentro de él. Unity (C#) es el predeterminado para juegos indie y de tamaño medio y muchos juegos móviles. Unreal (C++) lidera donde la fidelidad visual es el punto, desde juegos de gran presupuesto hasta producción de películas. Godot es el motor libre y de código abierto cuya comunidad ha crecido rápidamente, y un lugar amigable para comenzar.

El comercio multiplataforma merece que se lea en voz alta su precio. Un código único significa la mitad del trabajo y un equipo, que es por qué a los negocios les encanta. El costo es una capa entre tú y la plataforma: cuando se lanza una característica completamente nueva de iPhone, el framework necesita soportarla antes de que puedas usarla cómodamente, y exprimir una sensación completamente nativa requiere cuidado extra. Los equipos que necesitan cada detalle nativo aún construyen por separado con el kit propio de cada plataforma; los equipos que necesitan lanzar en ambos con un equipo pequeño eligen Flutter o React Native y rara vez se arrepienten.

Los motores de juegos llevan la inversión de control tan lejos como va, lo que los hace un caso extremo aclarador. El motor posee el tiempo mismo: llama tus scripts cada fotograma, ejecuta física entre tus callbacks, y decide cuándo tu objeto incluso existe. Tampoco escribes principalmente código "en" un motor; trabajas dentro de su editor, y los scripts son un activo entre escenas, materiales y prefabs. Esa propiedad total es exactamente por qué existen los motores: renderizado, física y canalizaciones de activos son años de trabajo especializado que ningún equipo de juegos quiere reconstruir. La misma lógica se escala hacia abajo: siempre que la plomería supera el producto, un framework deja de ser una conveniencia y se convierte en el único camino sensato.

JunoAplicaciones y juegos Flutter y React Native permiten que un código único se convierta en una aplicación de iPhone y Android, que es por qué tantos equipos los usan. Los juegos tienen motores como Unity, Unreal y Godot, que manejan gráficos y física mientras tu código dice qué hace cada objeto. La misma idea de framework que la web, usando diferentes ropas.

JunoAplicaciones y juegos Las aplicaciones móviles multiplataforma comercian un poco de pulido nativo por la mitad del trabajo, un trato que la mayoría de los equipos aceptan felizmente, mientras que los kits completamente nativos siguen siendo la respuesta cuando la sensación de plataforma es todo. Los motores de juegos son la idea de framework en su plena fuerza: funcionan el show sesenta veces por segundo y tus scripts completan el comportamiento.

JunoAplicaciones y juegos Los motores son el extremo que explica la regla: cuando la plomería (renderizado, física, canalizaciones de activos) es años de trabajo y supera tu juego real, ceder el control es el único comercio sensato. Mantén esa relación en tu cabeza, plomería versus producto, y la mayoría de las decisiones de framework en cualquier campo se vuelven más fáciles.

Los callados: testing y datos

No todos los frameworks hablan de construir un producto; algunos organizan el trabajo alrededor de él. Los frameworks de testing son el caso más claro, y el ejemplo más puro de la definición del último capítulo: pytest (Python), Jest (JavaScript), y JUnit (Java) cada uno encuentra tus funciones de test, las ejecuta, e informa, sin que nunca escribas un programa que llame a tus propios tests. Encontrarás uno de estos en casi todas las bases de código profesionales, generalmente el que coincide con el lenguaje del proyecto.

Los datos y el machine learning también tienen frameworks. PyTorch domina la investigación e incrementalmente la producción; TensorFlow es el ecosistema de Google con herramientas de producción profundas. Ambos manejan la maquinaria matemática del entrenamiento de modelos para que tu código describa el modelo en lugar de el cálculo. Si la pista Cómo funcionan los IA te interesó, estas son las herramientas con las que ese mundo se construye.

Los ejecutores de pruebas son la inversión de control en miniatura, y vale la pena un minuto de apreciación por esa razón. Escribes funciones nombradas test_something, y el framework las descubre por nombre, ejecuta cada una en un entorno nuevo, atrapa fallas sin detener el resto, e imprime el resumen. Nadie escribe esa orquestación por proyecto, que es la propuesta de valor del framework en su más pequeña y menos controvertida: incluso los desarrolladores que evitan los frameworks de productos por principio usan felizmente un framework de testing.

El par de ML es donde la línea librería-versus-framework se vuelve útilmente borrosa. Escribir un bucle de entrenamiento personalizado en PyTorch se siente como usar una librería: tu código dirige, y suministra matemática rápida. Usar capas de nivel superior, entrenadores y callbacks lo invierte de nuevo a la forma de framework, con tu código encajando en un bucle que la herramienta posee. El límite depende de qué capa de la herramienta conduces. Ese marco viaja bien más allá de ML: muchas herramientas grandes son librerías en una altitud y frameworks en otra, y saber a qué altitud estás volando te dice quién posee el flujo de control hoy.

JunoFrameworks de testing y datos Los frameworks de testing como pytest y Jest encuentran tus funciones de test y las ejecutan por ti, un pequeño ejemplo cotidiano de un framework llamando tu código. En machine learning, PyTorch y TensorFlow manejan la matemática pesada del entrenamiento de modelos. Los frameworks organizan todo tipo de trabajo de programación, mucho más allá de construir aplicaciones.

JunoFrameworks de testing y datos Un ejecutor de pruebas es la idea de framework en su menos controvertida: descubrimiento, aislamiento e informe que nadie debería reconstruir por proyecto. Observa que incluso los desarrolladores escépticos de frameworks usan uno sin queja; el comercio es diminuto y el resultado es constante. Esa asimetría es una buena lente para juzgar cualquier framework.

JunoFrameworks de testing y datos PyTorch es una librería cuando escribes el bucle de entrenamiento y un framework cuando su entrenador te ejecuta, y esa es la lección general: las herramientas grandes cambian de categoría dependiendo de qué capa conduces. Pregúntate quién posee el flujo de control a la altitud en la que estás trabajando, y la pregunta librería-o-framework se responde por sí sola.

A dónde va esto a continuación

Ese es el mapa: web en ambos lados del cable, móvil, juegos, testing y datos, toda la misma idea usando diferentes uniformes. La pregunta restante es la práctica, y tiene dos mitades: cuál, y si uno en absoluto. Elegir y aprender un framework afronta ambos, y si las definiciones aquí se sintieron inestables, ¿Qué es un framework? es una lectura breve de vuelta.