Cómo elegir y aprender un framework

docs.scrimba.com

Los dos capítulos anteriores cubrieron qué son los frameworks y qué opciones existen. Este capítulo es la parte práctica: si usar uno, cuál usar, y cómo aprenderlo. El orden importa, porque la primera pregunta es la que más se salta la gente.

¿Necesitas un framework?

Imagina dos proyectos. El primero es una app con cuentas de usuario, formularios y pantallas que reaccionan todas a datos compartidos. Construir eso a mano significa rearmar exactamente la plomería que un framework ya perfeccionó, y la versión sin framework termina siendo un framework casero, desordenado y a medio probar, que nadie quiere heredar. Elegir Django o React en ese caso significa quedarte con menos piezas que mantener, no con más.

El segundo caso es una landing page, un sitio de contenido, un script pequeño, un formulario que envía datos a algún lado. HTML plano, CSS y un poco de JavaScript cubren esto sin necesidad de proceso de build, sin actualizaciones de dependencias y sin nada que migrar el año que viene. Envolver una página así en un framework completo agrega maquinaria de la que solo se beneficia el tooling. Muchos desarrolladores con experiencia eligen a propósito no usar framework, y esa es una decisión profesional, nunca una concesión de principiante.

La ingeniería tiene una regla vieja y directa que cubre ambos casos: KISS, "keep it simple, stupid" ("mantenlo simple, tonto"). El insulto apunta al diseño y no a quien diseña, y la idea es que la mejor solución es la que resuelve el problema con la menor cantidad de maquinaria posible. Ambos proyectos de arriba obedecen esta regla, y llegan a respuestas opuestas.

Eso convierte todo en una sola pregunta, que hay que hacerse de nuevo en cada proyecto: elige la opción que te deje menos maquinaria para mantener. Cuando la plomería es mucho más grande que el producto, la respuesta es el framework. Cuando el producto es casi todo lo que hay, la respuesta es código plano.

Algunas señales hacen la decisión más concreta. Se inclina hacia el framework: muchas pantallas que comparten datos en vivo, cuentas de usuario y permisos, formularios que validan y guardan información, varias personas trabajando en el mismo código durante años. Se inclina hacia código plano: sobre todo contenido, poca interactividad, una vida útil medida en meses, uno o dos mantenedores, o una página donde la velocidad de carga es prácticamente toda la funcionalidad. Y el tamaño del proyecto puede cambiar la respuesta con el tiempo en cualquiera de los dos sentidos, así que el hábito útil es volver a hacerte la pregunta cada vez que el proyecto cambia de forma.

Esta decisión falla de dos maneras reconocibles, y ambas vienen de saltarse la pregunta. El primer fallo es la landing page con forma de framework: un pipeline de build, un árbol de dependencias y eventuales migraciones, todo eso pegado a cuatro pantallas de contenido, donde cada hora dedicada al tooling es una hora que el producto no necesitaba. El segundo es el framework accidental: un código base sin framework que termina desarrollando su propio router, su propio almacén de estado y su propio sistema de componentes, cada uno escrito una vez, probado nunca, y entendido por una sola persona. Ese segundo proyecto paga los costos de un framework sin recibir sus beneficios. Ambos fallos, vistos desde dentro, parecen convicción; y en ambos casos la solución es el mismo gesto poco glamoroso de volver a decidir según lo que el proyecto se ha convertido.

Juno¿Necesitas un framework? Hazte una sola pregunta por proyecto: ¿qué opción me deja menos por construir y mantener? Para una app interactiva con cuentas de usuario y datos compartidos, un framework suele ganar. Para una página de contenido o un script pequeño, el código plano suele ganar. Ambas respuestas son respetables, y elegir código plano nunca es un retroceso.

Juno¿Necesitas un framework? Estado en vivo compartido, cuentas de usuario, formularios y una vida larga con muchas personas involucradas apuntan hacia un framework; páginas centradas en contenido, de vida corta, o donde la velocidad es crítica apuntan hacia código plano. Vuelve a hacerte la pregunta cuando el proyecto cambie de forma, en lugar de defender la decisión original, y decide caso por caso siempre.

Juno¿Necesitas un framework? Cuidado con los dos fallos clásicos: la landing page con forma de framework que paga costos de tooling sin necesidad, y la app sin framework que en silencio terminó desarrollando su propio framework sin mantenimiento. Ambos vienen de tratar la decisión como algo ya resuelto para siempre. Yo vuelvo a decidir en cada punto de inflexión del proyecto, y eso me ha salvado de las dos trampas más de una vez.

Cómo elegir un framework

Cuando la respuesta es sí, elige con criterios poco glamorosos. Los benchmarks y las comparaciones de features son los datos menos útiles, porque dentro de una misma familia, las opciones populares son todas suficientemente rápidas y suficientemente capaces. Lo que realmente determina tu día a día es:

El ecosistema y la comunidad: documentación madura, preguntas ya respondidas, y paquetes para los problemas que vas a enfrentar. El equipo y el código base al que te vas a unir: el mejor framework suele ser el que tu proyecto ya usa, y la consistencia le gana a la novedad dentro de un equipo. El mercado laboral, si estás aprendiendo para trabajar: los números de uso importan mucho, y eso explica en buena parte por qué React es la elección racional de tanta gente. Y el lenguaje que ya conoces: un desarrollador de Python llega a Django más rápido que a Rails, por razones que no tienen nada que ver con la calidad de uno u otro.

Deja la opción de código plano en la lista hasta el final. Si la tabla de comparación se llena y ninguno de los candidatos le gana a "ninguno de los anteriores" en la prueba de simplicidad, eso ya te está diciendo algo.

Para evaluar un candidato de cerca, una hora de evaluación directa vale más que una semana leyendo opiniones: revisa el tutorial oficial y juzga si la documentación explica de verdad o solo sugiere; revisa el historial de versiones buscando un ritmo estable y sin apuros; busca "cómo migrar de la versión X a la Y" y fíjate si esas guías se leen como algo de una tarde o de toda una temporada; y observa si las preguntas que tú harías ya tienen buenas respuestas. Un framework es una relación larga, y estas son las pruebas de compatibilidad.

Dos hábitos de gente con experiencia completan esto. Primero, apuesta por lo bien establecido: una tecnología que se ha usado ampliamente durante años tiene modos de falla conocidos, gente disponible para contratar, y respuestas ya escritas, y "probado y un poco pasado de moda" sobrevive a "nuevo y emocionante" mucho más seguido de lo que uno esperaría. La rotación de tecnología es un costo que se acumula, y los frameworks que sobrevivieron una década ya pagaron ese costo. Segundo, mantén la opción de construir versus adoptar como algo real a nivel de componente: a veces la cantidad correcta de framework es una librería de routing y nada más, adoptada para resolver el único problema difícil mientras el resto se queda en código plano. Adoptar un framework no es todo o nada, y la dependencia más pequeña que resuelve la parte realmente difícil es una arquitectura perfectamente respetable.

JunoCómo elegir uno Elige con criterios prácticos: qué usa ya tu equipo, qué tan buena es la documentación y la comunidad, qué pide el mercado laboral, y qué lenguaje ya conoces. Dentro de una misma familia, todas las opciones populares son buenas, así que hay menos en juego de lo que parece. Tus habilidades se van a transferir sea cual sea el camino que elijas.

JunoCómo elegir uno Dedícale a un candidato una hora enfocada: lee su tutorial, revisa su ritmo de versiones, y lee una guía de migración entre versiones, porque ese es el futuro al que te estás comprometiendo. La comunidad, el ajuste con el equipo y las oportunidades de trabajo le ganan a los benchmarks siempre. Y deja "sin framework" en la lista corta hasta el final, a propósito.

JunoCómo elegir uno Apuesta por lo bien establecido: sobrevivir una década es el benchmark más informativo que puede presentar un framework. Y recuerda que adoptar no es binario; a veces una sola librería pequeña para el único problema difícil es la cantidad correcta de framework. El objetivo es un producto que se lanza y se mantiene lanzable.

Cómo aprender cualquier framework

Aprende el lenguaje primero. Un framework asume su lenguaje en todas partes: el código de React es JavaScript de principio a fin, y debajo de cada línea confusa de una app en Django hay Python. Quienes se saltan directo al framework terminan depurando dos misterios a la vez, el comportamiento del framework y la sintaxis del lenguaje, sin ninguna forma de distinguir cuál es cuál. Si React es tu meta, la ruta de JavaScript es el verdadero primer paso; para Django o pytest, la ruta de Python cumple el mismo papel. Aprender el lenguaje primero es el atajo más grande que existe, porque es la parte que se transfiere a todas partes.

Después, construye algo pequeño y real. Un proyectito que en verdad quieras hacer, construido apoyándote en el tutorial oficial, te enseña más que cualquier cantidad de ver videos y leer documentación, porque la forma del framework solo tiene sentido cuando lo tocas con tus propias manos. Mantén el primer proyecto modesto a propósito: su único trabajo es presentarte las ideas del framework, y la obra maestra puede esperar.

Y mientras avanzas, sigue preguntándote qué está haciendo el framework por ti. Cada feature conveniente reemplaza algo real: una ruta reemplaza el parseo de URLs, un componente reemplaza actualizaciones del DOM, un modelo reemplaza SQL. No necesitas dominar esas capas desde el principio, pero saber que existen, y a grandes rasgos qué hace el framework con ellas, es lo que distingue usar un framework de depender de él a ciegas.

La trampa común en esta etapa es el ciclo de tutoriales: terminar curso tras curso sin nunca empezar un proyecto propio sin guía, porque los tutoriales se sienten productivos y los archivos en blanco se sienten arriesgados. Rómpelo a propósito. Después de un tutorial oficial, empieza el proyecto pequeño y real y deja que sus problemas decidan qué buscas leer; la documentación leída con un problema real en la mano se queda grabada de una forma en que la documentación leída como tarea nunca lo hace. Quedarte trabado y salir de eso solo, en tu propio proyecto, es la habilidad que en realidad estás entrenando.

Dos hábitos hacen que el conocimiento de un framework dure. Aprende temprano las vías de escape: todo framework tiene formas autorizadas de bajar por debajo de sus abstracciones (SQL directo saltando el ORM, acceso directo al DOM saltando el renderizador), y saber dónde están te muestra los límites de la máquina aunque casi nunca las uses. E invierte, poco a poco pero de forma constante, en la plataforma que hay debajo del framework: HTTP, el DOM, SQL, el runtime del lenguaje. Los frameworks son la forma en que hoy se sostiene la plataforma; la plataforma es lo que permanece. Los desarrolladores que conocían la plataforma cruzaron intactos cada transición de framework de los últimos veinte años, y ese es un historial que vale la pena copiar.

JunoCómo aprender uno Aprende el lenguaje antes que el framework, siempre: JavaScript antes de React, Python antes de Django. Después, construye un solo proyecto pequeño y real con el tutorial oficial abierto al lado. Pequeño y terminado le gana a grande y abandonado, y todo lo que aprendas sobre el lenguaje conserva su valor para siempre.

JunoCómo aprender uno Escapa del ciclo de tutoriales a propósito: un tutorial oficial, y luego un proyecto pequeño sin guía cuyos propios problemas decidan qué lees después. La documentación estudiada con un problema real en la mano de verdad se queda grabada. Quedarte trabado y salir de eso en tu propio trabajo es la habilidad que realmente estás entrenando.

JunoCómo aprender uno Encuentra temprano las vías de escape; marcan los límites reales de la máquina. Y sigue alimentando tu conocimiento de la plataforma que hay debajo, HTTP, el DOM, SQL, porque los frameworks rotan y la plataforma se queda. La gente que conoce la plataforma sobrevive cada transición de framework; yo he visto varias y el patrón no ha fallado todavía.

A dónde te lleva todo esto

Ese es todo el resumen: la simplicidad como prueba, criterios poco glamorosos para elegir, y el lenguaje antes que el framework para aprender. Cuando aparezca un framework específico más adelante, en esta documentación o en el mundo real, Los tipos de frameworks es el mapa para ubicarlo, y Qué es un framework es la definición que está por debajo de todo.