Elegir y aprender un framework

docs.scrimba.com

Los dos capítulos anteriores cubrieron qué son los frameworks y qué existe. Este es el lado práctico: si usar uno, cuál, y cómo aprenderlo. El orden importa, porque la primera pregunta es la que se salta más a menudo.

¿Deberías usar un framework en absoluto?

Imagina dos proyectos. El primero es una aplicación con cuentas, formularios y pantallas que todas reaccionan a datos compartidos. Construirlo desde cero significa reconstruir exactamente la tubería que un framework ya ha perfeccionado, y la versión vanilla termina siendo una estructura dispersa, medio probada, un framework de tu propia invención que nadie quiere heredar. Recurrir a Django o React allí es elegir menos piezas móviles que la alternativa.

El segundo es una página de destino, un sitio de contenido, un pequeño script, un formulario que se envía a algún lugar. HTML, CSS y un poco de JavaScript simples cubren estos sin paso de compilación, sin actualizaciones de dependencias, y sin nada para migrar el próximo año. Envolver una página como esa en un framework completo añade maquinaria de la que solo se benefician las herramientas. Muchos desarrolladores experimentados lanzan vanilla a propósito, y es una respuesta profesional, nunca el compromiso de un principiante.

La ingeniería tiene una regla antigua y directa que cubre ambos casos: KISS, "keep it simple, stupid" (mantente simple, estúpido). El insulto apunta al diseño en lugar del diseñador, y la idea es que la mejor solución es la que tiene la menor maquinaria y aún hace el trabajo. Ambos proyectos anteriores la obedecen, y llegan a respuestas opuestas.

Eso hace que la prueba sea una pregunta, hecha de nuevo para cada proyecto: elige cualquier opción que te deje menos maquinaria para mantener. Cuando la tubería supera al producto, ese es el framework. Cuando el producto es casi todo lo que hay, ese es vanilla.

Algunas señales hacen la llamada concreta. Inclinación hacia framework: muchas pantallas compartiendo datos en vivo, cuentas de usuario y permisos, formularios que validan y guardan, varias personas trabajando en la misma base de código durante años. Inclinación hacia vanilla: principalmente contenido, poca interactividad, una vida útil medida en meses, uno o dos mantenedores, o una página donde la velocidad de carga es toda la función. Y el tamaño del proyecto puede cambiar la respuesta a lo largo del tiempo en ambas direcciones, así que el hábito útil es re-hacer la pregunta cada vez que el proyecto cambia de forma.

Esta decisión falla de dos maneras reconocibles, y ambas provienen de saltarse la pregunta. El primer fracaso es la página de destino en forma de framework: una pipeline de compilación, un árbol de dependencias, y migraciones eventuales adjuntas a cuatro pantallas de contenido, donde cada hora dedicada a herramientas es una hora que el producto no necesitaba. El segundo es el framework accidental: una base de código vanilla que crece su propio router, su propio almacén de estado, y su propio sistema de componentes, cada uno escrito una vez, nunca probado, y entendido por una sola persona. Ese segundo proyecto paga costos de framework sin beneficios de framework. Ambos fracasos se ven como convicción desde adentro; la solución en ambos casos es el mismo movimiento poco glamoroso de re-decidir basándose en lo que el proyecto se ha convertido.

Juno¿Necesitas un framework? Haz una pregunta por proyecto: ¿cuál opción deja menos por construir y mantener? Para una aplicación interactiva con cuentas y datos compartidos, un framework generalmente gana. Para una página de contenido o un pequeño script, el código simple generalmente gana. ¡Ambas respuestas son respetables, y elegir código simple nunca es un paso atrás!

Juno¿Necesitas un framework? El estado compartido en vivo, cuentas, formularios, y una vida larga multipersona apuntan a un framework; las páginas pesadas en contenido, corta vida, o críticas en velocidad apuntan a vanilla. Re-pregunta cuando el proyecto cambie de forma en lugar de defender la llamada original, y hazlo por proyecto cada vez.

Juno¿Necesitas un framework? Observa los dos fracasos clásicos: la página de destino en forma de framework pagando costos de herramientas por nada, y la aplicación vanilla que silenciosamente creció un framework no mantenido propio. Ambos vienen de tratar la elección como resuelta. Re-decido en cada inflexión de proyecto, y me ha salvado de ambas zanjas más de una vez.

Cómo elegir uno

Cuando la respuesta es sí, elige con criterios poco glamorosos. Los benchmarks y comparaciones de características son las entradas menos útiles, porque dentro de una familia las opciones populares son lo suficientemente rápidas y capaces. Lo que realmente da forma a tu vida diaria:

El ecosistema y comunidad: documentación madura, preguntas respondidas, y paquetes para los problemas que encontrarás. El equipo y base de código que estás uniendo: el mejor framework es generalmente el que tu proyecto ya usa, y la consistencia vence a la novedad dentro de un equipo. El mercado laboral, si aprendes para el trabajo: los números puros de uso importan, lo cual es una gran parte de por qué React es la primera opción racional de muchas personas. Y el lenguaje que 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.

Mantén la opción vanilla en la lista hasta el final. Si la tabla de comparación se llena y ninguno de los candidatos vence a "ninguno de los anteriores" en la prueba de simplicidad, esa es la respuesta diciéndote algo.

Para una mirada más cercana a un candidato, una hora de evaluación de primera mano vence una semana de lectura de opiniones: revisa rápidamente el tutorial oficial y juzga si la documentación explica o gesticula; verifica el historial de lanzamientos para un ritmo constante y sin pánico; busca "migrating from version X to Y" y ve si esas guías se leen como una tarde o una temporada; y mira si las preguntas que harías ya tienen buenas respuestas. Un framework es una relación larga, y estas son las pruebas de compatibilidad.

Dos hábitos senior redondean esto. Primero, apuesta por lo bien establecido: una tecnología que ha sido ampliamente utilizada durante años tiene modos de fallo conocidos, grupos de contratación, y respuestas, y "comprobado y ligeramente anticuado" sobrevive a "nuevo y emocionante" mucho más a menudo que de otra manera. La rotación es un costo compuesto, y los frameworks que sobrevivieron una década ya lo pagaron. Segundo, mantén compilar versus adoptar como una opción real a nivel de componente: a veces la cantidad correcta de framework es una librería de enrutamiento y nada más, adoptada para el único problema difícil mientras el resto permanece simple. 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 respetable.

JunoElegir uno Elige con criterios prácticos: lo que tu equipo ya usa, qué tan buena es la documentación y comunidad, qué quiere el mercado laboral, y qué lenguaje ya conoces. Dentro de una familia, cada opción popular es buena, así que las apuestas son más bajas de lo que parecen. Tus habilidades se transferirán de cualquier manera que vayas.

JunoElegir uno Dale a un candidato una hora enfocada: lee su tutorial, verifica su ritmo de lanzamiento, y lee una guía de migración de versión, ya que ese es el futuro en el que te estás inscribiendo. La comunidad, el ajuste del equipo, y la contratación vencen a los benchmarks cada vez. Y mantén "sin framework" en la lista corta hasta el final a propósito.

JunoElegir uno Apuesta por lo bien establecido: sobrevivir una década es el benchmark más informativo que un framework puede publicar. Y recuerda que la adopción no es binaria; a veces una pequeña librería para el único problema difícil es la cantidad correcta de framework. El objetivo es un producto que se lance y permanezca lanzable.

Cómo aprender cualquier framework

Aprende el lenguaje primero. Un framework asume su lenguaje en todas partes: el código React es JavaScript de pared a pared, y cada línea confusa de una aplicación Django es Python debajo. Los estudiantes que saltan al framework terminan depurando dos misterios a la vez, el comportamiento del framework y la sintaxis del lenguaje, sin manera de saber cuál es cuál. Si React es tu objetivo, la pista de JavaScript es el primer paso real; para Django o pytest, la pista de Python juega el mismo papel. El lenguaje primero es el atajo único más grande que hay, porque es la parte que se transfiere a todas partes.

Luego construye algo pequeño y real. Un pequeño proyecto que realmente quieras, construido mientras te apoyas en el tutorial oficial, enseña más que cualquier cantidad de ver y leer, porque la forma del framework solo tiene sentido bajo 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 venir después.

Y mientras avanzas, sigue preguntando qué el framework está haciendo por ti. Cada característica conveniente está en lugar de algo real: una ruta está en lugar del análisis de URL, un componente por actualizaciones del DOM, un modelo por SQL. No necesitas dominar esas capas de antemano, pero saber que existen, y aproximadamente qué hace el framework con ellas, es lo que separa usar un framework de depender ciegamente de él.

La trampa común en esta etapa es el bucle de tutoriales: terminar curso tras curso sin nunca empezar un proyecto sin guía, porque los tutoriales se sienten productivos y los archivos en blanco se sienten arriesgados. Rómpe deliberadamente. Después de un tutorial oficial, comienza el pequeño proyecto real y deja que sus problemas impulsen lo que buscas; la documentación leída con un problema en vivo en la mano se queda de una manera que la documentación leída como tarea nunca lo hace. Quedarse atrapado y salir solo en tu propio proyecto es la habilidad real siendo entrenada.

Dos hábitos hacen que el conocimiento del framework sea duradero. Aprende las trampillas de escape temprano: cada framework tiene formas sancionadas de caer por debajo de sus abstracciones (SQL raw pasando el ORM, acceso directo al DOM pasando el renderizador), y saber dónde están te dice los límites de la máquina incluso si raramente los usas. E invierte en la plataforma debajo del framework, HTTP, el DOM, SQL, el tiempo de ejecución del lenguaje, en un goteo constante. Los frameworks son cómo la plataforma está siendo actualmente sostenida; la plataforma es lo que perdura. Los desarrolladores que conocían la plataforma cruzaron cada transición de framework de los últimos veinte años intactos, lo cual es un récord que vale la pena copiar.

JunoAprender uno Aprende el lenguaje antes del framework, siempre: JavaScript antes de React, Python antes de Django. Luego construye un pequeño proyecto real con el tutorial oficial abierto a tu lado. Pequeño y terminado vence a grande y abandonado, ¡y todo lo que aprendas sobre el lenguaje mantiene su valor para siempre!

JunoAprender uno Escapa del bucle de tutoriales a propósito: un tutorial oficial, luego un pequeño proyecto sin guía cuyos problemas decidan lo que lees después. Los documentos estudiados con un problema en vivo realmente se quedan. Quedarse atrapado y salir solo en tu propio trabajo es la habilidad que realmente estás entrenando.

JunoAprender uno Encuentra las trampillas de escape temprano; marcan los verdaderos bordes de la máquina. Y sigue alimentando tu conocimiento de la plataforma debajo, HTTP, el DOM, SQL, porque los frameworks rotan y la plataforma permanece. La gente de plataforma sobrevive cada transición de framework; he visto varias y el patrón no ha fallado aún.

Dónde esto te deja

Ese es el primer pase completo: la simplicidad como la prueba, criterios poco glamorosos para la opción, lenguaje antes del framework para el aprendizaje. Cuando un framework específico aparece a continuación, en estos documentos o en el mundo real, Los tipos de frameworks es el mapa para ubicarlo, y Qué es un framework es la definición debajo de él.